I disagree with Mark's assertion that it is OK for entensions to be
BER encoded. As stated in the comment, it must be DER encoded. A CA that
is incapable of correctly generating the encoding for extensions should
be suspected of harboring other - security critical - bugs.
John
From pem-dev-request%neptune(_dot_)tis(_dot_)com(_at_)www(_dot_)tis(_dot_)com
Thu Jan 4 18:30 EST 1996
To: hoaly <hoa(_at_)rsa(_dot_)com>
Cc: pem-dev(_at_)TIS(_dot_)COM, M(_dot_)Wahl(_at_)isode(_dot_)com
Subject: Re: Certificate Extension Implementation
Date: Thu, 04 Jan 1996 17:24:23 -0600
From: Mark Wahl <M(_dot_)Wahl(_at_)isode(_dot_)com>
While I implement the Certificate Policies extension, an issue comes
up. If I'm given the DER encoding of the extension, and the policy
element information is not ordered as required for some reason.
Should this DER be considered invalid and rejected, or should I accept
it and do the ordering myself?
My feeling is that the comment next to the extnValue OCTET STRING
"contains a DER encoding of a value of type &ExtnType for the extension
object identified by extnId"
in TC #1 was primarily to simplify implementation of applications using
certificates, so that if certificates are available to it in DER encoding it
would not be required to implement anything of BER.
As the extnValue is wrapped and placed inside an OCTET STRING value, it is
protected from being decoded and then differently recoded by an intermediary
certificate server or database. Thus if there was an encoding of something
inside an extnValue that was not in the DER subset of BER, such as the
components of a multi-valued RDN not being in ascending order, it would
indicate a bug inside the CA software which issued that certificate. This
could perhaps be because a incorrect encoding of an extension value was
presented to a signing module, which simply placed it inside an OCTET STRING
and proceeded to DER-encode and sign the certificate. If the user
application
attempted to correct BER to DER _inside_ of the extnValue, in the same way as
it must do so for the elements of a Certificate value itself, the validiation
would in this case most likely fail.
While a user application would be correct in rejecting a certificate based on
a strict interpretation of this comment, I would not think that there would
be
any harm if an application capable of parsing it in BER made use of the
certificate and its extension information (logging a warning if it wished).
So long as the certificate with its OCTET STRINGs as presented verifies
correctly, I am not currently aware of a situation in which this 'liberality'
could be exploited to cause certificate contents to be undetectably modified.
------------------------------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)isode(_dot_)com; ISODE Consortium;
http://www.isode.com/