Ok, I guess we figured it out. First: the encoding used by verisign and openssl
is correct. Second: The SEQUENCE tag will even be missing if more than one
GeneralName is encoded in the distributionPointName.fullName. At least it is
using the snacc ASN.1 compiler. From the specs we deduce that the default
tagging in the PKIX asn1 definitions is IMPLICIT. So the syntax described in my
previous mail is incomplete, the complete syntax is
DistributionPointName ::= CHOICE {
fullName [0] IMPLICIT GeneralNames,
nameRelativeToCRLIssuer [1] IMPLICIT RelativeDistinguishedName }
causing the GeneralNames syntax for fullname to be implicitly assumed, and the
value field of fullName will be concatenated encodings of GeneralName items. If
we change that to EXPLICIT in the ASN.1 definition, the SEQUENCE OF encoding
appears even if there is only one GeneralName in fullname. That behaviour was
what we initially expected.
-----Urspr�ngliche Nachricht-----
Von: MIME:[EMAIL PROTECTED]
Gesendet am: Donnerstag, 9. September 1999 20:50
An: -:[EMAIL PROTECTED]; Olaf Schlueter
Betreff: Re: Encoding of crlDistributionPoints
Olaf Schlueter wrote:
>
> Looking at a Versign Certificate we stumbled today upon what we think is
> an non standard (should I say wrong ?) way of encoding
> crlDistributionPoint. We found that Openssl (using 0.9.3a for testing)
> displays and generates this extension in the same format, deviating from
> the specified standard syntax found in various specifications like
> (probably in the order of appearance): X.509, PKIX, Mailtrust V2, and
> SigI (the latter two specifications are german specifications derived
> from PKIX). The standard syntax is to encode crlDistributionPoints as
>
[description omitted]
>
> Or am I missing something ?
>
I've looked over the code that encodes cRLSistributionPoints and I can't
actually see the problem. It should be encoding GeneralNames.
Now what I'm thinking here is that because of the encoding rules:
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
if there is only one GeneralName in the SEQUENCE OF GeneralName,
will look the same as:
DistributionPointName ::= CHOICE {
fullName [0] GeneralName,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
In the first case the tag will be IMPLICIT and will thus "hide" the
SEQUENCE OF tag, it will be constructed because the underlying type is.
In the second case because GeneralName is a CHOICE type the tag will be
EXPLICIT and by definition constructed.
I may well be missing something myself here. ASN1 makes me feel ill at
times: though I'm told that is a natural reaction :-)
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
{\rtf1\ansi \deff0\deflang1024{\fonttbl{\f0\froman Tms Rmn;}{\f1\froman Symbol;}{\f2\fswiss Helv;}}
{\colortbl;\red0\green0\blue127;\red0\green127\blue0;\red0\green127\blue127;\red127\green0\blue0;
\red127\green0\blue127;\red127\green127\blue0;\red127\green127\blue127;;\red0\green0\blue255;
\red0\green255\blue0;\red0\green255\blue255;\red255\green0\blue0;\red255\green0\blue255;
\red255\green255\blue0;\red255\green255\blue255;}\paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440
\gutter0 \defformat\sectd \pard\plain {\plain \f0 \cb7 \cf0 [0] IMPLICIT GeneralNames,\
nameRelativeToCRLIssuer [1] IMPLICIT RelativeDistinguishedName \}\
\
causing the GeneralNames syntax for fullname to be implicitly assumed, and the\
value field of fullName will be concatenated encodings of GeneralName items. If\
we change that to EXPLICIT in the ASN.1 definition, the SEQUENCE OF encoding\
appears even if there is only one GeneralName in fullname. That behaviour was\
what we initially expected.\
\
-----Urspr\'81ngliche Nachricht-----\
Von: MIME:d in various specifications like\
> (probably in the order of appearance): X.509, PKIX, Mailtrust V2, and\
> SigI (the latter two specifications are german specifications derived\
> from PKIX). The standard syntax is to encode crlDistributionPoints as\
> \
[description omitted]\
> \
> Or am I missing something ?\
> \
\
I've looked over the code that encodes cRLSistributionPoints and I can't\
actually see the problem. It should be encoding GeneralNames.\
\
Now what I'm thinking here is that because of the enctag, it will be constructed because the underlying type is.\
\
In the second case because GeneralName is a CHOICE type the tag will be\
EXPLICIT and by definition constructed.\
\
I may well be missing something myself here. ASN1 makes me feel ill at\
times: though I'm told that is a natural reaction :-)\
\
Steve.\
-- \
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/\
Personal Email: [EMAIL PROTECTED] \
Senior crypto engineer, Celo Communications: http://www.celocom.com/\
Core developer of the OpenSSL project: http://www.openssl.org/\
Business Email: [EMAIL PROTECTED] PGP key: via homepage.\
\
______________________________________________________________________\
OpenSSL Project http://www.openssl.org\
Development Mailing List [EMAIL PROTECTED]\
Automated List Manager [EMAIL PROTECTED]\
\
h-consultancy.demon.co.uk \
Senior crypto engineer, Celo Communications: http://www.celocom.com/\
Core developer of the OpenSSL project: http://www.openssl.org/\
Business Email: [EMAIL PROTECTED] PGP key: via homepage.\
\
______________________________________________________________________\
OpenSSL Project http://www.openssl.org\
Development Mailing List [EMAIL PROTECTED]\
Automated List Manager [EMAIL PROTECTED]\
\
h-consultancy.demon.co.uk \
Senior crypto engineer, Celo Communications: http://www.celocom.com/\
Core developer of the OpenSSL project: http://www.openssl.org/\
Business Email: [EMAIL PROTECTED] PGP key: via homepage.\
\
______________________________________________________________________\
OpenSSL Project http://www.openssl.org\
Development Mailing List [EMAIL PROTECTED]\
Automated List Manager [EMAIL PROTECTED]\
\
h-consultancy.demon.co.uk \
Senior crypto engineer, Celo Communications: http://www.celocom.com/\
Core developer of the OpenSSL project: http://www.openssl.org/\
Business Email: [EMAIL PROTECTED] PGP key: via homepage.\
\
______________________________________________________________________\
OpenSSL Project http://www.openssl.org\
Development Mailing List [EMAIL PROTECTED]\
Automated List Manager [EMAIL PROTECTED]\
\
\par }}l
