Replying to myself... I’ve been told off-list that it didn’t make sense to introduce the hot, new algorithm as a MAY. The only reason I’m suggesting this is that there are currently no implementations to interop with, and no EdDSA certificates where the public keys might come from. My main motivation is to MUST NOT the pre-hashed versions because we don’t need them and again there’s no install base to interop with.
Thinking it over, the new EdDSA signature algorithm defined in the CFRG draft[1] can sign arbitrary-sized messages. We traditionally fed the signature functions hashes of the message because these signature functions only accepted a limited-size input. That is why the “digital signature” document (RFC 7427) has a negotiation and field for hash algorithm. Since we don’t need that with this particular algorithm, I suggest we don’t. IOW I’m suggesting that we allocate a new entry in the “IKEv2 Hash Algorithms” registry called “identity” that will be used only with EdDSA signatures (or any future signature with the same property). Yoav [1] See for example https://tools.ietf.org/id/draft-irtf-cfrg-eddsa-05.html#rfc.section.5.1.6 > On 4 Apr 2016, at 4:43 PM, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi > > At the meeting today, I presented the SafeCurves draft status and asked the > room whether we wanted to wait for CFRG and Curdle to settle their respective > RFCs. The room was unanimously in favor of not having anything in the current > draft, instead using RFC 7427 digital signatures. To be certain if we *did* > wait, we’d just list the two OIDs from Curdle that we like (the non-prehashed > ones). > > Quoting from the Curdle draft, they have this: > > id-Curve25519 OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.1 } > id-Curve448 OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.2 } > id-Curve25519ph OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.3 } > id-Curve448ph OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.4 } > > In other news, it turns out that we still have some discussion to go with > 4307bis. So I suggest that we add these to table 9 of section 4.2 there as > follows: > > +------------------------------------+------------+---------+ > | Description | Status | Comment | > +------------------------------------+------------+---------+ > | RSASSA-PSS with SHA-256 | SHOULD | | > | ecdsa-with-sha256 | SHOULD | | > | sha1WithRSAEncryption | SHOULD NOT | | > | dsa-with-sha1 | SHOULD NOT | | > | ecdsa-with-sha1 | SHOULD NOT | | > | RSASSA-PSS with Empty Parameters | SHOULD NOT | | > | RSASSA-PSS with Default Parameters | SHOULD NOT | | > | sha256WithRSAEncryption | MAY | | > | sha384WithRSAEncryption | MAY | | > | sha512WithRSAEncryption | MAY | | > | sha512WithRSAEncryption | MAY | | > | dsa-with-sha256 | MAY | | > | ecdsa-with-sha384 | MAY | | > | ecdsa-with-sha512 | MAY | ?SHOULD | > | id-Curve25519 | MAY | | > | id-Curve448 | MAY | | > | id-Curve25519ph | MUST NOT | | > | id-Curve448ph | MUST NOT | | > +------------------------------------+------------+---------+ > > What do others think? > > Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
