Hi,

while this clarification wouldn't hurt if it were present in the RFC 7634,
I think that generally speaking it is redundant. RFC 7634 doesn't exist
in vacuum, it is expected that its readers are familiar with RFC 7296,
which has a clear rule that algorithms with fixed key size MUST NOT
include Key Length attribute. I see no reason to repeat this rule in every RFC
specifying new algorithm. It definitely wouldn't hurt if it were repeated,
but if it isn't then that is that. Go and read RFC 7296.

Regards,
Valery.


> > This errata proposes to add the following sentence to section 4 of RFC 7634
> <https://tools.ietf.org/html/rfc7634#section-4>:
> >
> > As with other transforms that use a fixed-length key, the Key Length 
> > attribute MUST NOT be specified.
> >
> > This sentence is correct. If this came up as a suggestion during WG 
> > processing or during LC, I think we would
> add it.
> >
> > Looking back in RFC 7296, we have in section 3.3.5 
> > <https://tools.ietf.org/html/rfc7296#section-3.3.5>:
> >
> >    o  The Key Length attribute MUST NOT be used with transforms that use
> >       a fixed-length key.  For example, this includes ENCR_DES,
> >       ENCR_IDEA, and all the Type 2 (Pseudorandom Function) and Type 3
> >       (Integrity Algorithm) transforms specified in this document.  It
> >       is recommended that future Type 2 or 3 transforms do not use this
> >       attribute.
> >
> > And RFC 7634 says:
> >
> >    o  The encryption key is 256 bits.
> >
> > Given that, I don’t think there is any chance for a conscientious 
> > implementer to make the mistake of
> including the Key Length attribute.
> >
> > I don’t believe adding clarifying text is a proper use of the errata 
> > system. At best it should be marked as
> editorial and held for document update, if not rejected outright.
> 
> I generally agree with this sentiment.  I would probably be willing to mark
> as editorial/hold for document update in this case, though.  How would that
> work for people?
> 
> -Ben

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to