Re: Transition to PR: New "Proposed Algorithm" note for algorithms without interop (and Curve 25519 from CFRG)

On 10/12/2015 11:52 AM, Ryan Sleevi wrote:
>
>
> On Sun, Oct 11, 2015 at 6:29 PM, Harry Halpin <hhalpin@w3.org
> <mailto:hhalpin@w3.org>> wrote:
>
>     WebCrypto Working Group,
>
>     We still have two formal objections that we have to prove are properly
>     resolved to progress out of Candidate Recommendation phase and
>     algorithms in the spec have to show interoperable implementation
>     to get
>     out CR.
>
>     So as part of our transition to we have is that some algorithms are
>     going to removed, including some we might add back in shortly like
>     RSA-PSS. However, as part of the effort we would like to take all
>     algorithms that cannot demonstrate interoperability between two
>     different browser teams from the Candidate Recommendation. Rather than
>     have the text lost, as it is likely some of these will be added
>     back to
>     the spec (like RSA-PSS), I propose that we add this to a "Proposed
>     Algorithms" document that will be published as a Working Group
>     Note. It
>     will have no normative status and in the Working Group Note we can
>     outline the criteria we will use to add specifications to the Working
>     Group. Is the WG OK with this?
>
>
> It is unclear the value of this, other than perhaps some process
> working flow?

The value is that we do not want the "Proposed Algorithms" to be
mistaken for Rec-track. A "Working Group Note" is the way to do that as
it explicitly keeps states that the Document is not intended to be
Recommendation track.  We want a clear relationship between algorithms
that are not (possibly yet) proven to be interoperable and those that
are part of the Recommendation. The text of a Working Group Note is as
follows in the Status Section:

" This Working Group will not advance this Working Group Note to
Recommendation Status. Publication as a Working Group Note does not
imply endorsement by the W3C Membership. This is a draft document and
may be updated, replaced or obsoleted by other documents at any time. It
is inappropriate to cite this document as other than work in progress. "

Generally, a Working Group publishes non-Rec track document as Notes to
keep the difference clear when it fulfils its charter. We could also do
so with the "Use cases" document if needed.

>  
>
>     There was lots of comments over the lack of support for "non-NIST"
>     elliptic curve cryptography. We resolved to eventually inlcude in our
>     Recommendation whatever elliptic curves were recommended by the IRTF
>     CFRG [1]. Note that since then the CFRG has recommended Curve
>     25519 for
>     DH and for signatures. So  I would further add Trevor Perrin's
>     text for
>     Curve 25519 [2]  support to this "Proposed Algorithms" Note as well if
>     he has time to update it and the editors and WG can check his
>     description.
>
>
> I do not, and the CFRG's recommendation is still without final
> consensus on spec that would be necessary before finalizing such text.
>
> A Proposed Note suffers from the same issues of CR/PR, namely, that
> it's perceived as frozen in time (even though the web never freezes),
> so given that we know it's not in a place to be frozen, it's unclear
> how to reconcile that.

To prevent the Note from being frozen in time, seems like keeping it in
Git would be the way to go, no?

Also, it needs a paragraph explaining the relationship of "Proposed
Algorithms" to the actual Recommendation and how we plan to edit the
Recommendation in response to increased browser interoperability in the
future.

We could keep Trevor's work in yet another Note, but *if* it is viewed
as well-specified as the other algorithms, I see no reason to keep it
out. If it's not, I suggest we give him time to fix it. We could publish
it as another Note, but I would worry this would make things seem more
fuzzy. We could differentiate between "Working Group Approved Proposed
Algorithms" and "Suggestions by Individuals Not Reviewed by Working
Group" in the Proposed Algorithm Note.
>  
>
>     I would like to propose a call for consensus on this proposal at our
>     next meeting, and can discuss it on tomorrow's teleconference if there
>     is any questions.
>
>
> Our workmode is that we reach consensus on the mailing lists, as has
> been repeatedly established :)

Exactly. That's why the call for consensus will only happen after the
meeting, and over the mailing-list - just as we did last time :)

   cheers,
        harry