Re: SSL Certs for Malicious Websites

2016-05-21 Thread tech29063
On Friday, May 20, 2016 at 6:22:21 PM UTC-7, Peter Bowen wrote:
> [ Disclaimer: This message is my personal view and does not
> necessarily represent that of my employer. ]
> 
> On Fri, May 20, 2016 at 5:41 PM,  [Kirk Hall] wrote:
> > Peter -- the reference to BR 9.6.8(8) is interesting, but is not really 
> > relevant to discussion of the requirements of BR 4.2.1 through 4.9.10 
> > quoted by Kathleen in her first message above (and which are enforced by 
> > Section 5 of the Baseline Requirments WebTrust audit - see 
> > http://www.webtrust.org/homepage-documents/item76002.pdf) What about those 
> > sections?  Look again at the first analysis I posted.
> >
> > I don't understand the resistance to complying with these provisions -- 
> > it's not that hard.
> >
> > If you think the requirements of BR 4.2.1 through 4.9.10 should be softened 
> > or deleted, then I suggest you are the one who needs to propose a ballot!  
> > CAs have been following  these rules for about eight years now, so there is 
> > a pretty solid history and precedence.
> 
> You are right, it is not hard to comply with 4.2.1 to 4.9.10.  However
> they say absolutely nothing about malware.  The do discuss "misuse"
> but it is up to the CA to define misuse.
> 
> >From the sections you explicitly called out in your original email:
> 
> 4.9.3: Requires CAs provide ability for anyone to report things.  No
> action is required of the CA other than accepting the report.
> 
> 4.9.2: Says what must be in a certificate problem report, does not
> address processing the report.
> 
> 4.9.5: CA must decide _if_ revocation is warranted. However does not
> state conditions under which revocation must be warranted.
> 
> 4.10.2: CA must be able to respond to problem reports 24x7.
> _Where_appropriate_ the CA can either forward the complaint to law
> enforcement and/or revoke the certificate.  Again does not specify any
> conditions where the CA must do so.
> 
> 4.9.1.1(4): Requires the CA to revoke if the Certificate was misused.
> CA is free to define misuse as they see fit.
> 
> 4.2.1: Requires "additional verification activity for High Risk
> Certificate Requests prior to the Certificate’s approval, as
> reasonably necessary to ensure that such requests are properly
> verified under these Requirements."  Simply requires CAs to be sure
> they are properly identifying the subject authorization and DNS name
> control, as that is what is verified.
> 
> High Risk Certificate Request: ": A Request that the CA flags for
> additional scrutiny by reference to internal criteria and databases
> maintained by the CA".  Does not define any specific mandatory
> requirements for the criteria or database contents.  It does have "may
> include", but that means it is up to the CA.
> 
> I think one of the things that frequently is missed by people not used
> to technical specifications is the meaning of section 1.6.4 of the
> BRs.  It says that the 'words “MUST”, “MUST NOT”, "REQUIRED", "SHALL",
> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" in these Requirements shall be interpreted in accordance
> with RFC 2119.'  This basically means that anything labeled "should",
> "may", "recommended", or "optional" can be ignored.  The BRs become
> much clearer if you simply remove all the text that uses these words.
> This is why I recommended that they be amended if there is a desire
> that CAs be required to do something currently allowed to be ignored.
> 
> Thanks,
> Peter

Peter, once again you are ignoring the full language of BR 4.9.2 to 4.10.2.  
These CA requirements are not limited to reports of "misuse" submitted to a CA, 
but apply to reports of "suspected Key Compromise, Certificate misuse, or other 
types of fraud, compromise, misuse, or inappropriate conduct related to 
Certificates."

So please don't try to limit this conversation to what is "misuse" -- that's 
just inaccurate for defining a CA's obligations.  We as CAs need to be 
protecting users once we receive Certificate Problem Reports of certs being 
used for malware injection.

4.9.2: Anyone can submit “Certificate Problem Reports” to the issuing CA.   
That includes “Complaint of suspected Key Compromise, Certificate misuse, or 
other types of fraud, compromise, misuse, or inappropriate conduct related to 
Certificates.”

4.9.3: “Certificate misuse, or other types of fraud, compromise, misuse, 
inappropriate conduct, or any other matter related to Certificates”

4.9.5: “The CA SHALL begin investigation of a Certificate Problem Report within 
twenty-four hours of receipt, and decide whether revocation or other 
appropriate action is warranted based on at least the following criteria: 
1. The nature of the alleged problem; 
2. The number of Certificate Problem Reports received about a particular 
Certificate or Subscriber; 
3. The entity making the complaint (for example, a complaint from a law 
enforcement official that a Web site is engaged in illegal activities should 
car

Re: SSL Certs for Malicious Websites

2016-05-21 Thread Richard Z
On Thu, May 19, 2016 at 05:20:07PM +1000, Matt Palmer wrote:
> On Tue, May 17, 2016 at 11:14:21PM +0200, Richard Z wrote:
> > There are crime friendly providers already and having crime friendly CAs is 
> > something that users would definitely notice.
> 
> Why?  Do users typically notice the crime friendly hosting providers?

they do. You can argue that in absence of crime friendly providers the
criminals have other methods but having rogue providers certainly
makes their business easier.

There should be some reasonable middle ground. CAs can not be responsible 
for the contents served by their clients servers. However, CAs also must 
not knowingly or by gross negligence support malicious operations.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy