Re: some concerns about last IKEv2 draft

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   > => from RFC 3280: cert = Certificate and CRL = CertificateList
   
   The I-D MUST state so.
   
=> the I-D says PKIX certificates and CRLs. There is no ambiguity
at all, mainly because of the "PKIX" word.

   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.
   
=> the problem is a formal language can be very boring.
Two other remarks:
 - we don't need the abstract syntax, only the concrete data layout.
 - most of the other CERT types are very underspecified, for instance
   the DNS Signed Key...

   >    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 ::=

=> I prefer IMPLICIT tagging (which gives shorter encoding).

   BEGIN
   
   IMPORTS Certificate, CertificateList FROM PKIX1Explicit93
   -- or from PKIX1Explicit88, which is what's in rfc3280
   
=> we have the choice between PKIX{Explicit,Implicit}88 if we use
only the RFC 3280.

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

=> the names of the field (cert and crl) are examples of overspecification:
they are not needed for interoperability, only by ASN.1.

   CertificateBundle ::= SEQUENCE OF CertificateOrCRL
   
   END
   
   Now how is this too much ASN.1?
   
=> I have no trouble with ASN.1, let the WG decide how much of ASN.1
it can eat.

   I to am glad that you're wrong on this:
   
   http://www.itu.int/ITU-T/studygroups/com17/languages/

=> very fine!
   
   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).
   
=> thanks

Francis.Dupont@enst-bretagne.fr