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.
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. Following the recommendation of Section 10.5 I.D-eddsa, the
pre-hash variant SHOULD NOT be used.
Given the title, it would be more appropriated to have the first paragraph
here.
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.
In order to signal within IKE that no hashing needs to be done, we
define a new value has in the SIGNATURE_HASH_ALGORITHMS notification,
one that indicates that no hashing is performed.
On Wed, Feb 15, 2017 at 10:11 AM, Tero Kivinen <[email protected]> wrote:
> Andreas Steffen writes:
> > I personally think that 0 would have been legitimate for the "Identity"
> > hash but the next unassigned value (5) is also ok for me.
> >
> > Could you please ask IANA for an early assignment of the code point?
> > strongSwan 5.5.2 with Ed25519 support is ready to be deployed,
> > thus we would be able to release the stable version as soon as
> > the code point has been assigned.
>
> Before we can make code point allocation, we need to agree on whether
> it is going to be zero or next number. As you can see from the emails
> in this list there is not agreement on this yet, so even if authors
> make IANA request to ask for assignment, when it comes to me (as for
> expert review) few days later, I would wait for the comments on the
> list to agree on which number we are going to allocate.
>
> Now it seems more people are supporting allocating something else than
> zero...
>
> As for the process:
>
> > > As this is expert review registry there is no need to ask for early
> > > allocation, the normal process is just to fill in the IANA general
> > > request for assignments, which then goes to the IANA and they will
> > > then send it to the expert (me) for verification.
>
> And then we will then come back to this list to finish this
> discussion...
> --
> [email protected]
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
