Subject: pkinit, non-unique rfc2253 transformations, and transited encodings

From: Tom Yu <[email-masked]>
Date: Mon, 18 Nov 2002 21:35:11 -0500

From my readings of RFC 2253, it appears that the specification with
in section 3.1 of the pkinit draft creates a potentially one-to-many
transformation from X.500 names to UTF-8 strings.  The pkinit
constraint on the encoding of multi-valued RelativeDistinguishedName
values helps, but is not sufficient to create a unique mapping.  RFC
2253 appears to permit the use of numeric dotted OID representations
for AttributeType and the use of hexadecimal-encoded values for the
AttributeValue, though it appears to restrict this usage for cases
where an application needs to be able to reconstruct the DER encoding
of an X.500 name.  The pkinit draft should probably explicitly
prohibit this usage.  I don't know if excluding the combination of
dotted-OID / hex-value-encoding is sufficient to create a unique
mapping from X.500 names to UTF-8 strings, though.

Also, there is a question of whether it is important to have a
one-to-one mapping from X.500 names into UTF-8 strings.  Currently,
multiple values of X.500 names may map into the same UTF-8 string via
the RFC 2253 transformation.  These multiple values are likely to be
semantically equivalent, but I don't know if there are situations
where they may have distinct meanings.  This may cause difficulty in
looking up the relevant certificates or keys if they are indexed by
DER encodings of their DistinguishedName values, for instance.  Also
security problems may result if one RFC 2253 name can represent
multiple semantically different DistinguishedName values.

The transited encoding presents other problems.  The
DOMAIN-X500-COMPRESS encoding described in RFC 1510 and in
kerberos-clarifications only treats domain style realm names and X.500
names encoded in a non-RFC 2253 encoding.  Perhaps most
problematically, DOMAIN-X500-COMPRESS separates elements of the
traversal sequence by using the comma (",") character, while the RFC
2253 encoding instead uses the comma character to separate
RelativeDistinguishedName values in a DistinguishedName.  The X.500
name encoding in RFC 1510 and in kerberos-clarifications uses the
slash ("/") character to separate elements of a DistinguishedName,
which accounts for the usage of the slash character in the
DOMAIN-X500-COMPRESS.

I am not terribly familiar with the X.500 naming structure, but it
appears from examples in RFC 2253 that the ordering of
RelativeDistinguishedName values in a DistinguishedName goes from most
significant to least significant, and that the RFC 2253 encoding
deliberately reverses this ordering.  The X.500 realm naming scheme in
RFC 1510 and kerberos-clarifications seems to imply that the most
significant component of a DistinguishedName goes first in the
encoding.  Thus, even if the existing DOMAIN-X500-COMPRESS were
augmented to handle RFC 2253 encodings by way of mapping slash
characters in the "compressed" encoding to comma characters in the RFC
2253 encoding, the ordering would be incorrect.  Additionally, even if
the RFC 2253 encoding were converted completely to the realm name
format described in RFC 1510 and in kerberos-clarifications, that
format fails to accommodate multiple-valued RelativeDistnguishedName
values.

I'm not sure how this problem should be resolved.  It is possible that
pkinit will specify its own transited encoding, but there are numerous
backwards compatibility problems associated with that approach.

---Tom

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 19 Nov 2002 09:29:48 -0600

The other option is to not convert the name to a string, but to copy the 
ASN.1 name. from the certificate.  This would be a major change and impact
the transited field encoding, but  should be looked at, as it requires no 
mapping of conversion. Maybe for Extensions?

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 19 Nov 2002 10:33:01 -0500

Tom and I talked about this last night, but for the rest of the
audience:

Tom Yu <[email-masked]> writes:
> names encoded in a non-RFC 2253 encoding.

It doesn't optimize for "other"-type realm names; that just means you
can't do any "compression" of them in the general case.  (If you
happen to have two differing only by an additional trailing component
in one that starts with a "/", you can still compress.)

>   Perhaps most
> RelativeDistinguishedName values in a DistinguishedName.

DOMAIN-X500-COMPRESS uses a backslash to quote special characters,
including comma within a realm name.  So you'll get "a=b\,c=d".

>    The X.500

So, is our (1510/clarifications) X.500 style realm name actually
useful at all?  Should it be eliminated?

Ken