[cabfpub] Subject attribute proposal

[Rob Stradling]

On 20/03/17 16:59, Peter Bowen via Public wrote:
>
>> On Mar 20, 2017, at 5:37 AM, Gervase Markham <gerv at mozilla.org> wrote:
>>
>> On 19/03/17 23:28, Peter Bowen via Public wrote:
>>> I would like to allow CAs to add a dnQualifier attribute to certificate subjects without it being considered “Subject Identity Information”.
>>
>> Why? :-)
>
> Right now the BRs say that only CN is excluded from being Subject Identity Information.

Hi Peter.  The definition in the BRs is:

"Subject Identity Information: Information that identifies the 
Certificate Subject.  Subject Identity Information does not include a 
domain name listed in the subjectAltName extension or the Subject 
commonName field."

Clearly you're correct that "CN is excluded", because that's stated 
explicitly.  However, I question your assertion that _only_ CN is excluded.

What is included (and hence not excluded) is: "Information that 
identifies the Certificate Subject", minus the CN.  Presumably your 
interpretation is that this "Information" includes every attribute 
(minus the CN) in the Subject Distinguished Name.

However, ISTM that neither "OU=Domain Control Validation" nor "OU=Hosted 
by Contoso Hosting" _identify the Certificate Subject_.

I _think_ (but if anyone remembers differently, please shout) that the 
intent of the BRs was for these sorts of (ab)uses of the OU field to be 
permitted (well, tolerated at least) in DV certs without requiring OV 
validation.

> So including anything other attribute type in a subject (e.g. OU, description, etc) means the certificate has to meet the rules for Subject Identity Information, such as:
>
> The CA (i) implemented a procedure to verify the identity of the Applicant in accordance with Sections 3.2 and 11.2; (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;
>
> If the Applicant for a Certificate […] is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request.
>
> In other words, even if the certificate does not contain the organization name, but does contain some attribute, then the CA must follow 3.2 and 11.2 to confirm the identity of the applicant and may need to verify the authenticity of the certificate request.
>
> As I read it, a certificate with a subject such as “/OU=Domain Control Validated/OU=Hosted by Contoso Hosting/CN=*.example.com” triggers the above rules.
>
> Unfortunately leaving the subject completely out (e.g. an empty sequence for the Subject Name) breaks operating systems from a browser member.  This can be tested by trying to visit https://no-subject.badssl.com/
>
> We also know that commonName is limited to 64-characters and is required to contain a name from the subjectAlternativeNames list.  If all the names in the SAN are longer than 64-characters, the CA cannot today issue a certificate without Subject Identity Information.
>
> This proposal provides for an attribute that can be used in a subject without triggering the SII rule.  It allows CAs to issue no-SII certificates that work on all current OSes for all valid FQDN without violating the BRs.
>
> Thanks,
> Peter

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