Bonjour, On Thu, 3 Jun 2004, Dr. Stephen Henson wrote:
> On Thu, Jun 03, 2004, Erwann Abalea wrote: > > > I was looking at the RFC3739 for Qualified Certificates and the changes > > with the RFC3039, and noticed (among other things) that the example > > certificate changed. > > What makes you think it has changed? My fault, I must have been reading an older draft of the RFC3039, and I haven't checked the definitive version. > > The subject of this certificat has 3 RDN, and the last one has 2 > > "AttributeTypeAndValue" fields. > > > > When OpenSSL reads this certificate, it stores the subject as a sequence > > of 4 RDN, each one having only one AttributeTypeAndValue field. When you > > store it back, the certificate has changed, of course, and that is Bad > > (tm). > > Well OpenSSL seems to recognize that DN properly. If you include: > -nameopt oneline > for example in the 'x509' command line it will correctly display the last RDN. Well. My fault again, I haven't played with the -nameopt option yet. Now I've read the man page, it appears that not specifying the good -nameopt option results in OpenSSL using the same separator for several AVA of the same RDN as for several RDN, which confused me. And let me add another 'my fault' for having written that a certificate read and stored again was changed. OpenSSL did its job properly, but on the first file a trailing 0xa0 (*not* 0x0a) was present that wasn't part of the certificate. I don't know where it came from. I'm dumb :( > If you look at the internals of how this is stored it does at first sight > appear to only store the lot in a single sequence. The structure used is an > X509_NAME which includes a STACK_OF(X509_NAME_ENTRY) however each > X509_NAME_ENTRY has a field called 'set' which indicates which set the > AttributeTypeAndValue should be in. Thanks for the explanations. I looked at the code and the X509_NAME_add_entry man page, and with your explanations, it is much more clearer. So in a case where I have a multivalued RDN, if I want to sort the DN, the comparison function must be carefully written, since the 'set' can only have values -1 or 1, telling the library that this AVA belongs to the previous or the next set of AVA (or 0, of course, if the AVA is alone in its own RDN). Well. I won't sort DNs for the moment. > OpenSSL wont normally reencode DNs at all because it caches the original > encoding. If the DN is modified in some way it will of course be reencoded > though. Thanks. I'm using OpenSSL professionaly since the SSLeay days, and I'm still learning new stuff everytime. Keep doing a good work. -- Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5 ----- If you can't beat your computer at chess, try kickboxing. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
