Re: [Bug 27816] New: IANA considerations review for definition of algorithms

Mike:

What you've described in your email is inconsistent with the bug, and the
past discussions. That is, as Jim noted, "It is also not clear that this
field needs to be filled out unless it is requested by the DE" (of which,
Jim is one of them)

I just want to be careful that this doesn't become a way of attempting to
re-open https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607 by forcing it
into the IANA registrations.

I do think it's unfortunate that the IESG requested that, and that the IETF
accepted that, as part of the publication process. This further
demonstrates the departure that the JOSE-related documents are from the
CMS-related documents that preceeded, and it demonstrates that JWK is
inherently not a value-neutral key container format. This is a somewhat
substantial departure from being equivalent to subjectPublicKeyInfo (RFC
5280) or PrivateKeyInfo (RFC 5208), in which the algorithm identification
and format are expressed simply as 'opaque' OIDs.

This should be easily resolvable, by simply not registering these
algorithms as JWKs and not attempting to give them the same imprimatur of
JWK. Fundamentally, WebCrypto is an API, and we could argue that both the
input formats and output formats - while structurally compatible with JWK,
are instead API parameters (much like every major cryptographic API - from
JSSE to CryptoAPI to PKCS#11 to [Open/Boring/Libre]SSL - does).

My own preference would be:
- Add this required registry field, but leave it blank.
  - Work with the IETF (whomever is our liason - that's you, right?) to
ensure that the DEs are accepting of this
- If the DEs are not accepting of this, simply remove the IANA
considerations
  - Don't treat the JSON keys exported as 'JWKs'. Just treat them as an
API-defined schema that just happens to be 1:1 compatible with JWK :)

On Fri, Nov 13, 2015 at 11:16 AM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> Looking at the latest editor's draft at
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#iana-section-jws-jwa,
> the required "Algorithm Analysis Documents" field has not been added to the
> JSON Web Signature and Encryption Algorithms registrations.
>
> This must be addressed before the CR transition, or the requested IANA
> registrations will be rejected.
>
>                                 -- Mike
>
> -----Original Message-----
> From: bugzilla@jessica.w3.org [mailto:bugzilla@jessica.w3.org]
> Sent: Monday, January 12, 2015 1:10 PM
> To: public-webcrypto@w3.org
> Subject: [Bug 27816] New: IANA considerations review for definition of
> algorithms
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27816
>
>             Bug ID: 27816
>            Summary: IANA considerations review for definition of
>                     algorithms
>            Product: Web Cryptography
>            Version: unspecified
>           Hardware: PC
>                 OS: Windows NT
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: Web Cryptography API Document
>           Assignee: sleevi@google.com
>           Reporter: ietf@augustcellars.com
>                 CC: public-webcrypto@w3.org
>
> Please consider this to be a possible IANA considerations review.  It is
> not completely clear that this is what I would say at the time the document
> shows up.  But it does indicate my current thinking and a discussion will
> likely help in forming final opinions.
>
> This set of registrations is problematic due a change that has occurred
> since this path was initially embarked on.
>
> The IESG made a request for algorithm analysis be added as part of the
> process of registering a new algorithm so that the designated experts would
> have a set of usable documents to determine what the security levels of
> algorithms are.
> It was assumed that this was not necessary for the initial registrations
> as the working group had the chance to discuss this to death during the
> process.  This means that there is an additional requirement
>
>   Algorithm Analysis Documents(s):
>       References to publication(s) in well-known cryptographic
>       conferences, by national standards bodies, or by other
>       authoritative sources analyzing the cryptographic soundness of the
>       algorithm to be registered.  The designated experts may require
>       convincing evidence of the cryptographic soundness of a new
>       algorithm to be provided with the registration request unless the
>       algorithm is being registered as Deprecated or Prohibited.  Having
>       gone through working group and IETF review, the initial
>       registrations made by this document are exempt from the need to
>       provide this information.
>
> It is not clear to me that this is satisfiable for a number of algorithms
> that registration is being requested for in this case.  (It is also not
> clear that this field needs to be filled out unless it is requested by the
> DE so the fact that it is currently absent is not an apriori failure.)
>
> It is very possible that after some discussions a resolution Won't fix is
> reasonable.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
>