I can change that. However, “Identity” is the term used in the CFRG draft.
> On 8 Apr 2016, at 9:57 AM, Valery Smyslov <[email protected]> wrote: > > I also think that "null" is less ambiguous here. > > Regards, > Valery. > > -----Original Message----- From: Yaron Sheffer > Sent: Friday, April 8, 2016 9:30 AM > To: Yoav Nir ; Tero Kivinen > Cc: IPsecME WG > Subject: Re: [IPsec] EdDSA Signatures in IKE > > "Identity" is the formally correct term, but I think "null" is much > clearer than "identity". Especially in the context of certificates, > where "identity" can be mistaken for something else. > > Thanks, > Yaron > > On 04/08/2016 01:29 AM, Yoav Nir wrote: >> >>> On 7 Apr 2016, at 6:12 PM, Tero Kivinen <[email protected]> wrote: >>> >>> Yoav Nir writes: >>>> Tero: What would it take to register an “identity” hash function for >>>> use with the EdDSA? >>> >>> I assume you mean new value for the RFC7427 Hash Algorithm registry? >>> That registry is by expert review, but as "identity" is not >>> necessarely clear enough for the implementors, I would suggest writing >>> internet-draft doing the allocation, and also explaining how the >>> "identity" hash function would be used and where it can be used. >>> >>> That same draft could also point references to the suitable cfrg >>> document, and recommend not using the ph versions. >> >> Like this? >> https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00 >> >>> I.e., if we could use existing hash and signature algorithms then >>> there would not be need for document, but if we want to define new >>> "hash" algorithm, then I think we do need document that specifies >>> where it can be used and how it is "calculated". And that same >>> document can then also explain the signature algorithms where it is to >>> be used, and provide references. >>> >>>>> 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). >>> -- >>> [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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
