Just to be clear: everything has been described in much detail in Section 4 of the
lwig curve doc. There is no new algorithm: ECDSA has been specified in FIPS 186-4,
ANSI X9F, SECG, BSI docs for 1 1/2 decades; same thing for co-factor ECDH.
Perhaps, the confusion comes from the fact that each such algorithm actually can
only be instantiated once one agrees on bit/byte ordering or such? As an example,
FIPS 186-4 specified ECDSA, which has inputs {an elliptic curve in
short-Weierstrass format, a suitable hash function, and representation of
signature components r and s}. This does not make any instantiation another
algorithm, similar as any interface with input parms does not specify another
protocol (at least, in my reading). Same thing for elliptic curve points: if one
represents an affine curve point (x,y) in compressed form (e.g., (x,y) ---> (x,
y (mod 2))), this does not create another point, just a more bit-efficient way of
sending this over or storing this in time. The same holds for representations that
do have the benefit of economizing on development effort, by reusing specs, code,
hw, or all of this.
In short: there are no new algorithms.
I hope this helps.
==
From my perspective, what is most important to you and the WG proponents,
define the new algorithms or describe how you implement existing algorithms
with this
transform methodlogy? If it is the first then I think moving this document to
another WG where defining new algorithms are in scope. If it is the later, then
you and the WG have to strip down the document to not define new algorithms,
only how they can be implemented.
On 2021-02-17 1:57 p.m., Rene Struik wrote:
Hi Magnus:
According to Section 16.11 of RFC 8152 [1], registration of IANA code
points does not require a specification that is actually an IETF draft
or RFC document (I could have posted the specification on my own
website for that matter). {Obviously, unambiguous specifications have
to be there, see the very first draft of Nov 13, 2017, almost 3 1/2
years ago [2].} The same Section 16.11 also does not seem to require a
iana cose section.
I am sure you have much more process experience than I do. However, I
have trouble understanding how having a IANA section makes this
suddenly a process violation. Do I understand correctly that, in your
mind, this process issue would be moot if I would simply partition the
doc into two parts A and B, where C:=A+B is the current document and
where A=C\B and B:={Section 12.2, Section 12.3}?
Just for your info: I do hold the editorial organizational principle
dear, where I think I serve the community at large best by having a
coherent treatment of all relevant material in one carefully edited
document (rather than sprinkled around).
In case the A+B partitioning is your preference, how does this help an
implementer, who may be more interested in finding what he/she needs
than in procedural matters somewhere along the way? Where would they
find part B, in case they are interested in this?
I simply would like to understand, since I do not right now.
Best regards, Rene
[1] [excerpt of Section 16.11 of RFC 8152 - Expert Review Instructions]
Specifications are required for the standards track range of point assignment.
Specifications should exist for specification required ranges, but early
assignment before
a specification is available is considered to be permissible. Specifications
are needed for the first-come, first-serve range if they are expected to be
used outside of closed
environments in an interoperable way. When specifications are not provided, the
description provided needs to have sufficient information to identify what the
point is being used for.
[2]
https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00#section-3
[excerpt of your email]
I have after that initial realization tried to understand a bit how we ended up
with this situation. As I said this scope issues should have been detected and
handled much earlier. That is why I briefly looked at -00 and -04, where the
later is the point where this document definitely had crossed the line for
LWIG's charter scope. The fact that the document contained IANA considerations
for crypto algorithms was all I needed to make that determination. It is an
organizational failure in my view that this scope issue was not address already
in 2019.
Ref: [1] https://tools.ietf.org/html/rfc8152#section-16.11
On 2021-02-17 12:30 p.m., Magnus Westerlund wrote:
Hi Rene,
I think you are not correctly understanding my discuss. This is a discuss on the
failures in following IETF process that has occurred for this document.
From my perspective there is no question that the current draft put in front of
IESG is not within the chartered scope for the LWIG WG. It attempts to register
a new, not before existing COSE algorithms. That is clearly specification work,
something LWIG is not chartered to do.
It is good that you gotten some feedback on the draft. However, I am convinced
more feedback would have been provided had this work been done in a more
appropriate venue. I would also note that the email from John Mattsson that you
quote below also do indicate issues with coordination with COSE WG for example.
https://mailarchive.ietf.org/arch/msg/lwip/PHKTq30QucdjdtAfqsYqqbVep4A/
To be clear, I have no interest in killing your document, simply ensure that
IETF process is followed correctly to enable that your document can eventually
published.
From my perspective, what is most important to you and the WG proponents,
define
the new algorithms or describe how you implement existing algorithms with this
transform methodlogy? If it is the first then I think moving this document to
another WG where defining new algorithms are in scope. If it is the later, then
you and the WG have to strip down the document to not define new algorithms,
only how they can be implemented.
On Wed, 2021-02-17 at 10:50 -0500, Rene Struik wrote:
Hi Magnus:
I don't think a brief glimpse at 00 document does this document or my efforts
on this justice ("my brief review of the 00"). However, let me walk you
through this draft document. Perhaps, this helps in appreciating it better.
Let me attempt to clarify what my I see as my role as AD are in the document
approval process are. I review documents to find where my expertise and
experience of IETF may find significant issues that has gone unnoticed so far.
This particular week we have 11 documents (407 pages in total) and two charters
to review. I at least don't read the documents in detail. I skim a lot to find
those documents and parts of documents where I need to understand. Simply so
that I can determine if there are any issue. For your document I am not a
subject matter expert. To me it was sufficent to briefly look at the document to
understand on a high level what the document does. That high level understanding
was sufficient to see that there was an process issue here due to the scope of
the document and the scope the WG's charter defines.
I have after that initial realization tried to understand a bit how we ended up
with this situation. As I said this scope issues should have been detected and
handled much earlier. That is why I briefly looked at -00 and -04, where the
later is the point where this document definitely had crossed the line for
LWIG's charter scope. The fact that the document contained IANA considerations
for crypto algorithms was all I needed to make that determination. It is an
organizational failure in my view that this scope issue was not address already
in 2019.
So can we please focus on what is important to resolve the situation, i.e. which
path should be taken here.
Cheers
Magnus Westerlund
--
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
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
