[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some concerns about last IKEv2 draft



 In your previous mail you wrote:

   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.,
   
=> 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).

   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

   }
   
=> 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.

   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.

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

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

   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.
   
=> if the fields are not optional then they are mandatory so they comes
by pairs of a certificate and a CRL. If they are optional then at least
a tag is needed and the difference with a CHOICE is limited...

   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 :-).

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

Thanks

Francis.Dupont@enst-bretagne.fr