[cabfpub] Misissuance of certificates

[Rick Andrews]

Ryan,

Today, we and other CAs issue certificates to customers for use both (a) publicly and with browsers, and (b) privately on internal networks and/or with non-browser applications. Currently, these certificates all have a TLS serverAuth EKU, all are in-scope with the BRs, and all comply with the BRs. They all are issued from roots that appear in browser and OS trust stores.

However, we believe that if a CA issues a certificate (1) with a TLS serverAuth EKU, that (2) chains to a root that is not in browser or OS trust stores, then those certificates are not in scope nor need to comply with the BRs. We’ve discussed this before in the CA/B Forum and there seems to be consensus among the Forum members, including auditors. 

 

The issue that we’re raising here is that today the same roots, those trusted by browsers, are used for both public and private applications. This creates unnecessary complexity and delays in moving initiatives in the CA/B Forum forward as we have to solve for both the public and private use cases. What we’re recommending is finally to make these use cases clearly distinct for customers (clearly using different roots for the public vs. private cases and the clarifying the implications of choosing one vs. the other) and to provide a transition period to do so.

 

This will serve not only this topic of transparency but also allow us the ability to move faster than before to move forward other important changes when it comes to publicly trusted certificates.    

  

-Rick

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, December 09, 2015 7:05 PM
To: Rick Andrews
Cc: public at cabforum.org
Subject: Re: [cabfpub] Misissuance of certificates

 

 

 

On Wed, Dec 9, 2015 at 6:39 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:

Ryan,

 

Yes, that’s what I mean by private (not subject to the BRs).

 

The concerns I raised still apply... today it is common practice for customers to use certificates from roots trusted by browsers for private and/or non-browser use cases. The ballot needs an implementation date in the future to allow us and other CAs time to implement options for customers that distinguish these private/non-browser certificates, to make sure customers are aware of how these new rules relate to the future disclosure of publicly-accessible certificates, and to allow customers to replace their existing certificates where needed. This is why we proposed the interim disclosure approach, where prior to that implementation date, disclosure would still happen, but with the subject details redacted.

 

Rick,

 

A few points of clarification, to make sure I am fully understanding your message.

 

When you say 'private and/or non-browser use cases', is it correct to understand this as:

1) Certificates that have a TLS serverAuth EKU

2) Certificates that are in-scope with the Baseline Requirements

3) Certificates that comply with the stipulations set forth in the Baseline Requirements

 

If you have 1, then it should be well understood that you also have 2, and thus necessarily also have 3, but I wanted to confirm that #1 is true.

 

However, your reply "private, not subject to the BRs" and "from roots trusted by browsers" seems very much incompatible, if 1 is true, and if this is the case, then we need to resolve this understanding as soon as possible, as such an understanding seems incompatible with a number of root program agreements.

 

If you have #1, however, I have trouble understanding how it _isn't_ a matter of public interest and trust when such a certificate is misissued, and thus would like to try to further understand the reasoning.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151211/2959981b/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5749 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151211/2959981b/attachment.bin