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 ?
- concerning the NewSignature, do you think we should define a new one
per Signature Algorithm ? 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 ?
- NewSignature and NewCGA options will be ignored by legacy nodes (i.e.,
conforming to RFC 3971) and thus messages carrying them will be treated as
unsecured by these nodes.
- specify NewSignature and NewCGA receiver processing such that a node that
doesn't support said algorithm treats the message as unsecured.
Thanks (again) for your comments.
Regards,
Tony
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
