No responses yet... Tero: What would it take to register an “identity” hash function for use with the EdDSA?
Yoav > On 5 Apr 2016, at 11:09 AM, Yoav Nir <[email protected]> wrote: > > 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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
