Last Call Review of draft-turner-clearancesponsor-attribute-
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
(I would note for the record that I roped in Kurt Zeilenga to check
certain issues, but I nevertheless take full credit for any errors).
This is a straighforward definition of an attribute suitable for
X.509 certificates (either public key or attribute) or X.500/LDAP
directory entries which carries the name of the clearance sponsor,
that is, the entity which initiated and maintains the assignment of
I note that recent cases where a DirectoryName has been used with
X.509 for authentication - in particular usage of the CommonName of
the Subject Name - have been subjected to attacks using embedded
NULs. Whilst presumably using the correct equality matching rule
prevents this, it'd be nice to see that called out. (If the equality
matching rule does not prevent this case, that's obviously more
Mandating that NUL is not a valid codepoint in this attribute would
probably be useful, too.
It's not entirely clear to me why one would want to consider this as
part of an authorization check, unless one was attempting to match
the name of the sponsor against a list of "known good" sponsors -
that is, if a sponsor was subsequently revoked as a whole as being a
suitable sponsor, one might want the sponsored clearances to be
pulled as well. (It might be useful to note *why* one might want to
do this, within the draft).
However, it occurs to me that this kind of matching might be better
done against an OID, such as one from the Enterprise arc, rather than
a simple string, which might prove to be subject to human foibles.