Re: some concerns about last IKEv2 draft

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

On Thu, Sep 11, 2003 at 07:24:51PM +0200, Francis Dupont wrote:
>    which implies a SEQUENCE OF SEQUENCE, not SEQUENCE OF CHOICE;
>    this is because of the "and" in the last sentence.  I.e.,
>    
> => I have a private message from the author where he confirmed he means
> a CHOICE (I can develop type theory arguments explaining why but
> this is not the place. Note that as soon as we reach a common understanding
> in the list we ne more need to ultraclarify the point in the document).

Good, now let's clarify.

>    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>
> 
> => from RFC 3280: cert = Certificate and CRL = CertificateList

The I-D MUST state so.

>    }
>    
> => I strongly disagree with the SEQUENCE OF SEQUENCE interpretation,
> the text is "SEQUENCE of certificates and CRLs", not "SEQUENCE of
> certificate and CRL pairs". I.e., the each element of the SEQUENCE is
> a certificate (PKIX certificates and CRLs are well defined, perhaps
> a reference to RFC 3280 is missing in the paragraph) or a CRL.

This merely proves that it's easier to disagree about the meaning of
English language text than it is to disagree about the meaning of a
specification written in a formal language.

>    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).
>    
> => no, too much ASN.1 is not a good idea.

This is not too much - and we've seen the confusion and incorrect
specification that results from too little.

DEFINITION EXPLICIT TAGS ::=
BEGIN

IMPORTS Certificate, CertificateList FROM PKIX1Explicit93
-- or from PKIX1Explicit88, which is what's in rfc3280

CertificateOrCRL ::= CHOICE {
    cert [0] Certificate,
    crl  [1] CertificateList
}
CertificateBundle ::= SEQUENCE OF CertificateOrCRL

END

Now how is this too much ASN.1?

>    Friends don't let friends underspecify.
>    
> => the only real issue is in fact the type of tagging.

No, I misundertood the English language description of "certificate
bundle" but would not have misunderstood the above ASN.1 module.

>    >    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
>    
> => no PKIX or X.509 stuff uses application tags.

Sure, but by not specifying what the CHOICE alternatives' types are or
where they come from one cannot know for sure if the CHOICE is
ambiguous, which is why it's proper for the I-D to be explicit.

>    Er, the ASN.1 specs are OPEN and can be retrieved from the ITU-T site as
>    PDF documents.
>    
> => freely retrieved? I know there are freely available somewhere but
> not at the ITU-T site (note that I'd like to be wrong :-).

I to am glad that you're wrong on this:

http://www.itu.int/ITU-T/studygroups/com17/languages/

>    > 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).
>    
> => There is not several ways to put certificates and CRLs in a SEQUENCE:
>  - SEQUENCE of CHOICEs (SEQUENCE OF CHOICE { cert, CRL })
>  - SEQUENCE of SEQUENCEs (SEQUENCE { SEQUENCE OF cert, SEQUENCE OF CRL})
> I know that it is the first one because when I asked why not use a SET
> of CHOICEs, Paul Hoffman confirmed it and gave an argument (reordering
> issue with SETs for people whose encoder always does DER) against SETs.
> 
>    I don't mean to say that you MUST use ASN.1, but that a well specified
>    encoding for the "certificate bundle" is needed.
>    
> => if you really believe the CHOICE interpretation is not so clear,
> what about ", respectively with implicit tags 0 and 1 in CHOICEs"?

I think the ASN.1 module given above is quite simple, easy to read and
clear, clearer than English language text.

If you insist on an English language description of the encoding of
"certificate bundle" then let me suggest:

   The bundle is encoded as the BER [X.690] encoding of an ASN.1 [X.680]
   SEQUENCE OF CHOICE where the choices are the Certificate and
   CertificateList types from PKIX1Explicit93 [or 88] explicitly tagged
   with context tags 0 and 1, respectively.

Please ensure the presence of _normative_ references to X.680 (ASN.1)
and X.690 (BER).

Cheers,

Nico
--