The second part of the sentence below (see ....) did not make it to my
earlier email. My apologies.
RS>> Reuse of the same public-private key pair with different signature
schemes is not allowed. See also Security Considerations, Section 7.5. <<RS
On 2/3/2020 3:46 PM, Rene Struik wrote:
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
1. 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
1.
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. See also Security Considerations,
Section 7.5. <<RS
Jim
*From:* Lake <[email protected]> *On Behalf Of *Pascal Thubert
(pthubert)
*Sent:* Monday, February 3, 2020 5:29 AM
*To:* [email protected]
*Cc:* [email protected]; Shwetha Bhandari (shwethab)
<[email protected]>; The IESG <[email protected]>; [email protected];
[email protected]; Benjamin Kaduk <[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] | 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
