[cabfpub] Defining BR scope

[Peter Bowen]

(changing the subject to split the thread)

> On Jan 20, 2016, at 3:05 PM, Peter Bowen <pzb at amzn.com> wrote:
> 
> 
>> On Jan 20, 2016, at 12:51 PM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>> wrote:
>> 
>> On Wed, Jan 20, 2016 at 11:57 AM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
>> 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.
>> 
>> This seems to weaken Jeremy's proposal - but perhaps it's merely bringing clarity to what was already a weak proposal.
> 
> I admit that it might weaken it in one area — by saying the Compliance Date is the earlier of notBefore or CA signing, it would allow a CA to issue a certificate now with a notBefore of Feb 1, 2013 and avoid the rule.  This is possible because there is no rule about how the notBefore date relates to the date when the CA signs the certificate.

Based on concerns raised offlist about some cert profiles used for identity cards, I'll the following alternative:

"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 February 15, 2013 that that either do not include the extended key usage extension or include anyExtendedKeyUsage (2.5.29.37.0) in the extended key usage extension and:
- do not include a subject alternative name extension or
- include a subject alternative name extension containing one or more entries of type dNSName or iPAddress and 

These requirements do not apply to Certificates that contain a keyUsage extension and do not assert any of digitalSignature, keyEncipherment, keyAgreement, keyCertSign, or cRLSign.”  

This excludes things that cannot validly be used to authenticate a TLS connection. I realize that this is the kind of complexity that some were hoping to avoid, but I feel like this is a reasonable tradeoff between recognizing that X.509 certificates are used in many contexts and ensuring that relying parties are appropriately protected.

Thanks,
Peter

> 
>> That is, it leaves an unknown portion of non-BR certificates out there for an unknown number of years (since, by being non-BR, we cannot presume that the certificates themselves will expire within the 39 months prescribed by the BRs, nor the 60 months previously allowed)
>> 
>> The problem with the Web PKI is determining what the known-knowns are, but also trying to map out the unknown-unknowns - there's a vast portion of 'hidden' certificates which do not comply to the BRs, but were issued by BR conforming roots. The past two years of Mozilla's CA communications demonstrate Mozilla's own attempts to map out the scope and impact of such certificates - even when the requirements were much clearer.
> 
> From CT logs, it seems that a number of CAs were issuing certificates with validity periods of up to 10 years prior to the BRs coming into effect.  It doesn’t seem clear to me that this was against any rule.
> 
>> If we adopt a position of "go forward" of June 30, 2016 being when anything in scope (and there may still be some wording tweaks needed here to clarify that issuance from a CA that has the EKUs but leaves that do not have EKUs, the leaf is _still in scope_), I think we should also look at an internal-server-name like "revoke-or-disclose" sunset clause.
>> 
>> The end goal being that, for roots and intermediates that conform to the BRs, the entire population of certificates - and the requirements that they were expected to abide by - can be known.
> 
> I think that putting in some compliance dates is a start.  Yes, it might not be great, but at least it should create a closed set of certificates rather than continuing to have ambiguity.
> 
> Thanks,
> Peter
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

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