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 
carry more weight than a complaint from a consumer alleging that she didn’t 
receive the goods she ordered); and 
4. Relevant legislation.”

Section 4.10.2: "The CA SHALL maintain a continuous 24x7 ability to respond 
internally to a high-priority Certificate Problem Report, and where 
appropriate, forward such a complaint to law  enforcement authorities, and/or 
revoke a Certificate that is the subject of such a complaint." 
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to