RE: IANA registry for WebCrypto?

For context, it's important to understand that an explicit consensus call was made in the JOSE working group about whether to support algorithm identifiers as structured objects or as simple strings.  The consensus was to use only strings.  See http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.  From a IETF/ JOSE process point of view, this is a closed issue.

I also disagree that what JOSE has isn't extensible.  The registry defined at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-6.1 explicitly provides the algorithm extension mechanism.

Anyway, I'm not going to continue discussing JOSE issues on the WebCrypto list, but I believe it's important to this discussion to understand that this particular decision isn't likely to be revisited by JOSE.

				Cheers,
				-- Mike

-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com] 
Sent: Friday, January 18, 2013 3:15 PM
To: Ryan Sleevi
Cc: Harry Halpin; public-webcrypto@w3.org
Subject: Re: IANA registry for WebCrypto?

OK, let's up-level a little bit here.  

We're not talking about File object or the One True JSON Encoding.  We're talking about tiny little simple objects to configure an algorithm.  The biggest difference is between BigInt/ArrayBufferView and their serialized forms.  

What JOSE has right now is not perfect.  It's not extensible, and it's poorly laid out.
What WebCrypto has right now is not perfect.  It's too verbose (see other email on 'params').

JOSE might benefit from better encapsulation ({name: "PBKDF2", iterations: "..."}). 
WebCrypto might benefit from some shortcuts ("HMAC-SHA-256").

This is not a huge degree of compromise.  I was just hopeful that folks would be open to trying to find a mutually agreeable solution.  Would it help if I proposed something concrete?

--Richard





On Jan 18, 2013, at 5:08 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Fri, Jan 18, 2013 at 1:57 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> Richard,
>>> 
>>> It's very clear from both charters that JOSE and WebCrypto are 
>>> separate projects, separate efforts, and seek to meet a separate set 
>>> of goals. While there is some commonality, I strongly object to the 
>>> suggestion that they are at all related in purpose enough to derive 
>>> value from sharing algorithms.
>>> 
>>> In all the people I've talked to who have expressed interests or use 
>>> cases for this API, not a single person has expressed any interest 
>>> in JOSE. It's certainly clear that the use of JWE, JWT, JW*, JWK, 
>>> while certainly possible through this API, are NOT the sole intended 
>>> consumers.
>>> 
>>> At it's core, JOSE is a wire format. The WebCrypto API is an API. No 
>>> amount of rechartering in either WG is going to change this reality.
>>> The decisions made should best reflect their intended purposes and 
>>> use cases, and should not be arbitrarily and unnecessarily joined.
>>> 
>>> It does not make any sense to me whatsoever to have an API 
>>> definition handled through an IANA registry nor through a wire 
>>> representational form, especially one as inefficient (for *Web 
>>> Apps*) and programmer-unfriendly as JOSE.
>>> 
>>> JOSE MUST make decisions that best reflect its' design requirements 
>>> - including efficient URL representation - while the WebCrypto API 
>>> MUST make decisions that best reflect users' and authors' needs - 
>>> which extend well beyond JOSE. There is an inherent incompatibility 
>>> in these MUSTs - a point I well understood that we'd previously 
>>> reached consensus on, as reflected in the decisions on ISSUE-13.
>> 
>> 
>> 
>> 
>> Ryan,
>> 
>> I can't agree that WebCrypto and JOSE are as separate as you claim.  WebCrypto needs to represent crypto constructs in JavaScript, JOSE in JSON; the difference in concept is only really serialization.  If we don't coordinate, we're going to have duplication.  These babies are inherently conjoined.
> 
> No. That's not the difference in concept.
> 
> For example, no matter how creative JOSE tries to get, it will never 
> be able to *efficiently* represent a File object in JSON.
> 
> JSON as a wire format is very, very different than native JavaScript 
> objects, and while you can certainly go from a JSON into an object 
> that retains some semblance, we should not be conflating the two.
> 
>> 
>> As far as the need for JW* from users, the lack of interest is not actually that surprising.  It's a network effect thing.  Right now, everyone you're trying to talk to is speaking some ancient ASN.1 language that your JS has to interoperate with.  If JOSE lives up to its charter, it should be a web-friendly replacement for things like CMS and PKCS12, so that future applications can not have to deal with ASN.1.  The trick for WebCrypto is to be able to support the legacy stuff while also looking forward.
> 
> I disagree on the network effect thing - but I certainly didn't come 
> here to bash JOSE.
> 
>> 
>> We do agree, however, that the current JOSE specs are developer-hostile, especially in the web environment.  It prioritizes wire compactness over developer utility in the worst possible way.  That's a major flaw in a JOSE, and a discussion that we should have over there.
>> 
>> Maybe I'm the only one who's fantasizing about a world where building secure apps is actually straightforward, with JOSE as a secure object format instead of CMS, and WebCrypto for the processing instead of platform APIs.  But I think that's the world we should be trying to build here, and we shouldn't be stopped by the failings of our current *draft* specs.
>> 
>> --Richard
> 
> The API should remain neutral. Which was the conclusion of ISSUE-13. I 
> don't object to JOSE for high-level, and have certainly been trying to 
> evangelize it if only to explain why some of the security decisions of 
> the API have been intentionally deferred to the protocol and 
> representational forms, but I think it's a much more serious misstep 
> to imply one is inherently superior or the future.
> 
> JOSE is simply not an alternative to ASN.1 nor an alternative to other 
> representational forms. While it may be convenient, again, the use 
> cases that JOSE sets out to solve are not in line with the use cases 
> that this API tries to solve. No matter how much fantasizing happens, 
> you're not going to see a world where SSH is suddenly replaced with a 
> JOSE-based form, nor are you going to see XMLDSig suddenly disappear 
> in favour of the one true JOSE form.
> 
> Again, I'm quite supportive of JOSE solving the problems it attempts 
> to solve, but I firmly believe, as I have always asserted, that we're 
> talking a square peg in a round hole when it's suggested that JOSE and 
> WebCrypto have significant enough overlap that all users of WebCrypto 
> should be gated on JOSE's needs.
>

Received on Friday, 18 January 2013 23:27:51 UTC