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

well, i don't agree with you, but i've said my piece.


On Thu, Mar 31, 2016 at 11:03 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
> 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.
>
>