On Mon, Mar 24, 2003, Naomaru Itoi wrote: > Thank you so much for the quick response, Steve. > > I tried -strparse 1366 and it actually knows it's UPN. > > OK ... so I think I understand this now. Since the data field of > subjectAltName is OCTET STRING, asn1parse doesn't try to parse it (because > it's just bunch of bytes). But if I force it to parse it by doing > -strparse, it actually understands it. (too many "it"s in this sentence) >
Not just subjectAltName but any extension... I suppose asn1parse could also be made to look inside OCTET STRINGs automatically if it looked like something sensible is in there. dumpasn1 already does this. > So this is totally fine with me. I can write a program which parses the > whole cert first, then re-parse the subjectAltName. > Well OpenSSL already has routines to parse a certificate into an X509 structure. The individual extensions can be decoded into machine friendly forms with the X509v3 code (see doc/openssl.txt et al). In the case of subjectAltName you get a STACK_OF(GENERAL_NAME) which can then processed appropriately. In the case of otherName you get an OID and an ASN1_TYPE structure which can be processed further. If however you are 'parsing' a certificate by parsing the output of things like the x509 or asn1parse utilities then that is a bad idea. The output of those utilities is meant to be human readable and not machine readable: that is their output format could change in future versions of OpenSSL. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
