[cabfpub] Defining BR scope

[Rob Stradling]

On 02/02/16 19:02, Peter Bowen wrote:
<snip>
>> 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:
     a) absent
     or
     b) present, containing at least ONE of the following OIDs:
       i) id-kp-serverAuth
       ii) anyExtendedKeyUsage
       iii) the Microsoft SGC OID
       iv) the Netscape Step-up OID
   AND
   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.
   AND
   3. The cert chains up to a publicly-trusted root certificate.

Otherwise, it's out of scope.

How am I doing?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online