Subject: issue 54 - pekka's technical issues

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 10:45:24 +0200

Thanks for the comments. I think I took into account all of
them except for the following:

- Pad length being unnecessary. The pad lengths are explicit since
   there are variable length fields. For instance, the Trust Anchor
   option has a name which may end at an 8-octet boundary. We could pad
   with zero bytes, but I feel better about an explicit pad length
   field. Similarly, the Signature and Certificate options have
   complicated ASN.1 data, and it may be easier to have an explicit
   field than to determine it from the encoding of a field.

- Nonces being required for senders but the lack of a nonce can in
   some cases be ignored by receivers. I was unsure about this
   one. Perhaps Pekka N can explain as this part of the text came from
   him, I think. But I would classify this under "be conservative what
   you send, liberal what you accept".

- IPR notices applying to an old draft version and name.  I know. I
   can not speak for others but I like to avoid going to the IPR
   department more often than really necessary ;-). Since we are about
   to finish the SEND protocol and there are no more draft renamings (I
   hope!) I now go and ask for an update of the IPR notice too.

See the new text in

   http://www.arkko.com/publications/send/issues/issue54diff.html

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Feb 2004 10:50:46 +0200

>   you send, liberal what you accept".

I'm sorry but I don't remember the details any more, and
don't have time to dive in right now.  I guess your
explanation, Jari, is the right one.

--Pekka N.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Feb 2004 16:55:54 +0200 (EET)

Hi,

>    field than to determine it from the encoding of a field.

I'm not sure if I understand your reasoning.  You seem to be saying 
that it's important to get the exact length of the ASN.1 encoded data, 
before decoding the data.  Note that you can already get the rough 
estimate -- which is enough e.g. for buffer allocation purposes, I'd 
guess -- from Length field; this will include 0-7 bytes of zero 
padding at the end.

I certainly don't see problems with implicit zero padding when the
data falls on alignment boundaries; I think using such is extremely 
commonplace in IETF specs.

So, I still think that Pad Length appears to be unnecessary.  On the
other hand, it MIGHT be necessary if you would have to be able to
allocate the exact size of memory for storing the data before decoding
the data.  But 0-7 bytes of overhead here doesn't seem to be worth the
trouble..

>    you send, liberal what you accept".

Fine with me.
 
>    hope!) I now go and ask for an update of the IPR notice too.

OK.  Note that I'm actually hoping that there would NOT be IPR claims
anymore -- as CGA stuff has been moved to a separate document, there
shouldn't be any, right?

If there is, it would be helpful to know which sections these pertain 
to (CGA parts or something else).

So, this is IMHO actually a pretty important thing to do.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Feb 2004 17:49:00 +0200

> the data.  But 0-7 bytes of overhead here doesn't seem to be worth the

My thinking was not based on buffer allocations. I agree that those
are a non-issue. I was mainly thinking of how to find the end of a
field followed by implicit padding. For instance, I'm was sure
if the zero byte appears in some international character set schemes.
But I guess not, that would break all C programs ;-) Anyway, zeros
can appear in ASN.1 and binary encoded data. The question is thefore which of
the following cases we have:

   (1) Variable length field has no length indication, explicitly or
       implicitly. In this case we must provide the length field either
       for this or for the padding that cames after it.

   (2) There is length information embedded in e.g. the ASN.1 encoding.
       In this case we can have either (a) length in the ASN.1 level
       only or (b) length in both the ASN.1 and our packet level.

I think you are saying that you'd prefer (2a) over (2b). I think I
agree on that now. I just would like to be assured that we don't have
case (1) anywhere. Anyone familiar with the encoding of digital signatures
care to comment?

>>   you send, liberal what you accept".

Great!

> So, this is IMHO actually a pretty important thing to do.

I have requested an update.

--Jari