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 <kivi...@iki.fi> 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 <ynir.i...@gmail.com> 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).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
