Re: some concerns about last IKEv2 draft

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

 In your previous mail you wrote:

   > 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.
   
=> please help the poor (:-) editor: propose a new wording asap!

   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.
   
=> I agree: DER will be common but we have not to mandate it.

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

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

   However, with either DER or BER, the types of the
   underlying definition of Certificate and CRL are not ambiguous,

=> there are not ambiguous but they are the SAME.

   which means that this is perfectly legal ASN.1:
   
   	SEQUENCE OF CHOICE { X509-CERTIFICATE, X509-CRL };
   
=> this is legal ASN.1 only when automatic tagging is selected.
As it is not the case (automatic tagging is not the default),
some kind of tagging (explicit, implicit or automatic) is needed.

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

   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.

Thanks

Francis.Dupont@enst-bretagne.fr