On 2/3/2020 5:49 PM, Jim Schaad wrote:
*From:* Rene Struik <[email protected]>
*Sent:* Monday, February 3, 2020 12:47 PM
*To:* Jim Schaad <[email protected]>; 'Pascal Thubert (pthubert)'
<[email protected]>; [email protected]
*Cc:* [email protected]; 'Shwetha Bhandari (shwethab)'
<[email protected]>; 'The IESG' <[email protected]>; [email protected];
'Benjamin Kaduk' <[email protected]>
*Subject:* Re: [Lake] SEC-DIR review of AP-ND:
Hi Jim:
Just weighing-in on this: see below.
Best regards, Rene
On 2/3/2020 1:16 PM, Jim Schaad wrote:
What is following is personal opinion (although I will admit to
being one of the DEs on these registries):
1. I don’t think that you are going to be able to start doing
compressed points easily in JOSE. It is a design philosophy
that people really wanted at the time. There was extensive
discussions about getting compressed points as well as how to
expressed the point format.
RS>> I would be curious what this design philosophy was: if there is a
record of this, that would be great. It would be particularly
interesting to understand the reasoning as to why for Montgomery
curves and twisted Edwards curves compression is a must, while for
short Weierstrass curves this is forbidden... This is not just so with
JOSE, it is also in RFC 8152 (OKP vs. EC2 distinction). It seems to be
pretty random. <<RS
[JLS] I would suggest going and reading through JOSE mailing list for
how things were setup for there. I think that you and I have a
different view of how the curves are setup for the difference between
OKP and EC2. For the EC2 curves, there are both an X and a Y point
publicly provided to the user. For the Edwards curve, only the X
portion of the point is provided publicly to the user. This means
that there would be a large discussion of what should be done with the
Y coordinate. Being able to validate that the correct set of fields
are present without having to understand all of the fields is
considered to be desirable, at least by me, so reflecting that
difference between the two key formats is logical. I don’t see it as
being random at all. I can see some future three coordinate version
of a hyperspace that might come in the future that would get some type
of 3 point public key and that would again require a new key format to
be defined. (Note that I have no reason to expect it, just that I can
imagine it.)
RS2>> In the future, one may indeed have to deal with definition of new
key formats (which is beyond scope of ap-nd deliberations). Just for
clarity: For EdDSA, one currently, uses lossless point compression,
whereas for X25519, one exchanges only the x-coordinates (lossy
compression), and for Weierstrass curves one uses lossless, but
uncompressed coordinates. <<RS2
2. In my opinion, table 2 should not be referencing the
Curve25519 in the last column. From my point of view when
curves are expressed as using different coordinate systems
then you need to be expressing these as different curves. An
algorithm negotiation currently only needs to include the
curve and not additionally include the point format. This
needs to be maintained. I therefore believe that a new curve
code point should be registered here. That is the only
registration that I believe needs to be done in the JOSE
registries.
RS>> Please note that the different crypto types in Table 2 refer to
complete specifications of signature schemes, including point
representation, bit/byte ordering, etc. Please note that curves
expressed in different coordinate systems are not really different:
only their representations are (unfortunately, this confusion is
caused by heavy marketing by some people in the past). The different
representations, not just of curve points, but also LSB/MSB and
lsb/msb ordering conventions, are already captured in Table 2. Since
different bit/byte ordering, even with the same curve, makes a
difference, representation conventions are the guiding metric, not
just different curve models. <<RS
[JLS] If you do not plan to use either JOSE or COSE key formats, then
you are free to do what you will. If you want to use those key
formats then I am afraid that you are going to need to deal with the
perceptions of the people who currently hold the review world there.
RS2>> If not both entries in the tuple (curve, representation
conventions) are the same, then reuse of the long-term public-private
key pair may not be safe. As an example, if one were to use Edwards25519
with deterministic Schnorr and defines two instantiations, viz. (1)
with LSB/lsb representation and (2) with MSB/msb representation, then
one can certainly not reuse long-term public/private key pairs, since
this would immediately expose the private key (since the hash function
H(R,Q,m) would have differently formatted representations of R:=kG and
Q:=dG. I hope this illustrates that representation conventions are an
essential part of a signature scheme. In the end, we both mean the same
thing, except that my statement was a little bit broader, in the sense
that representations are another input parameter of an instantiation of
a signature scheme. <<RS2
3.
Note, I find section 7.5 to be missing a small piece of guidance
that might be needed. If you use the “same” private key for both
the Edwards and Weierstrass curve representations, is that a
problem according to this guidance?
RS>> Reuse of the same public-private key pair with different
signature schemes is not allowed. <<RS
[JLS] And are they different signature schemes? Some people might not
think so based on what is currently documented. Can you switch the
signature format between the two schemes? If so does that mean that
they are really different?
RS2>> Those schemes are different per the remark above, since the pairs
(curve, representation conventions) are different. Perhaps,
reformulating this as different instantiations of signature schemes
would satisfy your remark? <<RS2
Jim
*From:* Lake <[email protected]>
<mailto:[email protected]> *On Behalf Of *Pascal Thubert
(pthubert)
*Sent:* Monday, February 3, 2020 5:29 AM
*To:* [email protected]
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>; Shwetha
Bhandari (shwethab) <[email protected]>
<mailto:[email protected]>; The IESG <[email protected]>
<mailto:[email protected]>; [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>; Benjamin Kaduk
<[email protected]> <mailto:[email protected]>
*Subject:* [Lake] SEC-DIR review of AP-ND:
Dear all
During SEC-DIR review, Benjamin pointed out:
> Why do we need to allow ambiguity/flexibility as to the point
representation
> within a given Crypto-Type value (as opposed to fixing the
representation as a
> parameter of the Crypto-Type)? Alternately, what does
"(un)compressed"
> mean, as it's not really clarified directly? Furthermore, Table
2 lists an
> "(un)compressed" representation for type 0 (over P-256), but RFC
7518 notes
> that the compressed representation is not supported for P-256
(Section
> 6.2.1.1). I also am not finding the needed codepoints
registered in the JOSE
> registries to use ECDSA25519 (crypto-type 2) -- do we need to
register
> anything there?
Any idea how we can address this?
In particular does anyone know why RFC 7518 does not support the
compressed representation for P-256? Cc’ing LAKE on the impact of this
Pascal
--
email:[email protected] <mailto:[email protected]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
