Re: [CGA-EXT] Review draft-ietf-csi-proxy-send-01

[Roque Gagliano <[e-mail]>]

Julien,

You can even include Tonys text about "Signature Algorithm":
"
   Signature Algorithm

      A one-octet long field indicating a signature algorithm and the
      corresponding hash algorithm that this node supports; this support
      implies at least ability to verify signatures of this Signature
      Algorithm algorithm.

      If the first leftmost bit, bit 0, is set to 0, it indicates that
      the emitter is able to perform signature checks only (i.e. no
      signature generation with this type of signature algorithm).  If
      this bit is set to 1, it indicates that the emitter has a public
      key of this type and can generate signatures.  Bit 1 and 2 are
      reserved.  Bit 3 to 7 are named Signature Type Identifier subfield
      and encode an identifier for the signature algorithm and
      corresponding hash algorithm.  Default values for the Signature
      Type Identifier subfield defined in this document are taken in
      part from the IANA-defined numbers for the IKEv2 protocol, i.e.
      IANA registry named "IKEv2 Authentication Method":

      *  Value 0 is RSA/SHA-1 (compatible with [RFC3971])

      *  Value 1 is RSA/SHA-256

      *  Section 5 of document [cheneau-csi-ecc-sig-agility] provides
         values for ECDSA signature algorithm
"
Roque.

On Dec 10, 2009, at 1:09 AM, Roque Gagliano wrote:

> Hi Julian,
> 
>> 
>> So in terms of prefix I agree that you want to use right of use rather than ownership, but in terms of CG-addresses, IMHO we do want to say ownership.
>> 
> 
> The distinction is not so clear for me but I am fine with "no innovating". 
> 
>>> That is something I made clear in the CERT draft.
>> 
>> But the focus of the CERT draft is on delegating authorization to advertize/use prefixes or addresses that are NOT cryptographically generated, thus there's no ownership involved.
>> 
>>>> The lack of algorithm agility is generic to SEND and not specific to the Secure Proxy ND mechanism. When the WG concludes on how to move forward with algorithm agility, we can publish an RFC updating both RFC3971 and this to be RFC to add algorithm agility. 
>>> 
>>> So, we know there is a problem and probably know that SEC ADs are looking at these particular issues, however we would to advance this draft to the IESG hopping that it passes their LC with the promise to solve the issue later on? I only have been in CSI for a couple of months but does not sound proper IETF process to me.
>>> 
>>> The agility discussion also included a signaling between the parties in order to select which algorithm to use. What we can do while that discussion is not over in the WG is to make sure that new SEND options have the possibility of identifying which algorithms each party are using, leaving the signaling part for later. This is similar to DNSSEC where in order to change from SHA-1 to SHA-256 probably all signatures will be for a while duplicated in the zone files.
>> 
>> Would inclusion of an algorithm field in the PSO solve your concern?
> 
> IMHO, it will help to move the document through the next step.
> 
> Roque.
> 
>> --julien
> 
> -------------------------------------------------------------
> Roque Gagliano
> LACNIC
> [e-mail]
> GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE
> 

-------------------------------------------------------------
Roque Gagliano
LACNIC
[e-mail]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE