Tony Cheneau wrote: > > Hello Julien, > > > On Fri, 21 May 2010, Laganier, Julien wrote: > > [...] > > FWIW - a strawman that seems to fulfill simpler requirements would > > be: > > > > - define NewSignature and NewCGA options that include the algorithm > > in use and are used in place of CGA and RSA Signature options when the > > algorithm in use is not RSA. > > I would need several clarifications on this sentence: > - I do not see why we should define a NewCGA option. RFC 3971 defines a > CGA Option that carries a CGA PDS (defined in RFC 3972) that is > agnostic of the Public Key type. As long as the Public Key can be > formatted as a DER-encoded ASN.1 structure of type > SubjectPublicKeyInfo, this is not a problem. Did I miss something ?
If the public key algorithm in use is signaled elsewhere (e.g. via an algorithm field in the NewSignature option) then it seems that current CGA option would be enough. > - concerning the NewSignature, do you think we should define a new one > per Signature Algorithm ? No. We should define a NewSignature option with a field encoding the signature algorithm. (Seems that's what you call "Universal" as below.) > So there will be one for RSA (already > exists), one for ECDSA, as long as there is free value on the "IPv6 > Neighbor Discovery Option Formats" registry. Or do you think there > is actually some value in our solution that defines an "Universal" > Signature option that indicates the type of Digital Signature it > carries. > Since there is already a reserved field in the RSA Signature Option, > I would not see why we could not use this field to do just that. > Legacy nodes will try to process the option and fail when it is not RSA. > Signature Agility enabled nodes will just do fine. What is you > opinion on this ? --julien _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
