Thanks Tero and sorry for forgetting:-)


On 13/10/16 13:04, Tero Kivinen wrote:
> Stephen Farrell writes:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-ipsecme-safecurves-05: Yes
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> - Sorry if I'm forgetting how we handle this in IPsec,
>> but is an implementation of this RFC expected to support
>> both curves? I think it'd be ok to say that 25519 is a
>> MUST for folks doing, this but that 448 is optional.  I'm
>> also fine if we mean that implementing this means you
>> have to support both btw but you don't say (here) that
>> that's the case.
> In IPsec we do not specify any requirement levels in the actual
> algorithm documents. The algorithm documents just allocate the IANA
> numbers and specify how they algorithms are used.
> Then we have separate documents (new versions soon to be in front of
> IESG) specifying the actual mandatory to implement algorithms.
> Whether some implementation supports this new RFC is something that
> does not have well define answer, as people could say they implement
> this RFC if they support one or other, or both curves. Usually people
> are just saying they support algorithm RFC if they support one
> algorithm from there. I.e., vendors usually say they support RFC2451,
> even if they only support 3DES from there, and might not support
> CAST-128, RC5, IDEA and Blowfish.
> Anyways the mandatory to implement ciphers are specified in the
> rfc4307bis [1] and rfc7321bis [2].
> These curves are not mentioned there, so they are still going to be
> MAY. When we are going to update 4307bis again then we are most likely
> going to make them SHOULD+ or even MUST (if there is enough
> implementations actually implementing them at that point).
> [1]
> [2]

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

IPsec mailing list

Reply via email to