Re: [pkix] Self-issued certificates

["Miller, Timothy J." <[e-mail]>]

Welcome to directories.  Please check your common sense at the door.  :)

The fact that the DN in my cert and my user account DN in, say, Active Directory aren't the same isn't a problem because (a) one of my SANs is probably set for AD--e.g., UPN, and (b) most code doesn't force them to be consistent anyway.

In effect, when I load a cert into userCertificate or userSMIMECertificate the directory is binding that cert to that directory identity.  That's technically separate from the identity the CA was binding into the cert because the CA is using a separate directory.  This is a necessary consequence of multiple independent DITs.  Yay!

Are the different names different identities?  It depends.  If you consider only the computer's POV, then yes, they may be separate identities depending on the processing being done.  If you take a meatspace POV, then the answer is "not necessarily."

The only real identity that matters is "keyholder."  If I control the private key bound to any name--DN, SAN, account name, doesn't matter--then I *am* that identity for all computational intents and purposes.  If this doesn't align with meatspace, well, too bad.  The only binding between a key and a bag o' meat is the private key container--this is a big reason why we use smartcards (though under certain conditions even this binding can be invalidated--see Balfanz and Felton, 1999).

-- T

> -----Original Message-----
> From: Erik Andersen [mailto:[e-mail]]
> Sent: Tuesday, July 14, 2015 7:30 AM
> To: Miller, Timothy J.; [e-mail]
> Subject: SV: [pkix] Self-issued certificates
> 
> Hi Timothy,
> 
> I understand what you are saying and agree that the name is the thing.
> However, the model is not that clear. Attributes may be stored in a directory
> entry either in X.500 or LDAP.
> 
> The X.500 definition is:
> 
> 11.2.1	User certificate attribute
> A user may obtain one or more public-key certificates from one or more CAs.
> The userCertificate attribute type contains the end-entity public-key
> certificates a user has obtained from one or more CAs.
> 
> userCertificate ATTRIBUTE ::= {
>   WITH SYNTAX             Certificate
>   EQUALITY MATCHING RULE  certificateExactMatch
>   ID                      id-at-userCertificate }
> 
> The RFC  4523 defines an equivalent one for LDAP.
> 
> The  object class needed for defining directory entries is:
> 
> 11.1.1	PKI user object class
> The PKI user object class is used in defining entries for objects that may be
> the subject of public-key certificates.
> 
> pkiUser OBJECT-CLASS ::= {
>   SUBCLASS OF  {top}
>   KIND         auxiliary
>   MAY CONTAIN  {userCertificate}
>   ID           id-oc-pkiUser }
> 
> As it an auxiliary object class, it has no associated name form, but it might be
> combined with a structural object class that has a name form different from
> the name form used in any subject name.
> 
> If I get end-entity certificates from different CAs, they may not have the
> same subject name. Are they then different entities? At least they may be
> contained in the same directory entry.
> 
> By the way, I never believed in a single DIT, which made me a apostasy of a
> religious belief at the time. I was closed to being crucified.
> 
> -----Oprindelig meddelelse-----
> Fra: Miller, Timothy J. [mailto:[e-mail]]
> Sendt: 13 July 2015 16:42
> Til: Erik Andersen; [e-mail]
> Emne: RE: [pkix] Self-issued certificates
> 
> > I am not sure how the first paragraph leads to the second paragraph.
> > Where is that stated in RFC 5280 or X.509?
> 
> It's not stated, it's legacy.  Originally the DN was supposed to be the entity's
> location in the imaginary X.500 directory.  Two different DNs == two different
> locations, and therefore two different entities (because X.500 had a single
> DIT).
> 
> In short, the name--in X.509 and PKIX--*is* the thing.
> 
> This may seem like a philosophical issue but is has real implications.  In access
> control systems, once the user's authenticator is verified, the user's public
> key is discarded and the system uses the name (usually by binding that name
> to a proprietary access credential, e.g., a cookie).  This behavior is common to
> most PK-enabled systems, though the use of the DN is no longer exclusive
> (we have SANs now).  Change the name--even if the same key is bound to it-
> -and you'll lose access.  Try it with a PK-enabled website.
> 
> Similarly with S/MIME--change the relevant name (here the SAN
> rfc822Name), and the email won't verify.
> 
> -- T