On Thu, Sep 11, 2003, Edward Lewis wrote: > At 2:52 +0200 9/12/03, Dr. Stephen Henson wrote: > >*However* the meaning of 'support' in the context of otherName is somewhat > >ambiguous. The actual value field can contain anything depending on the > >name > >field. > > Yeah. I'd settle with being able to give an OID in the dotted > decimal notation and the value in hex. That maybe a simplistic > opinion, but I figure I can build the application to take the data > from internal to hex and vice versa (possibly even in accordance to > ASN.1/?ER rules!). >
Well you'd have to specify the OID and the type. An OCTET STRING is fine for arbitrary hex data. 0.9.8 can support the encoding stuff but not decoding with the standard utilities. At an API level the relevant data is available to applications. > Has anyone thought of this - if I declare an OID to be "this data is > a pointer into my database" how do relying parties figure this out? > As in, is there some way to retrieve the ASN.1 rules/interpretation > at run time? Securely? > That's not something that's currently done in general. Its more common to give an indication somewhere of the meaning of the OID and have the corresponding value declare anything else. Its down to the implementor to then support it as they see fit. 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]
