Subject: [Ietf-krb-wg] PKU2U and X.500 principal names

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Nov 2007 11:37:27 -0500 (EST)

The current version of PKU2U (draft-zhu-pku2u-03.txt) specifies the use of
principal names of type NT-X500-PRINCIPAL as a fallback when no better
name can be derived from a certificate.  According to RFC4120, a principal
name of this type is derived from an X.500 DN by converting it to a string
as specified in RFC2253 (since obsoleted by RFC4514).  Unfortunately, the
specified transformation is not unique in either direction -- the same DN
may be encoded in multiple ways, and different DN's may encode to the same
string(*).  Specifically...

- RFC2253 section 2.3 indicates that attribute types should be encoded
  as strings when present in some table of attribute types, and as OID's
  otherwise, but fails to specify any particular such table (it makes
  reference to RFC2252, which does not include or refer to a table of
  attribute types).

- When there is no string representation for an attribute, the value
  is encoded "as an octothorpe character ('#' ASCII 35) followed by
  the hexadecimal representation of each of the bytes of the BER
  encoding of the X.500 AttributeValue"; however, BER is not a
  canonical encoding.

- If the attribute value does have a string representation, then that
  representation is used, converted to UTF-8.  However, there is no
  guarantee that all attribute types will have syntax which produces
  a unique encoding.

- When a string representation is used for an attribute value, there
  is an escaping mechanism which allows inclusion of characters that
  would otherwise be confused as syntactic elements, such as '+' or
  ','.  However, RFC2253 section 2.4 states "Implementations MAY escape
  other characters", which opens the door to non-unique encodings.

- When an RDN contains multiple AVA's, they are considered as a set
  and may be encoded in any order.

- RFC2253 section 7 describes additional considerations related to
  non-unique encodings of attribute values, particularly with regard
  to attribute values which use any of several string types.

If PKU2U or any other protocol is going to make use of NT-X500-PRINCIPAL,
I think we need to determine whether these ambiguities matter for Kerberos
principal names, and if so, what we are going to do about them.

I'd also like to here from working group participants on whether PKU2U's
specification of the encoding of these names is consistent with what was
intended in RFC4120.  Specifically, is the intent that names of this type
have only a single component which contains the entire DN?

-- Jeff

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg