On 07/06/2010 02:35 PM, Ludwig Nussel wrote:
Kaspar Brand wrote:
[1] Re-reading section 3.1 in RFC 2818 can actually confirm this
hypothesis, under the following interpretation: "the (most specific)
Common Name field in the Subject field of the certificate MUST be used"
can be understood to mean the domain name which has the highest number
of DNS labels: if the subject has CN=foo.example.net and CN=example.net,
then the first one must be used for the identity check (it's more
specific than CN=example.net), irrespective of its position in the DER
encoded subject, actually.
That interpretation at least doesn't require knowledge about
certificate encoding subtleties. It's ambiguous though. You could
have several CN with an equal number of dots after all. Just think
of this one:
http://www.mail-archive.com/[email protected]/msg61198.html
cu
Ludwig
X.500 defines a tree structure, the nodes are relative names put
into a hierarchie represented by a DN. a prefix of the elements in
the sequence defines thus a "subtree", and the relative name of a leaf
is the rightmost element, In a tree the most specific element a leaf
and moving backwards defined less specific.
There is no need at all to talk about binary encoding, or DER or
whatever. A DN is a sequence of relative names forming a tree
structure when interpreted in the X.500 context. This is thus
one clear interpretation of 'most specific' (for a RDN).
But: Since RDN can have multiple occurences of AVAs with the
same type, (and one my even construct interpretations as above)
it is not clear whether anything else than putting exactly one AVA
with type Common Name into the very last component and not
having any AVA with type Common name may lead to unexpected
results, making 2818 unclear.
At least I think one can agree that Common name in the last RDN
as the only AVA is "safe". What can one do else:
- some other RDNs without after it? probably ok, but not sure.
- other RDNs with Common Name before? oh oh, like th \0 attack
- multiple AVAs in the same RDN. maybe.
...
Anyway, since there is no good reason not to put a subjectAltName,
I do not think that one shouls say anything more than
"If you use a Common Name other than in the most simple case one
may run a risk not to be interpreted correctly."
replace:
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]..... and so on
by
In essence, Subject (and Issuer) are essentially are defined in PKIX and
X.50x/ISOnnnn as ASN.1 type DistinguishedName which is (in ASN.1 terms)
a a row of elements (SEQUENCE OF in ASN.1 terms)
of type RelativeDistinguishedName (RDN).
In the directory context and in the PKIX context
this defines a hierarchical tree structure
from left to right and least to most specific, i.e. a prefix defines
a subtree and the relative name of a leaf is the rightmost one
in the sequence.
An RDN is a collection (SET OF in ASN.1 terms) of elements of
the ASN.1 type AttributeValueAssertion (AVA). ... leaving as
exercise a definition of AVA.
Thus, regarding this, the usage of "most specific RDN of type Common
Name" in HTTPS is not precise enough.
Furthermore, string representations (as well as graphical ones)
may confuse
users because of two possible interpretations of an implied order of
RDNs.
e.g. LDAP define the order ....
and, historically, Openssl uses the other direction.
By the way: Certificates are not binary objects. At best:
Certificates are structures defined as ASN.1 types, and (almost always)
transmitted in
an encoding called DER... which may be encapsulated in base64, i.e.
becoming textual ... etc. Anyway, does this matter here?
Compare: The last paragraph of 2.2 doesn't use DER.
SubjectAltname is not a 'field', it is an occurence of type
Extension identified (... let's say ... ) as SunjectAltName.
Certificate subjects may have alternate names represented as Extension
identified as SubjectAltName.
Thus: 2.2 can be greatly simplified IMO.
ave fun.
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
