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