Re: some concerns about last IKEv2 draft

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Sep 10, 2003 at 01:54:49PM -0700, Nicolas Williams wrote:
> On Wed, Sep 10, 2003 at 06:30:19PM +0200, Francis Dupont wrote:
> > I have some concerns about the draft-ietf-ipsec-ikev2-10.txt document:
> > 
> >  - in 3.6 Certificate Payload:
> > 
> >       Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of
> >       a PKIX certificate bundle followed by a variable length URL the
> >       resolves to the BER encoded certificate bundle itself. The bundle
> >       is a BER encoded SEQUENCE of certificates and CRLs.
> > 
> >  => this is an underspecified ASN.1 type: some tagging is needed,
> >     for instance by adding:
> >     ", respectively with implicit tags 0 and 1".
> 
> To be fair to the draft, it didn't claim that this is an ASN.1 type, it
> just specifies the use of BER.
> 
> That said, there are at least to problems here: a) the first sentence of
> the paragraph you quote is grammatically incorrect and b) it should use
> DER or CER instead of BER (since there's multiple ways to encode an ASN.1
> SEQUENCE in BER, but one should generally use a definite encoding to
> encode inputs to hash functions).

The grammatical typo can easily be fixed, either now or during last
call.

While you are right that the use of DER or CER is preferred for data
structures which are digitally signed, as it simplifies certain
implementations that may decide to decode and then re-encode a
particular ASN.1 stream, it certainly isn't required.  In this
particular case, I very much doubt it will cause any real problems to
an implementation, since the simplest and easiest implementation
strategy will be to verify the hash immediately after downloading the
certificate bundle specified by the URL, and before separating it into
its component certificates and CRL's.  

Note that certificates and CRL's are themselves self-verifying data,
so the hash is really more of a sanity check to make sure the correct
bundle was downloaded as opposed to being seriously needed for the
security of the protocol.

> Further, it would be preferable to give the ASN.1 syntax for this
> SEQUENCE, which means getting the tagging right, as you point out.

As I said earlier, no tagging is really needed.  Explicit tags are
optional in ASN.1, unless they are needed to create a non-ambiguous
encoding.  However, with either DER or BER, the types of the
underlying definition of Certificate and CRL are not ambiguous, which
means that this is perfectly legal ASN.1:

	SEQUENCE OF CHOICE { X509-CERTIFICATE, X509-CRL };

Perhaps some ASN.1 geeks would feel that this is clearer than the
current English that is there now, but personally, I'm not at all
convinced.

							- Ted

P.S.  This confusion over the use of ASN.1 simply reinforces my
personal bias that "friends shouldn't let friends use ASN.1", but it's
far too late in the process to be making changes that basically boil
down to arguments over preferred ("bits on the wire") packet formats.