[cabfpub] Misissuance of certificates

Peter Bowen pzb at amzn.com
Wed Jan 20 19:57:35 UTC 2016


What would you think about defining a new term, “Compliance Date”?

Compliance Date: The Compliance Date of a certificate is the earlier of the notBefore field or when the CA signs the certificate

Then it can be used to make it very clear:

These Requirements apply to all Certificates with a Compliance Date of or after February 15, 2013 that include id_kp_serverAuth (1.3.6.1.5.5.7.3.1) in the extended key usage extension. Additionally, these Requirements apply to all Certificates with a Compliance Date of or after June 30, 2016 that either do not include the extended key usage extension or include anyExtendedKeyUsage (2.5.29.37.0) in the extended key usage extension.

I might also suggest replacing the sentence "The	requirements	are	not	mandatory	for	Certification	Authorities	unless	and	until	they	become	adopted	and	enforced	by	relying–party	Application	Software	Suppliers.” with “These Requirements became mandatory for Certification Authorities on February 15, 2013.” 

The Feb 2013 date is based on the email thread in Feb 2015 titled "When did the WebTrust/ETSI BR audit requirement become mandatory?”

Thanks,
Peter


> On Jan 20, 2016, at 11:37 AM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> 
> To move this discussion forward (and resurrect my old proposal), I’d like to have a ballot that defines the scope of the BRs as follows:
> 1)      Effectively immediately, any certificate chaining to a publicly trusted root containing the serverAuth EKU is considered in scope
> 2)      Effective Jun 30, 2016, any certificate containing either no EKU or any EKU is in scope. 
>  
> The language change would be to Section 1.1:
> These Requirements apply to all Certificates that include id_kp_serverAuth (1.3.6.1.5.5.7.3.1) in the extended key usage extension. Effective June 30, 2016, these Requirements apply to all Certificates that either omit the extended key usage extension or include either id_kp_serverAuth (1.3.6.1.5.5.7.3.1) or anyExtendedKeyUsage (2.5.29.37.0) in the extended key usage extension. containing an extendedonly address Certificates intended to be used for authenticating servers accessible through the Internet. 
>   <>
> Thoughts?
>  
> From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com>] 
> Sent: Monday, January 18, 2016 1:00 PM
> To: Jeremy Rowley
> Cc: Rick Andrews; Peter Bowen; Doug Beattie; public at cabforum.org <mailto:public at cabforum.org>
> Subject: Re: [cabfpub] Misissuance of certificates
>  
>  
>  
> On Mon, Jan 18, 2016 at 11:53 AM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>> wrote:
> I don’t recall that as being the case.  I think the discussion stalled because certain national programs used the anyEKU and their national policies conflicted with the BRs.  I know we all agreed serverAuth ought to be included.  The question was on no EKU and anyEKU as they are both technically server certs. 
>  
> Isn't that what I said? ;)
>  
> no EKU and anyEKU are both accepted by all browsers as being valid for issuance.
> There were some CAs who, as you note, in collaboration with certain national PKI projects, had issued a number of such intermediate certificates, but wished to exclude them from BR compliance.
>  
> And that's where and how we stalled - CAs that were capable of issuing certificates trusted for TLS authentication wished to be out of scope of issuance.
>  
> There was the suggestion of who should bear that cost - either the CAs doing this, which would need to either stop participating in such programs or reissue intermediates, or browsers, with the proposal being that all new software only accept serverAuth EKUs. There was, unsurprisingly, also objections about whether the EKUs should chain - that is, in RFC 5280, they apply to the leaf certificate, but as implemented by many libraries, the intermediate's EKU set is expected to be a superset of the leaf EKU set.
>  
> This discussion reached an impasse because neither party was really willing to budge. In response, both Mozilla and Microsoft implemented root program requirements that made this clear, with Mozilla's policy language being very explicit that anything that can technically cause issuance needs to be in scope of a BR audit, or be technically restricted from such issuance.
>  
> So now we're having this conversation again, but with clearer policies as to what browsers expect. Does that make this national policies go away? No. But it sets out the expectation of what constitutes publicly trusted, and therefore what constitutes as scope of needing BR audits.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160120/c5db633d/attachment-0003.html>


More information about the Public mailing list