Hi Ben:
I do believe your suggestion to allocate a code point for ECDSA with
SHAKE256 (thereby, untie-ing this from the curve) is easy to
accommodate with the draft.
This would come down to changing Section 12.3.2 as below (change of
Name and Description fields only, plus pointer to example):
12.3.2. COSE Algorithms Registration (1/2)
This section registers the following value in the IANA "COSE
Algorithms" registry [IANA.COSE.Algorithms].
Name: ECDSA with SHAKE256;
Value: TBD (Requested value: -48);
Description: ECDSA with SHAKE256;
Change Controller: IESG;
Reference: specified in Section 4.4 of this specification; for
encodings, see Section 10.2; for an example, see Appendix Q.3.3.
and changing the last para of Section 10.2 as below (i.e., untieing
the curve from "alg" parameter [since "alg" now becomes ECDSA+SHAK256,
rather than ECDSA+SHAKE256+Wei448):
OLD:
The encodings below specify the use of instantiations of ECDSA with
COSE (see Section 10.2.1) and JOSE (see Section 10.2.2), where the
encoding for a specific ECDSA instantiation (i.e., with a specific
short-Weierstrass curve and specific hash function) results by setting
the "crv" parameter to the unique name of the underlying curve in
question and the "alg" parameter to the unique name of the specific
signature scheme instantiation (e.g., "ECDSA25519" for the ECDSA
scheme defined in Section 4.3 and "ECDSA448" for the scheme defined in
Section 4.4). Note that, in this case, the "alg" name uniquely defines
the curve (and, thereby, implicitly the underlying "crv" parameter)
and the underlying hash function.
NEW:
The encodings below specify the use of instantiations of ECDSA with
COSE (see Section 10.2.1) and JOSE (see Section 10.2.2), where the
encoding for a specific ECDSA instantiation (i.e., with a specific
short-Weierstrass curve and specific hash function) results by setting
the "crv" parameter to the unique name of the underlying curve in
question and the "alg" parameter to the unique name of the specific
signature scheme instantiation. For JOSE, this is realized by setting
the "alg" parameter to "ECDSA25519" for the ECDSA scheme defined in
Section 4.3 and to "ECDSA448" for the scheme defined in Section 4.4).
For COSE, this is realized by setting the "alg" parameter to "ES256"
(short-hand for "ECDSA with SHA-256") for the ECDSA scheme defined in
Section 4.3 and to "ECDSA with SHAKE256" for the scheme defined in
Section 4.4). Note that, in the case of JOSE, the "alg" name uniquely
defines the curve (and, thereby, implicitly the underlying "crv"
parameter) and the underlying hash function, while in the case of
COSE, the "alg" name uniquely defines the underlying hash function,
but not the underlying curve.
I do think this would highlight the (somewhat confusing [to me])
differences between COSE and JOSE treatment of ECDSA in a concise
manner.
I think this would settle the ECDSA/SHAKE256/Wei448 code point for
COSE. Could you confirm?
As to using ES256, the main issue I see is that the definition of
ECDSA in RFC 8152 is not precise enough. For the exact definition, I
included Appendix Q (which is compatible with RFC8152's definition in
the deployed cases of ES256, ES384, and ES512, so using the exact
definition does not hurt current deployments and helps future ones).
Putting some verbiage to that effect into the draft should illuminate
this and settle this. Does this work? {If not, one still would need a
code point for "ECDSA with SHA-256 exact definition-style"; if so, one
would not need this (currently in Section 12.2.2).}
Last note: RFC8692 defines ECDSA w/ SHAKEs (including both ECDSA w/
SHAKE128 and ECDSA w/ SHAKE256). It would be easy to align COSE to
this, simply by adding the ECDSA w/ SHAKE128 code point (to the
already requested code point for ECDSA w/ SHAKE256). There should be
sufficiently many "small-size" code points left to do so (one can use
"-9" if the verdict of the above para is okay).
I hope this helps, Rene
Ref: [1] Email Ben Kaduk of April 29, 2021, 6.29pm EDT, Subject: next
steps for draft-ietf-lwig-curve-representations
[2]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-21
[3] https://datatracker.ietf.org/doc/html/rfc8152
[4] https://datatracker.ietf.org/doc/html/rfc8692
On 2021-04-29 6:53 p.m., Benjamin Kaduk wrote:
Hi Rene,
My apologies for the slow response -- Erik, Roman, and I were able
to get
together to talk about this document last week but then I had to
take a
couple days off, which interrupted my drafting of this note.
It seems that there are a handful of mostly orthogonal axes along
which action
is needed, so I will try to enumerate them separately.
[1] Intended status of the document (Informational vs Proposed
Standard).
Since, at its core, the point of this document is to provide
information about
how you can use elliptic curve isogenies (and isomorphisms) to use
an ECC
implementation that is generic within one family of curves to perform
operations defined on a different family of curves, the
Informational status
seems most appropriate. My undersatnding is that the intended
status was
changed to Proposed Standard in order to qualify for allocations
from a
codepoint range in the IANA COSE registries that has a shorter
encoding. At
present, those IANA Considerations are not even in the document,
but even if
we do want to have IANA registrations for those COSE codepoints
eventually, it
is fairly straightforward to do to in a separate document as needed.
Accordingly, assuming the WG chairs (on behalf of the WG) do not
object,
please go back to the Informational status in the next version.
[2] Describing the motivation for the document
My understanding of the core purpose of this document is
summarized in the
previous point -- to allow reuse of code that is "generic" (but
not fully
generic ECC code) to make more algorithms accessible to that
implementation.
In our discussions, it seemed that Sections 1 and 2 could be seen as
subsections of a single "motivation" section, and that the document's
accessibility would be improved by adding a few clarifying
sentences covering
the importance/relevance of this type of strategy for lightweight
implementation. Please consider performing this type of
restructuring to
improve the document. I am willing to suggest specific edits if
desired
(though probably not with a particularly fast turnaround time).
[3] Key types
The JOSE registration requests currently in the document (and the
COSE ones,
when they were there) are doing something that is without
precedent, namely
allowing the use of both "OKP" and "EC" ("EC2" in COSE) key types
(i.e.,
representations) for a single curve. All the curves defined in
RFC 7518 use
"EC" and only "EC; likewise, all the curves defined in RFC 8037
use "OKP" and
only "OKP". RFC 8812 is the only other JOSE curve registration,
which uses
kty "EC". I think this deviation from precedent is something that
does not
have a presumption of IETF consensus, and that the JOSE and COSE
communities
should be consulted on whether diverging from precedent in this
way is the
correct course of action. I will initiate an email thread with
the COSE and
JOSE WG lists (and am happy to put you on the CC list if desired)
to consider
this question. If you do believe that it is important to be able
to use both
key types with these new curves, I implore you to specifically
discuss the
topic in the IANA considerations and provide some explanation or
justification
for why it is the right thing to do. Such text would be a useful
input to the
discussion I will initiate with the COSE/JOSE WG lists.
[4] COSE Algorithm semantics
I include this text only for completeness, even though it is
perhaps only a
matter for the IANA Considerations that requested allocation from
COSE
registries. (On the other hand, the main body text still includes
treatment
on the use of the new algorithms with COSE as well as JOSE, which
might
suggest that COSE-related topics remain in scope.)
One of the goals of the COSE work was to (in some sense) "avoid
repeating the
mistakes of JOSE". This led to, among other things, changing the
key type
value for two-coordinate ECC points from "EC" to "EC2" (as
mentioned above),
but it also led to a fundamental change in what a COSE Algorithm
indicates.
Whereas a JOSE algorithm for ECC signature indicates all three of
signing
algorithm, hash algorithm (if applicable), and curve, in COSE the
algorithm
indicates only two of those three: the signing algorithm and hash
algorithm
(if applicable). COSE indiates the curve separately. (JOSE also
has an
explicit curve parameter, and avoiding this type of redundancy and
risk of
inconsistency was the motivation for making the change in COSE.)
There is one
exception to this classification, as you know: the ES256K
algorithm. That was
a deliberate exception to the rule, made not for purposes of
restricting the
signature algorithm but rather to restrict what the *curve* can be
used for.
Because there is already a COSE codepoint for ECDSA using SHA256,
there is no
need for a new "ECDSA25519" codepoint -- the existing ES256
codepoint with
curve Wei25519 would be the appropriate combination. (There is not
a COSE
codepoint for ECDSA using SHAKE256, so some new codepoint would be
needed for
the intended Wei448 construction.)
The situation for ECDH25519 and ECDH448 is somewhat, but not
entirely,
analogous, due to the complications of requiring cofactor ECDH --
RFC 8152,
its "bis" version, and RFC 6090 as referenced therefrom do not
cover cofactor
ECDH. In my opinion the topic of how COSE should handle cofactor
ECDH is
something that should be discussed in the COSE WG and a consensus
decision
reached. It may or may not be decided to use a new codepoint for
cofactor
ECDH, and so I feel strongly that this document should not
allocate a new
codepoint for cofactor ECDH.
(Also, COSE ECDH algorithms using KDF specify whether they are for
ephemeral-static or static-static, so potentially two new
codepoints would be
needed for both variants.)
[5] Crypto review
I know that the -00 did receive positive review from the CFRG
crypto panel,
but there have been some changes to the relevant text in the
ensuing versions
(as well as a great deal of things moving around in the
document). The ADs
are going to request a new crypto-panel review to confirm the
positive
assessment, but since there is potential for further changes to
the document
in light of the other points, we plan to wait to request such a
review until
it is clear that the document has stabilized again. According to
my notes the
most important sections are currently (-20) 4.1, 4.2, and 4.4, and
at least
appendices F, G, and I.
In the interest of full disclosure, I do have a few other topics
that I still
need to do some more work/investigation on in order to tell if
they are
serious issues or not. These include (but are not limited to):
- whether it is harmful to the Internet community to mention
"X25519+" and
"X448+" as new things distinct from X25519/X448 (and thus, maybe
better/preferred) without discussion of whether/why they are
better. There is
harm to interoperability in specifying new algorithms just
because we can,
and I have seen indications (though perhaps not strong
evidence) that IETF
consensus is to only define new algorithms when there is a
clear need or
benefit from them. My current inclination is to suggest to
remove
discussion of the "plus" variants since they currently seem
under-motivated,
though of course my opinion may change as I get more information.
(Similar considerations may apply to Wei25519.2 and
Wei25519.-3., etc.)
- the specifics of ECDSA+SHA256 on Wei25519. This is related to a
point made
by Ilari but I am not sure that we ever came to clear
agreement as to what
was in quesiton (let alone the answer). The premise here is
that for the
existing ECDSA schemes/curves (P-256+SHA256, P-384+SHA384,
P-521+SHA512),
the range of the hash function is very close to the domain of
input for the
signing function (that is, the size of the prime underlying
the field over
which the curve is defined). In particular, one of the ECDSA
references I
read by following reference chains from this document (sadly,
I did not note
which one) clearly states that the pretreatment of the hash
function output
prior to doing the curve arithmetic for signing involves
subtracting zero or
one multiple of the prime. However, subtracting one copy of
2^255-19 from
the "maximum output" of SHA-256 (i.e., 2^256-1) produces a
value that is
still outside of [0, 2^255-19), and so the referenced ECDSA
procedures are
not applicable for the combination of SHA-256 and Wei25519.
Given your
detailed treatment of byte- and bit-encoding, I expect that
you have given a
precise specification of what you expect to happen in this case.
Unfortunately, I think it is clearly out of charter for LWIG
(and arguably a
bad idea for the IETF itself, vs CFRG or NIST) to define new
ECDSA procedures
outside of what NIST has already specified. Ideally there
would be a NIST
reference we could point to for this class of scenario; if
there is not one
already then my preference would be to ask NIST to produce some
clarification (there are a few NIST staff who participate in
the IETF).
- the extent to which normative requirements from other documents are
duplicated in normative language in this document. Generally,
we try to
only have one authoritative source of any given normative
requirement, so
that it's clear what to do if there is any inadvertent
conflict between the
specifications.
Thank you again for your efforts so far on this document, and my
apologies
that we have not been very effective at helping you to understand
the expected
procedures for a successful IETF-consensus RFC.
-Ben
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
