[cabfpub] Ballot 208 - dnQualifiers

[Peter Bowen]

> On Oct 22, 2017, at 12:44 PM, Geoff Keating <geoffk at apple.com> wrote:
> 
> 
> 
>> On 22 Oct 2017, at 11:05 am, Peter Bowen <pzb at amzn.com> wrote:
>> The issue that both Li-Chun and Geoff raise appears to be whether we should use a different attribute type instead of dnQualifier.  The most obvious suggestion would be to define a new attribute type, under an Object Identifier arc that is managed by the Forum or a member.  However this results in real-world compatibility issues.  There are numerous products which error if a certificate DN contains attributes not on a whitelist.
> 
> I think you’ve undercut this ballot a bit by pointing out that:
> 
>> A bit of searching on “oid.map”, I did find the source, which is a PKIX library from Certicom.  The part of oid.map that seems relevant is below.  I note dnQualifier is not there, so maybe we should choose one of the attributes below:

I agree that this finding does undercut a core portion of the rationale from he ballot as written.  I found this while writing the email I sent; it was news to me.  I had stupidly assumed that all the attributes that have been the RFCs forever would be supported everywhere (name | commonName | surname | givenName | initials | generationQualifier | dnQualifier | countryName | localityName | stateOrProvinceName | organizationName | organizationalUnitName | title | pkcs9email)

> Another workaround for individual cases is to identify the subscriber!  If you just supply the countryName field, that will do.  It can be determined and verified automatically in most cases.

If it would be agreeable to exclude countryName-only certificates from the definition of certificates which "contain Subject Identity Information”, then this seems like a reasonable workaround.  Otherwise section 7.1.6.1 directs that these be designated OV certificates.

I think this could be accomplished by the following change to the definitions in the BRs:

"Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include [strikeout]a domain name listed in the subjectAltName extension or the Subject commonName field[/strikeout] [insert]countryName attributes in Distinguished Names, commonName attributes in Distinguished Names, dNSName Subject Alternative Names, iPAddress Subject Alternative Names, or SRVName Subject Alternative Names[/insert].” 

and in section 3.2.2:
If the Applicant requests a Certificate that will contain [strikeout]Subject Identity Information comprised only of[/strikeout] the countryName field [insert]and no Subject Identity Information[/insert], then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of Section 3.2.2.3 and that is described in the CA’s Certificate Policy and/or Certification Practice Statement.  If the Applicant requests a Certificate that will contain the countryName field and [strikeout]other[/strikeout] Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representative’s certificate request using a verification process meeting the requirements of this Section 3.2.2.1 and that is described in the CA’s Certificate Policy and/or Certification Practice Statement.  The CA SHALL inspect any document relied upon under this Section for alteration or falsification.

This completely removes dnQualifier from the equation.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171022/933021a0/attachment-0003.html>