Hi, Daniel. See my comments inline.
Also see this pull request: https://github.com/ietf-ipsecme/drafts/pull/25 <https://github.com/ietf-ipsecme/drafts/pull/25> Unless I hear some push-back, I will submit this right before the deadline. Yoav > On 8 Mar 2017, at 20:49, Daniel Migault <[email protected]> wrote: > > Hi, > > Please find my comments regarding the draft. I believe the draft is ready to > be moved forward. I do not have strong opinion on the value to assign. > > Yours, > > Daniel > > The Internet Key Exchange protocol [RFC7296] can use arbitrary > signature algorithms as described in [RFC7427]. The latter RFC > defines the SIGNATURE_HASH_ALGORITHMS notification where each side of > the IKE negotiation lists its supported hash algorithms. This > assumes that all signature schemes involve a hashing phase followed > by a signature phase. This made sense because most signature > algorithms either cannot sign messages bigger than their key or > truncate messages bigger than their key. > > EdDSA ([I.D-eddsa]) defines signature methods that do not require > pre-hashing of the message. Unlike other methods, these accept > arbitrary-sized messages, so no pre-hashing is required. These > methods are called Ed25519 and Ed448, which respectively use the > Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although > that document also defines pre-hashed versions of these algorithm, > those versions are not recommended for protocols where the entire to- > be-signed message is available at once. > > MGLT: I think that a pointer for the recommendation should be provided - > section 10.5 of I.D-eddsa. Added. Except that now it’s in section 8.5 of RFC 8032. > The first sentence of the paragraph above confuses me. Although this si true, > I prefer to say that EdDSA ([I.D-eddsa]) defines signatures methods that > includes pre-hasing as well as signature methods that do not require > prehashing. Yes, but the first paragraph is all about the assumption that all signature methods have a pre-hash stage. The new thing about EdDSA is that it introduces a method that does not have a pre-hash stage. The fact that we are not even specifying the use of EdDSA with pre-hash is all the more reason to push the mention of this to the end of the paragraph. How about: EdDSA ([RFC8032]) defines signature methods that do not require pre- hashing of the message. Unlike other methods, these accept arbitrary-sized messages, so no pre-hashing is required. These methods are called Ed25519 and Ed448, which respectively use the Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although that document also defines pre-hashed versions of these algorithm, those versions are not recommended for protocols where the entire to- be-signed message is available at once. See section 8.5 or RFC 8032 for that recommendation. > > EdDSA defines the binary format of the signatures that should be used > in the "Signature Value" field of the Authentication Data Format in > section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines the > object identifiers (OIDs) for these signature methods. For > convenience, these OIDs are repeated in Appendix A. > > MGLT: Note that the pkix document is still on discussion. -- Although IOD > seems out of the scope of the discussion. Since I’m referencing an I-D normatively, they become a cluster. If Curdle decides to allocate other OIDs we’ll fix this specification as well. Not that any of us expect that to happen. Yoav BTW: RFC 8032 is Informational, while this document and RFC4492bis and the Curdle I-D are standards track. So I guess the shepherd’s write-up should reflect that RFC 8032 should be added to the downref registry.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
