- From: Mike Jones <Michael.Jones@microsoft.com>
- Date: Sun, 15 Nov 2015 16:54:43 +0000
- To: Jim Schaad <ietf@augustcellars.com>, 'Ryan Sleevi' <sleevi@google.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <BY2PR03MB44268066FCA0F5EE0FBB2E8F51F0@BY2PR03MB442.namprd03.prod.outlook.com>
Since Jim as a DE agrees that the information isn’t needed in this case, then I’d suggest that our registrations do the same as those in JWA [RFC 7518]: Algorithm Analysis Documents(s): n/a -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, November 14, 2015 10:53 PM To: 'Ryan Sleevi'; Mike Jones Cc: public-webcrypto@w3.org Subject: 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<mailto:Michael.Jones@microsoft.com>> Cc: public-webcrypto@w3.org<mailto: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.
Received on Sunday, 15 November 2015 16:55:17 UTC