[dtn-security] Re(4): Bundle Security Protocol details

["Peter Lovell" <[e-mail]>]

Hi Susan,


>>My interpretation is that the source, destination and security
>>are compound fields, as suggested by having a single bit for 
>>each. As such, security-result-length and security-result
>>would both be in the first block (res bit set) or both be
>>in the second (res bit off).
>
>Yes, I agree.

I suggest that we clarify the language to indicate that "security
result" is a compound field, consisting of "security result length" and
"security result data". The phrase "security result" refers to the
compound field.

Bit 11 ("res" bit) indicates whether or not the "security result" (length
+data) is in a block (bit is set) or not (bit is zero). Length+data
always go together and are never split.



>>In addition, there is no requirement that the
>>security-result-length be known in advance. Of course, 
>>in many cases it will be but I'm not aware
>>that it is required to be. 
>
>Well I've been assuming it is always known in advance.
>Is this an invalid assumption?

I don't think it's invalid, it's just that I had not also made that
assumption. 

I don't know of a digest mechanism which produces results which vary in
length but I can imagine that there are some. 

>>If the security-result-length is included in the canonicalization
>>then it must be fixed before any digesting begins. If it is not
>>fixed, then canonicalization must exclude the security result data
>>(as it already does), the security result length (because it is
>>size known since it's SDNV) and the block-length field must be
>>not known, nor is its adjusted to exclude the size for these two.
>>
>>If we digest the length field than it can't ever be variable-length.
>>
>
>Why can't it be variable length?  

The problem comes if you have multiple BA blocks. Not the "split block"
kind, but where there are multiple BAs for some reason, such as key-
rollover or whatever. Which one do you canonicalize first and what value
can you use for the length of the second, if you don't know that until
you do the second?

The answer is that you can't do this unless the lengths for ALL BAs are
known before you start digesting for ANY of them. And these lengths also
are part of the overall block length for each block.

Since I didn't want to preclude variable-length, and also because it
seemed that "security result" intended to mean "length+data", I had
thought to exclude both parts of that field from canonicalization.

However, I don't think this is a big deal. If we require fixed length
then that's OK with me. We just need to clarify what we mean.


>>>2. The new "security result offset" field that is being suggested
>>>should indicte the offset of the start of the security result field
>>>(not of the security result length field).

In line with the definition suggested at the top, I prefer that it point
to the start of the "security result" field and not the start of the
data field ["security result data"]. This is the same start point as the
length field["security result length"], of course.


Thanks.....Peter