[Mobopts] Re: Comments on draft-kempf-mobopts-ringsig-ndproxy-02.txt

James Kempf wrote:

>>>        If a multi-CGA capable node receives a message with a 
>>> standard RFC 3971 RSA Signature Option but the CGA Parameters Option 
>>> contains an RST Ring Signature Key Suboption, the node SHOULD ignore 
>>> the RST Ring Signature Option and treat the message like a standard 
>>> RFC 3791 SEND-
>>>        secured message. The node SHOULD use the standard RSA 
>>> signature verification algorithm and the key in the Public Key Field 
>>> of the CGA Parameters Option to verify the signature.
>>
>> Ignore? As in delete it from the contents of the CGA Parameters
>> Option, or keep it there but not do anything special for it?
>>
>
> RFC 3972 requires extensions to the CGA Parameters option to be 
> concatenated into the calculation for verification. So what I think 
> needs to be done is that, for the purposes of verification, it should 
> not be included in the calculation.
>
> This part of RFC 3972 may need some attention. I don't remember what 
> Tuomas and the WG had in mind with this, but the extensions field is 
> underspecified. If it is treated like a standard protocol extension 
> field, there will be TLV values for the extensions, and this is how 
> the multi-key CGA draft treats it. But the way it is incorporated into 
> the verification calculations implies that it is rather some bits that 
> don't have any specific field-like structure or any identifying 
> information as to what the extension is. Should such TLV bits be 
> included into the calculation? They aren't for the base key, 3792 
> specifies specifically when the encoded public key is used (c.f. 
> Section 4, Step 2).

This is what RFC 3972 says:

   Note that the hash values are computed
   over the entire CGA Parameters data structure, including any
   unrecognized extension fields.

Now, the field itself is underspecified although its usage in the
address calculation is clear (above). What we would probably need
to do is to specify first a TLV structure for the extensions, and
then one extension for the purposes of MCGA. But I don't
think we need to touch the calculation rules.

Btw, it seems that if the host's key is in the place where it
should be according to RFC 3972, the other keys are in
the extensions, you could easily use the RSA Signature, too,
as long as you are not currently proxying -- just sign with
the host's key. Of course you'd lose your privacy property.
But I thought I'd mention this because it may affect whether
you really want a new CGA type value or not.

--Jari

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts