Re: some concerns about last IKEv2 draft

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Thu, Sep 11, 2003 at 03:35:58PM +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    > 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.
> 
> => tagging IS needed.

Actually, Francis is right (but see below) - I had not noticed that
Theodore said "SEQUENCE OF CHOICE."  The I-D says:

"
      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.
"

which implies a SEQUENCE OF SEQUENCE, not SEQUENCE OF CHOICE;
this is because of the "and" in the last sentence.  I.e.,

Cert-Bundle ::= SEQUENCE OF SEQUENCE {
    cert    <some ASN.1 type for certificate - the I-D should be specific>,
    CRL	    <same other ASN.1 type for CRL - again, please specify>
}

Regardless of whether the I-D meant "SEQUENCE OF SEQUENCE" or "SEQUENCE
OF CHOICE" it is clear now to me that the I-D has to be a lot more
specific - it should even name the ASN.1 types (_and_ the OIDs for the
modules whence they are to be IMPORTed) for certificates and CRLs, even
if we're all supposed to know what they are (future readers may not).

Friends don't let friends underspecify.

>    Explicit tags are
>    optional in ASN.1, unless they are needed to create a non-ambiguous
>    encoding.
> 
> => tags (of any kind) are needed when the encoding is ambiguous,
> and it is the case here (a CHOICE between two SEQUENCEs).

Definitely, unless those sequences are explicitly tagged with, say, some
application tag (but I see that "Certificate" is NOT so tagged, for
example, even in PKIX1Explicit93

But the I-D wording suggests SEQUENCE OF SEQUENCE (without OPTIONAL
fields, I presume [see? a possibly bad assumption]), in which case
there's no ambiguity.

[...]
>    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.
>    
> => I can send to you *privately* the last ASN.1 documents (my telecom
> engineer school is a member of the ITU, I even have a minitel on my
> desk :-). But the current document is just a bit underspecified
> and we have to fix it. My proposal is designed to be as small as
> possible: ", respectively with implicit tags 0 and 1".

Er, the ASN.1 specs are OPEN and can be retrieved from the ITU-T site as
PDF documents.

>    P.S.  This confusion over the use of ASN.1 simply reinforces my
>    personal bias that "friends shouldn't let friends use ASN.1",
> 
> => so you should share my idea to introduce as little as possible ASN.1 (:-)!
> For instance I implicitly translate the English word "and" into the ASN.1
> CHOICE.

I myself do not.  Evidently the "certificate bundle" is structured data
whose encoding ought be specified, and ASN.1 is a perfectly appropriate
syntax for the purpose (and one of several).

I don't mean to say that you MUST use ASN.1, but that a well specified
encoding for the "certificate bundle" is needed.

Cheers,

Nico
--