[cabfpub] Defining BR scope
rob.stradling at comodo.com
Thu Feb 4 13:51:06 UTC 2016
On 02/02/16 19:02, Peter Bowen wrote:
>> Other software: It will be a decade+ before such applications stop
>> checking CNs.
> And it is certs like https://crt.sh/?id=11880495 that prove that this is
> true. That certificate was issued in the last month, has no SAN or EKU,
> has a FQDN in the CN, and chains back to one or more roots trusted by
> every browser (https://gist.github.com/pzb/c55a802c283c7b44002d).
> https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil shows
> that the certificate is in use at the FQDN in the CN.
> According to the ssllabs analysis, the chain should fail due to policy
> constraints, but I’m not sure if anything enforces such constraints.
OK, so "FQDN in the CN" should be in-scope. Let me update my proposal...
I propose that an end-entity certificate should be regarded as in-scope
for the BRs if...
1. The EKU extension is either:
b) present, containing at least ONE of the following OIDs:
iii) the Microsoft SGC OID
iv) the Netscape Step-up OID
2. The cert contains at least ONE of the following:
a) A SAN.dNSName, containing any value.
b) A SAN.iPAddress, containing any value.
c) A Subject.CN, containing any value that ends with an
IANA-registered TLD preceded by a ".".
d) A Subject.CN, containing an IPv4 or IPv6 address.
3. The cert chains up to a publicly-trusted root certificate.
Otherwise, it's out of scope.
How am I doing?
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public