From: Steve Kent <kent(_at_)BBN(_dot_)COM>
I have a hard time imagining any attribute that has a DN as a val[u]e being a
good candidate for an RDN.
A counterexample from MHS-DS: RDNs of entries in the MTA-MTA bilateral
agreement tables have values which are the MTA's DN.
Are you really comfortable suggesting such constructs?
I am more comfortable with putting a DN with a RDN component whose syntax is
DN into the subject field of a X.509 certificate than adding roleOccupant and
disclaimers in the X.509 certificate definition. I would be much happier
though, from a naming and usage POV, with attribute certificates for
holding signed undistinguished values, such that in this example the RDN
component would just be the name of the role cn="Vice President", and
there would be attributes in that role's entry for roleOccupant, disclaimer
&c. also signed by the CA.
What does the DIT look like under such circumstances?
If not using attribute certificates, then for example, in the level under
ou=Accounting, o=Foo Incorporated, c=US
the role might have an RDN of three components:
cn="Vice President" % objectClass=organizationalRole % \
roleOccupant="cn=John Smith, ou=Accounting, o=Foo Incorporated,c=US"
If attribute certificates are available, then the role could perhaps just be
named by cn="Vice President".
The entry named by this DN would have a userCertificate containing the
public key of the role. The corresponding private key would probably be
'owned' by the organization. Additionally, the purported roleOccupant with
RDN cn="John Smith" would probably also have a userCertificate containing
the public key, whose private key might possibly be 'owned' by the person.
-------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)isode(_dot_)com; ISODE Consortium