On 10/3/10 6:45 PM, =JeffH wrote:
> [ forwarding with permission of the author (I didn't write the below) in
> order that we have this info publicly available in the archives ]
> 
> Subject: Fwd: [certid] Need to define "most specific RDN"
> From: Paul Tiemann <[email protected]>
> Date: Fri, 16 Jul 2010 11:56:11 -0600 (10:56 PDT)
> To: Jeff Hodges <[email protected]>, Kaspar Brand
> <[email protected]>

<snip/>

Jeff, what is your take? Here's what I see...

> My opinion on steps for improvement from where we are now:
> 
> 1) Clarify CN usage by strongly recommending only 1 CN in a subject.

I think we already do that, because in our working copy Section 3,
bullet 6 states:

       The certificate MAY contain more than one DNS-ID, but SHOULD NOT
       contain more than one CN-ID.

> 2) Encourage ubiquitous usage of the SAN extension, so that almost all CA
> issued certificates include the SAN extension, only deviating from that for
> reasons of compatibility with legacy servers or clients which choke on the
> SAN.

Again I think we already do that, because in our working copy Section 3,
bullets 1 through 3 state:

   1.  The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName
       entry of type dNSName) if possible as a baseline for
       interoperability.

   2.  If the service using the certificate deploys a technology in
       which a server is discovered by means of DNS SRV records
       [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate
       SHOULD include an "SRV-ID" (i.e., a subjectAltName entry of type
       otherName whose name form is SRVName as specified in [SRVNAME]);
       furthermore, multiple instances of the "SRV-ID" identifier type
       are allowed.

   3.  If the service using the certificate deploys a technology in
       which a server is typically associated with a URI (e.g., this is
       true of [SIP]), then the certificate SHOULD include a URI-ID
       (i.e., a subjectAltName entry of type uniformResourceIdentifier);
       the scheme SHALL be that of the protocol associated with the
       service type and the authority component SHALL be the fully-
       qualified DNS domain name of the service; furthermore, multiple
       instances of the "URI-ID" identifier type are allowed.

> 3) Make strong recommendations to stop using CN-IDs in subject

Done via bullet 5 in Section 3 of our working copy:

   5.  Even though many deployed clients still check for the CN-ID
       within the certificate subject name, the certificate SHOULD NOT
       represent the server's fully-qualified DNS domain name in a
       CN-ID.

> 4) Stop using server-IDs in common names experimentally

That's an implementation and deployment issue, not a spec issue,
although we would hope that folks do some experiments and report on the
results.

Peter

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


_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid

Reply via email to