On Mon, Mar 22, 1999 at 11:34:48PM +0000, Alicia da Conceicao wrote:
> Greetings:
>
> Is it possible to add additional customized fields to the DN (Distinguished
> Name) of a standard X509 certificate. Since the DN appears as text, with
> fields delimited by the forward slash character '/', in the subject of the
> X509 certificate, it should be easy enough to adds these extra fields.
>
> For example, the DN in my personal certificate is:
>
> /C=CA/ST=Ontario/L=Toronto/O=CyberStation Inc./OU=
> /CN=Alicia da [EMAIL PROTECTED]
>
> And if we add a new field for my telephone number "/T=416-860-9378" to my
> DN:
> /C=CA/ST=Ontario/L=Toronto/O=CyberStation Inc./OU=/T=416-860-9378
> /CN=Alicia da [EMAIL PROTECTED]
I assume that you realize that the above X.400-style representation
doesn't mean anything to the DER-encoded cert.
I think that X.509 cert RDNs support all the X.520 name tag OIDs. There
is an OID for telephone number. I don't know what the X.400 ascii
translation for telephoneNumber is, it could well be T=<number>.
> or if we add it to the end of the DN:
>
> /C=CA/ST=Ontario/L=Toronto/O=CyberStation Inc./OU=
> /CN=Alicia da [EMAIL PROTECTED]/T=416-860-9378
I think that ordering is irrelevant in RDNs.
> Are any of the above "extended" DN's valid?
Since there's a valid X.520 OID for telephoneNumber, I think that it
would be valid in X.509. It's been a while since I read X.509 but I
think that you can put any valid X.520 OIDs into an RDN in a X.509 cert.
The question then is whether the X.509 code you're dealing with to
make/decode certs understands that OID in an RDN. The code that I
have written for various people that decodes X.509 would deal with
a telephoneNumber field but I don't know about other people's code.
> Would the X509 certificates
> that contain these DN's still be valid certs? Instead of adding fields
> to the DN's, would it be better to add extra fields within an extention
> to the X509 certificate (like the extra netscape fields like "nsCertType")?
I think that you should put it into the RDN since there's a tag for it.
But the general trend these days seems to be to use v3 extensions for
just about everything, even data that could have a valid place in
the cert body. So perhaps other people will disagree with me.
> Thank you in advance. Sincerely, Alicia.
>
> PS. If it possible to safely add extra fields to a client certificate, then
> is it also possible with SSL3 or TLS to only allow those client
> certificates to be submitted in an encrypted manner, to a SSL
> server, after the client application first validates the server
> certificate? That way, the client's certificate can contain private
> data in its fields that only trusted servers are allowed to see.
> (This is method would be very useful for decentralized databasing.)
Arrgh!
Don't even think that. The whole point of a cert is to authenticate
party A to party B when they don't already know each other and have
a common party (the CA) which they trust. They're meant to be widely
distributed, so that anyone who wished to communicate with you
(and who trusts the same CAs you do) can do so. You _have_ to be
able to distribute your certificates widely in order for them to
do any good at all. If your model says that you only need to distribute
certs to a select closed group, then you probably don't need certs
at all and can use something like AADS.
Putting private data into a cert means that you can't distribute it
widely, you have to authenticate the person you're going to send your
cert to to make sure that it's ok to send the private data to
them. But how can you do this without a cert? You can't! It's why
certs were invented in the first place!
It'd be much better to keep your private data out of the certs and send
it after the cert exchange/mutual authentication has occured. Since
this is an SSL list, I'd say that you should let the SSL session
negotiation occurr and _then_ send your private data. That way it's
automatically encrypted and authenticated.
--
Eric Murray N*Able Technologies www.nabletech.com
(email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
