On 5/14/10 2:48 AM, Peter Sylvester wrote: > > >> >> In particular here's what RFC 2818 sez (in section 3.1 Server Identity).. >> >> If a subjectAltName extension of type dNSName is present, that MUST >> be used as the identity. Otherwise, the (most specific) Common Name >> field in the Subject field of the certificate MUST be used. ... >> >> ..which is ambiguous because X.501 does not explicitly state which RDN >> in the DN sequence is the most specific (it's implied) and there >> allegedly exist non-trivial slices of current practice don't >> necessarily follow that stipulation anyway (for whatever reasons). > DNs as a sequences of RDNs form a hierarchical name space similar to the > DNS name space. > with the difference that the "labels" are not just a piece of texts but > are structured , i.e. > SET OF of attribute/values assertions. > > If one writes "a.b.c" then this is something that can be described as a > string folling DNS name syntax, > and I could use it in whatever environment. > > What is ambiguous in 2818 is that you may have a set of AVAs with more > than one > occurence of an AVA with common name. In theory... > > Using the term 'field' is somewhat sloppy wording.
We borrowed that wording from RFC 5280. Do you have a suggestion for improvement? And, from the perspective of this proposed BCP, does it make a material difference? >> Also, we should note that the current rev of "CA/Browser Forum: >> Guidelines For The Issuance And Management Of Extended Validation >> Certificates (version 1.2)" <http://cabforum.org/Guidelines_v1_2.pdf> >> specifies using CN (commonName) containing the host domain name /or/ >> dNSName in subjectAlternativeName (see section 8.1.1(2) therein), >> rather than deprecating use of subject:commonName (in that doc's >> notation). that doc also doesn't specify where in the DN's RDN >> sequence an RDN of type commonName should/must be placed. > > Indeed. This is not surprising, if one looks at certification policies, > they are also pretty unprecise in that area. > > But: what is deprecated in RFC 2818 is the fact not using > a subjectAltName: > > If a subjectAltName extension of type dNSName is present, that MUST > be used as the identity. Otherwise, the (most specific) Common Name > field in the Subject field of the certificate MUST be used. Although > the use of the Common Name is existing practice, it is deprecated and > Certification Authorities are encouraged to use the dNSName instead. > > At least, if I understand the "otherwise" correctly and apply > Boolean an IETF logic. > > As soon as one adds a subjectAltName, a verifier conformant > to 2818 doesn't even look for a common name. > > As a "best practice", one may say that having > exactly one common name AVA in a single value RDN with > ensures that the cert is recognized as one belonging > to the intended host. > > and to have an identical value in a subjectAltName > > One may add that putting it as the last element in the > sequence covers the 0.000001% of very strange things, > I'd rather say that it is not necessary for this RDN > to be the last (i.e. explicitely tell verifiers so) > >> >> (so we have some evangelizing to do with the CABForum folk...) > > Well, my hourly fee is ... negotiable :-) > > I (really don't) wonder how many of the CAs in that forum allow a > certificate request with two common names... > > I think it is very important that the RFC use clear wording that > is also easy to understand by non native English. > > 7. The certificate SHOULD NOT represent the server's DNS domain name > in a Relative Distinguished Name (RDN) of type Common Name (CN) > (see [LDAP-SCHEMA]) within the subjectName field, even though it > is recognized that many deployed clients still check for this > legacy identifier configuration within certificate subjectName. > > I do not see any reason for this unless one adds 'only' before the > within. see above. How about removing the words "within the subjectName field"? > However, if this legacy identifer configuration is employed, then > the server's DNS domain name MUST be placed in the last (most > specific) RDN within the RDN sequence making up the certificate's > subjectName, as the order of RDNs is determined by the DER- > encoded Name within the server's PKIX certificate. > > If one takes the text without saying that subjectAltName has precedece, > I think the message is wrong. Does this proposed BCP say that the subjectAltName has precedence? If that is not clear, then we need to clarify it. > The subject field of a PKIX Certificate is defined as a X.501 type > Name [PKIX] and known as a Distinguished Name (DN). See also [X.501] > A DN is an ordered sequence of attribute type and attribute value > pairs (termed "attribute value assertions (AVAs)"), where the > attributes are to be those of the subject. Each AVA is also termed a > "Relative Distinguished Name (RDN)". The RDNs are ordered in the DN > sequence from most general to most specific. > > this is simply wrong. > > DistinguishedName ::= RDNSequence > > RDNSequence ::= SEQUENCE OF RelativeDistinguishedName > > RelativeDistinguishedName ::= SET SIZE (1..MAX) OF > AttributeTypeAndValue > > AttributeTypeAndValue ::= SEQUENCE { > type AttributeType, > value AttributeValue } Our working copy of version -05 currently says: The subject field of a PKIX certificate is defined as an X.501 type Name and known as a Distinguished Name (DN) -- see [X.501] and [PKIX]. A DN is an ordered sequence of Relative Distinguished Name (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- value pairs [LDAP-DN], each of which asserts some attribute about the subject of the certificate. The RDNs are ordered in the DN sequence from most general to most specific. > Often such a > DN string representation is ordered from left-to-right, most specific > to most general. See [LDAP-AUTH] for details. OK. In fact do we need to say anything about the order (specific to general or general to specific)? > I'd rather say that unfortunately both orderings occur and > it not always obvious to see which is used. I know about a > institude's CA that has country (C=DE) as last element > got that certified. :-) So: ... In practice, the RDNs can be ordered in the DN sequence from most general to most specific or most specific to general, and the order cannot be relied upon. Better? > 8. The certificate MUST NOT represent the server's DNS domain name > by means of a series of Domain Component (DC) attributes (because > the order of Domain Components is not guaranteed, certain attacks > are possible if DC attributes are included). > > I think that this is also not nice wording. What is ment IMO is > that the server MUST NOT assume that whatever is put in DCs > is recognized as a domain name. This section is about certificate issuance, not client processing (or server interpretation of the certificate, which so far is utterly out of scope for this proposed BCP). > One should be careful about such words, sine it may be that > some extremely strict verifier misinterprets it. Talking about > 'certain attacks' doesn't seem a useful information. Consider: 1. DC=com, DC=example, DC=cn vs. 2. DC=cn, DC=example, DC=com Clearly com.example.cn != cn.example.com, but if one interpreted DCs then both of those DNS domain names would match #1 and #2. We can add more text about this to the spec. > 2. After the server provides its presented identifiers in the form > of an PKIX certificate, the client checks each of its reference > identifiers against the presented identifiers for the purpose of > finding a match. > > 'presents its' instead of 'provides its presented' > and remove 'after'. It maybe present out of band Sure. Changed. > The reference identifiers is matched with identifiers > included/present/provided/electable in a PKIX certificate > belonging to the server, i.e. by which the intended > communication of data verification can be authenticated > cryptograhically. > > I don't really like PKIX here, one may have an X509 cert that is not > conformant to the PKIX profile. One may, but we're not trying to cover every possible profile of X.509v3 here, only those conformant to the PKIX profile. > In addition to checking identifiers, a client MAY complete further > checks to ensure that the server is authorized to provide the > requested service. However, methods for doing so (e.g., consulting > local policy information) are out of scope for this document. > > The chapter talks about Server identity verification. This paragraph > doesn't belong to this imo. It's just an implementation note. I've added some clarifying text. > o The list SHOULD NOT include a CN-ID; however, the CN-ID (if > included) MUST be constructed only from the source domain and > never from a target domain. > > Note: A client MUST NOT construct a reference identifier > corresponding to Relative Distinguished Names (RDNs) other than > the Common Name and MUST NOT check for such RDNs in the presented > identifiers. In particular, this means that a client MUST NOT > check a series of Domain Component (DC) attributes if included in > the certificate (because the order of Domain Components is not > guaranteed, certain attacks are possible if DC attributes are > checked). > > since a CN-ID is: > > CN-ID = a Relative Distinguished Name (RDN) of type Common Name > (CN) > > what is the purpose of the note? The purpose of the note is to warn client developers against using DCs. > 3.4.4 seems to have a lot of redundant information and not the > same as already presented elsewhere. Repetition is not necessarily a bad thing. We assume that client developers will read only section 3, not section 4. > All text starting from > thesecond paragraph can be replaced by > > 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 cfor a CN-ID. Maybe, but I think the repetition is useful. I'll double-check this when I have more time. > The examples may be put into the description of the certificate subject > structure. > > > 3.6: There may also be the case where the server does not present a cert > at all. not the case of tls etc, but one may verify signatures of OCSP, > TSAs etc. Out of scope. We might write another spec about such use cases, but in this case we think we're covering at least 80% of the usage. > have fun Always. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
