"Salz, Rich" <[EMAIL PROTECTED]> writes:
> >It won't always be the case that your directory structure will map
> >_exactly_ to your certificate heirarchy.
>
> So you need a general filtering of subjectDN to LDAPDN, I guess. We've
> come across this issue. Our circumstances are a little different from
> yours, since the product (here) is a repository, not using an external
> directory. So we can say things like "we will rewrite the DN to be
> c/o/ou/l/cn allowing multiple ou's and ignoring all other attrbiutes."
> Whereas your code probably has to allow flexibility in rewrite rules.
Yup, I want this to be able to work with any LDAP server out there and any
layout the user chooses.
> >But if you want to use something like Verisign to get your certificates,
> >their certs are pretty nasty looking and I would _not_ want my directory
> >to look like that. :)
>
> Yeah, the longer CA folks have been in business, the more they do things
> beyond the PKIX profile. (No surprise in that.)
>
> >Either as an RDN in the cert, or an extended attribute. Verisign's
> >low-assurance CA sticks your email in there.
>
> It's amazing what people put in their DN's. We've seen certs that have a
> copyright notice in them.
The Verisign certs have a great big comment in them about the
`Certification Practice Statement' - ~750 bytes of legalese. Gotta love
it.
> It's an interesting exercise to find the official oid of the email rdn. :)
My coworker who does all the serious crypto was just lamenting that fact on
the phone. :)
-Bill P.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
