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

I agree with Ryan on this.  The comments about needing to supply information about crypto algorithms is more for dealing with vanity algorithms that the DE has never heard of.  This is not the case here.

 

Jim

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Saturday, November 14, 2015 2:08 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: public-webcrypto@w3.org
Subject: 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 <mailto: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>  [mailto:bugzilla@jessica.w3.org <mailto:bugzilla@jessica.w3.org> ]
Sent: Monday, January 12, 2015 1:10 PM
To: public-webcrypto@w3.org <mailto: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 <mailto:sleevi@google.com> 
          Reporter: ietf@augustcellars.com <mailto:ietf@augustcellars.com> 
                CC: public-webcrypto@w3.org <mailto: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.