Re: Distinguished names and X509v3 extension OIDs (fwd)

[Warwick Ford <[e-mail]>]

We certainly looked first at the more obvious options such as ANY DEFINED
BY and EXTERNAL but were forced to reject them.  I think what you are
saying you would prefer is essentially the ANY DEFINED BY option, i.e., (in
shorthand) SEQUENCE { oid, boolean, ANY DEFINED BY oid }.  (Actually this
would be done using table notation, but most readers probably are more
familiar with ANY DEFINED BY.)

>From recollection, the problem with the ANY DEFINED BY approach is as
follows.  Recall that a certificate is not necessarily transmitted
everywhere encoded in DER.  Some certificate-carrying protocols use
BER-encoding.  This is why a cert using system may need to regenerate the
DER encoding of the cert when verifying the signature.  Recall also that
intermediate systems through which a cert traverses may decode and recode
certs differently (e.g., if BER is in use, a system may re-encode a cert
with a different BER encoding than that in which it was received).  In the
case of an extension, such a change of encoding might occur in any system
that recognizes the extension OID and the corresponding ASN.1 type for the
extension value.

Now, when it comes to validating a cert, note that certs that contain
unrecognized extensions may still be perfectly valid and usable (provided
every unrecognized extension is flagged noncritical).  But, if it is
possible for the bit-representation of an unrecognized extension to have
changed in transit, how can the cert-using system generate the required
canonical encoding to verify the cert's signature?

The level of indirection gained through the OCTET STRING overcomes this
problem.  Intermediate systems are not permitted to change the encoding of
an extension at the inner level, since it is mandated to always be DER.
And changing the encoding of the octet string itself is not a problem as
you can always regenerate the DER encoding of an OCTET STRING.

Hope this helps,
Warwick (Ford)

At 09:53 AM 3/31/97 -0500, David P. Kemp wrote:
>The fact that extensions are octet strings is not SSLeay's fault. It
>was, IMHO, a faulty decision by the designers of X.509 v3.  It's
>probably too late to correct this decision now - lots of people
>have already written code to handle v3 certs with octet string extensions.
>But it would have been smarter for the extension contents to be the
>DER data directly, not an octet string containing DER data.  (Octet
>string would be a legitimate content type for some extensions, such
>as keys, hash values, or opaque non-ASN.1 objects such as Microsoft
>Word documents :-).
>
>John Larmouth (http://www.salford.ac.uk/iti/books/osi/chap8.html)
>has this to say about the "OCTETSTRING hole":
>
>  "... the application designer specifies a field as an ASN.1 octet
>  string for the purposes of defining his/her own abstract syntax,
>  then proceeds to populate the field with the encoding of an ASN.1
>  type ...  Use of this mechanism cannot be prevented by the Presentation
>  Layer or by ASN.1 (although text in the 1992 DIS deprecates this use of
>  OCTETSTRING), but clearly does not fit in any way with the spirit
>  of the presentation layer.   ...  The reader is ... asked to
>  avoid introducing such holes in any designs he/she becomes responsible
>  for!"
>
>
>X.509 designers, is there any chance of fixing the certificateExtension
>definition in the 1997 spec?

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [e-mail]; Tel: [phone] x225; Fax: [phone]
---------------------------------------------------------------------