Re: Distinguished names and X509v3 extension OIDs (fwd)

[[e-mail] (David P. Kemp)]

> From [e-mail] Mon Mar 31 16:45:05 1997
>
> 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 }.

Yes.

> 
> >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)


Warwick,
  Thanks for the cogent explanation - it helps to understand the rationale.
I'll have to think some more about the conclusion though.

I believe that it is always possible for BER/CER/DER software, having
no knowledge of specific extensions, or even of the X.509 certificate
structure itself, to take an arbitrarily-coded BER structure and recode
it in DER.  It certainly seems to be true for the elements commonly
found in certificates (UNIVERSAL and CONTEXT elements).  It should also
be true for APPLICATION and PRIVATE elements, because the DER
restriction rules are not specified for them: if an APPLICATION element
has two different BER encodings (not counting differences in UNIVERSAL
subelements) then it also has two different DER encodings, therefore
that particular APPLICATION element cannot be used in the signed
portion of a certificate.

If anyone has a counterexample - a BER transfer string that cannot
be converted to DER without knowledge of the ASN.1 definition, I'd
like to see it.

Thanks,

   Dave Kemp