Thanks, I will change that (but not put in the part about 5) The RFC editor anyway changes this to “IANA has assigned the value 5 in the …” so it doesn’t matter much what we write.
Modified the PR Yoav > On 13 Mar 2017, at 1:21, David Schinazi <dschin...@apple.com> wrote: > > Yoav, > > The diff looks good to me. > > Based on the discussion in this thread, it looks like there is consensus > to not use 0 as the value for Identity. > Would it make sense to reflect that in the document? > The "IANA Considerations" section currently states: > > IANA is requested to assign a new value from the "IKEv2 Hash > Algorithms" registry with name "Identity" and this document as > reference. Since the value zero was reserved by RFC 7427 and this > "Identity" hash is no hash at all, assigning the value zero to > Identity seems appropriate. > > Could we replace this with: > > IANA is requested to assign a new value from the "IKEv2 Hash > Algorithms" registry with name "Identity" and this document as > reference. Since several current implementation already use > the value zero with a different meaning, assigning the next > available value (currently 5) seems appropriate. > > Thanks, > David > > >> On Mar 12, 2017, at 11:14, Yoav Nir <ynir.i...@gmail.com >> <mailto:ynir.i...@gmail.com>> wrote: >> >> 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 <daniel.miga...@ericsson.com >>> <mailto:daniel.miga...@ericsson.com>> 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. >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
