Graham Leggett wrote: > In a typical client certificate scenario, you might verify that a certificate > chain is complete, not expired, and trusted by a root certificate. If you > were to choose a way to authorize the certificate over and above the check > that the cert is valid, you might store it's subject in a directory, and > compare that. > > I face a problem where I need to trust two client certificate trees, and > there is no guarantee that the subject of a certificate issued beneath the > first tree doesn't collide with the subject of a certificate in the second > tree, and so storing the subject isn't good enough any more. In the past you > might have stored and trusted the issuer, but given that certificate chains > can be of arbitrary depth this isn't good enough either. > > In theory I would need to store all the subjects of all the certificates in > the chain to unique identify that certificate where multiple independent CAs > are trusted, but I am struggling to find an existing standard way to encode > this list of subject names. Does such a thing exist? > > In theory I might encode the subjects of the certificate chain as > "subject=<escaped-subject-client-cert>, > subject=<escaped-subject-of-intermediate-cert>, > subject=<escaped-subject-of-root-cert>" and assign this to an LDAP attribute. > Lots of escaping though. > > Alternatively I might generate a hash (sha256?) of all the subjects, suitably > canonicalised (rfc2253?), although that is less readable.
Yupp. I'd calculate a fingerprint to distinguish the client certs. Maybe you'd rather want to map the client cert to an internal name and use this in your authz scheme. With such an approach your not tied to client certs as authc mech. > Has anyone done something like this before? E.g. OpenDJ (a LDAP server written in Java) has a built-in client-cert identity mapper based on fingerprints which searches an LDAP entry by client cert fingerprint. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
