Re: [certid] version -04 of CertID draft

[Peter Saint-Andre <[e-mail]>]

On 5/13/10 2:28 AM, Kaspar Brand wrote:
> A few more comments about draft -04:

My apologies, I missed this post while making our edits for -05.

(Nits skipped in what follows.)

>> 2.1.  Subject Naming in PKIX Certificates
>> [...]
>>    "string representation" of a DN before being rendered.  Often such a
>>    DN string representation is ordered from left-to-right, most specific
>>    to most general.  See [LDAP-AUTH] for details.
> 
> I would suggest to replace this with a reference to RFC 4514 (not 4513).

Corrected.

>> 2.2.  PKIX Certificate Name Rules
>>
>>    The following rules apply to the representation of application server
>>    identities in PKIX certificates issued by certification authorities.
>>
>>    1.  The certification authority MUST issue the certificate based on
>>        the DNS domain name (not an IP address) at which the server will
>>        provide the relevant service.
> 
> With the current draft, "relative" domain names (such as "www", "mail"
> etc.) are also permitted as DNS-IDs or CN-IDs, from what I understand.
> Is this a deliberate decision, or should domain names possibly be
> required to be fully qualified (or "absolute", in RFC-1034 speak)? If
> the latter, then it would probably make sense to add an entry for "DNS
> domain name" to section 1.3 and explicitly state that it's required to
> be absolute / fully qualified.

Our intent was to cover only absolute domain names. Fixed in our working
copy.

>>       Note: A client MUST NOT seek a match for a reference identifier of
>>       CN-ID if the presented identifiers include an SRV-ID, URI-ID,
>>       DNS-ID, or any application-specific subjectAltName extensions, and
>>       MUST NOT check a Common Name in the certificate if it is other
>>       than the last Relative Distinguished Name (RDN) in within the
>>       sequence of RDNs making up the Distinguished Name within the
>>       certificate's subjectName.
> 
> As already mentioned elsewhere, this requirement is probably too strict.
> I suggest changing to something like "must only check against the last
> Common Name RDN in the sequence of RDNs making up the Distinguished Name
> within the certificate's subjectName".

That wording does seem better. Thanks for the text.

>> 3.4.4.  Checking of DNS Domain Names in Common Names
>>
>>    As noted, a client MUST NOT seek a match for a reference identifier
>>    of CN-ID if the presented identifiers include an SRV-ID, URI-ID,
>>    DNS-ID, or any application-specific subjectAltName extensions.
>>
>>    Therefore, if and only if the identity set does not include
>>    subjectAltName extensions of type dNSName, SRVName, or
>>    uniformResourceIdentifier (or any application-specific subjectAltName
>>    extensions), the client MAY as a fallback check for a DNS domain name
>>    in the value of the last Relative Distinguished Name (RDN), if it is
>>    of type Common Name (CN), within the sequence of RDNs making up the
>>    Distinguished Name within the certificate's subjectName.  (Note: The
>>    term "last" refers to the DER order, which is often not the string
>>    order presented to a user; the order that is applied here MUST be the
>>    DER order.)
> 
> See above - should be adapted accordingly.

Done in our working copy.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/