Re: [Lake] SEC-DIR review of AP-ND:

Jim Schaad <ietf@augustcellars.com> Mon, 03 February 2020 17:50 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: "'Pascal Thubert (pthubert)'" <pthubert@cisco.com>, draft-ietf-6lo-ap-nd@ietf.org
CC: 6lo-chairs@ietf.org, "'Shwetha Bhandari (shwethab)'" <shwethab@cisco.com>, 'The IESG' <iesg@ietf.org>, 6lo@ietf.org, lake@ietf.org, 'Benjamin Kaduk' <kaduk@mit.edu>
References: <MN2PR11MB3565A885E27E86C53205825BD8000@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565A885E27E86C53205825BD8000@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Mon, 03 Feb 2020 09:50:07 -0800
Message-ID: <01fe01d5daba$62940e20$27bc2a60$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FF_01D5DA77.54740270"
Thread-Index: AQI51a2x6Xn9gJl7cgl9kt+4OYRyJadByMfA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/PmbX7yMvO_ytYwXPBb7L9jcZVn4>
Subject: Re: [Lake] SEC-DIR review of AP-ND:
Precedence: list

>From a quick run through the JOSE mailing list to refresh my memory:

 

1.	There is a view that on only one way should exist to do things.
Thus only either compressed or uncompressed
2.	There are still issues (at the time) about having compressed points
and patents

jim

 

From: Lake <lake-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, February 3, 2020 5:29 AM
To: draft-ietf-6lo-ap-nd@ietf.org
Cc: 6lo-chairs@ietf.org; Shwetha Bhandari (shwethab) <shwethab@cisco.com>;
The IESG <iesg@ietf.org>; 6lo@ietf.org; lake@ietf.org; Benjamin Kaduk
<kaduk@mit.edu>
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

[Lake] SEC-DIR review of AP-ND: Pascal Thubert (pthubert)
Re: [Lake] SEC-DIR review of AP-ND: Jim Schaad