Re: I-D ACTION:draft-ietf-smime-escertid-00.txt

[Dr Stephen Henson <lists@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Peter Gutmann wrote:

> "Denis Pinkas" <denis.pinkas@xxxxxxxx> writes:
> 
> 
>>The current ASN.1 in RFC 2634 is:
>>
>>  ESSCertID ::=  SEQUENCE {
>>       certHash                 Hash,
>>       issuerSerial             IssuerSerial OPTIONAL
>>  }
>>
>>The proposal from draft-ietf-smime-escertid-00.txt is:
>>
>>     ESSCertIDEx ::=  SEQUENCE {
>>          certHash                 Hash,
>>          hashAlg                  AlgorithmIdentifier DEFAULT {id-sha256},
>>          issuerSerial             IssuerSerial OPTIONAL
>>     }
>>
>>The proposal made on the PKIX mailing list is:
>>
>>ESSCertIDv2 ::= SEQUENCE {
>>   certHash         OCTET STRING,
>>   issuerSerial     IssuerSerial,
>>   hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 }
>>
>>The advantage of the last proposal is backward compatibility with the
>>existing structure. 
> 
> 
> No it isn't, you've lost the 'OPTIONAL' on issuerSerial, making it non-
> backwards-compatible.  If you want it to have the properties you claim it has,
> you'd need:
> 
> ESSCertIDv2 ::= SEQUENCE {
>     certHash         Hash,
>     issuerSerial     IssuerSerial OPTIONAL,
>     hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 }
> 

Well passing through those structures caught my attention.

Aren't they ambiguous and could possibly be rejected by ASN1 compilers
or parsers?

My reason being that the presence of DEFAULT/OPTIONAL fields is decided
by the tag and both IssuerSerial and AlgorithmIdentifier both have a
SEQUENCE tag.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@xxxxxxxxxxxxxxxxxxxxx, PGP key: via homepage.