Re: ASN.1 encoding. What is wrong and some possible ways forward.

On Thu, Mar 31, 2016 at 10:43 AM, Jason Proctor <jason@mono.hm> wrote:
>
> Can you explain what you mean by what "has to support ASN.1 keys" means?
>> In particular, what requirement is there?
>>
>
> well supposing someone wanted to develop a web client for an existing
> application which has been happily using asn.1 keys, and for one reason or
> another couldn't force adoption of JWK throughout.
>

You don't need to force the adoption of JWK throughout - only to your
front-end.

I'm trying to understand what's different about, say, needing to adapt from
Win32 UI APIs to HTML, or, on a more practical level, switching from a push
messaging service like iTunes or Android and adopting WebPush.

You choose the right technology for the problem at hand. The goal is not to
ship everything, it's to ship what's necessary. And my goal in this thread
is to find why ASN.1 is necessary for your use case. So far, I've only got
"it's less work", and that's... not the same.


> i think my previous point still stands. it's not about just me. we can
> either have a situation where WC presses on and finishes its asn.1
> compatibility, which would presumably incorporate a quality peer-reviewed
> implementation, or we can take it out, and oblige anyone needing this
> functionality to cobble something together. which is better?
>

It doesn't really, unfortunately. The goal of shipping code in browsers is
not to provide a "Javascript Standard Library" of every functionality that
people need. It's to provide a suitable set of primitives, in particular,
those which can ONLY be accomplished through coordination in or with the
browser, and let application developers compose.

This is the zeitgiest of https://extensiblewebmanifesto.org/ - and so to
answer your question of "Which is better", it's actually better to let
application developers deal with the ASN.1 encoding, objectively, precisely
because of the various issues. It only becomes a matter for needing
treatment in the browser if and only if there's something unique which can
only be accomplished by the browser - and from your use case, that
certainly doesn't seem the case.


> It sounds like you're wanting to interact with some other (non-WebCrypto)
>> system, is that correct? As presently spec'd, there are no guarantees of
>> that - precisely because we, as the WebCrypto WG, have no idea what other
>> non-WebCrypto system you're trying to interact with, nor that it will
>> reliably export the same format as spec'd as viable for import, nor that it
>> will import what WebCrypto has spec'd for output.
>>
>
> yes, i'm interacting with another non-WebCrypto system and i would submit
> that this case isn't unusual. i accept that there are no inter-system
> interoperability obligations, but thanks to implementation of standard
> formats by various packages, stuff demonstrably works.
>

It demonstrably doesn't, though. I'm happy that you haven't run into them,
but there are so many myriad ways to demonstrate the interoperability
problems, that it's unacceptable for a Web-facing spec. I mean, even simple
things like ordering the first two primes within the RSA private key, as
specified in the spec, can't be reliably enforced due to legacy systems and
quirks of embedded systems. So the ability for a UA to implement the spec,
and expect it to work, is simply not there IF we accept 'legacy' as part of
the calculus.

That's why it has to be explicitly spec'd as to expectations, so that
there's a clear and consistent understanding about the behaviours. And that
means that legacy systems - those which do all sorts of untoward and
horrible things - will need to change, or you, as an application developer,
will need to do the same thing the vast majority of application developers
have been doing for the past several decades - writing glue code to bridge
your legacy system with your modern system in order for your use case to
continue to work, and for you to take advantage of the new shiny without
giving up your old and busted.


> it may not be that much work for me to go to JWK throughout, but again,
> this isn't about just me. there are a lot of asn.1 keys around, and if the
> WC API doesn't take a step towards existing standards, then my fear is that
> it will get sidelined as just another ideal-world thing that didn't make it.
>

OK. That's your fear, and while I appreciate the concern, I don't feel it's
valid. There's plenty of new and unique functionality that can only be done
in the browser being exposed here (for example, the constant-time safe
algorithms) that are simply not possible on the web today.

But with ASN.1 encodings? That's clearly possible on the Web today - as
shown by pure-JS solutions like asn1js or by even more convoluted solutions
such as transpiling libraries like OpenSSL to asm.js or WebAsm (which can
and do exist).

There's nothing special about the formats here that necessitates in-browser
functionality. There's no performance argument to be made on the need to
necessitate in-browser functionality, and even if there was, it'd require
careful analysis to see if it's just a matter of trying to do something you
obviously shouldn't be doing (that is, there's lots of ways to create
self-inflicted performance problems)

At the end of the day, WebCrypto is not designed to be the "interop with
your existing systems" spec. That's because your existing systems fail to
follow any of the relevant specs (NSS, OpenSSL, BouncyCastle) in a way that
can guarantee interop. WebCrypto is designed to provide you something that
only the browser can provide, given the language - such as the
constant-time aspect - that would otherwise be impossible in (Web) JS.

This is truly a problem for the Web - if you're talking about something
like Node, you already have a clear and easy solution to the problems
WebCrypto tries to solve, because you can simply drop-down to / introduce
native bindings for your underlying library. That's part of why I reject
the notion that non-browser JS use cases are in scope - because again, the
goal is not to provide the Javascript Standard Library, it's to empower
developers and authors with the necessary primitives to accomplish their
work.