Hi,
This looks good to me.
Here is the text to justify the downref ;-)
The Downref is justified by RFC3967 as it falls into the following case:
o A standards track document may need to refer to a protocol or
algorithm developed by an external body but modified, adapted, or
profiled by an IETF informational RFC.
Yours,
Daniel
On Sun, Mar 12, 2017 at 2:14 PM, Yoav Nir <[email protected]> wrote:
> Hi, Daniel.
>
> See my comments inline.
>
> Also see this pull request: 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.
>
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
