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

fwiw, i hope we can resolve this in such a way as to keep ASN.1 support.
interoperability with existing/legacy systems helps drive adoption,
testing, verification, reputation, etc.

i for one have to redo my entire web client strategy if we lose it. i'm
lucky in that i can somewhat evolve my application to fit developing
standards and best practices, and i certainly appreciate the things WC has
taught me so far.

regards
J



On Tue, Mar 29, 2016 at 7:05 AM, <Axel.Nennker@telekom.de> wrote:

> I support Jim’s option 4 “Kill the idea of doing any ASN.1 import and
> export code at all” and RMH’s option 2 “We drop the ASN.1 formats”.
>
> The life of developers gets easier without ASN.1
>
> Axel
>
>
>
> *From:* Ryan Hurst [mailto:rmh@google.com]
> *Sent:* Montag, 28. März 2016 19:26
> *To:* Ryan Sleevi; ttaubert@mozilla.com
> *Cc:* Jim Schaad; public-webcrypto@w3.org
> *Subject:* Re: ASN.1 encoding. What is wrong and some possible ways
> forward.
>
>
>
> For implementations I believe in the axiom "Be liberal in what you accept
> and conservative in what you send.", for specifications Henry Ford's "Give
> them any color they want as long as it is black." is a more appropriate
> approach.
>
>
>
> This is, as history has taught us, a challenge with ASN.1 libraries, and I
> would hate to see that legacy find its way into the web.
>
>
>
> Given the above, I have to agree with Sleevi's conclusion, practically
> speaking these issues are only going to be resolved if:
>
> 1. UAs normalize the ASN.1 before handing down to the cryptographic
> library;
>
> 2. We drop the ASN.1 formats.
>
>
>
> PKIjs uses the ASN.1 based formats exposed by Web Crypto and based on that
> experience I think it does make sense to support them natively in
> WebCrypto. I say this because these are probably the most common formats in
> use today and many applications that will try to achieve interoperability
> existing systems will surely need them.
>
>
>
> With that said, if we we can not support them in an interoperable way they
> should be dropped.
>
>
>
> It sounds like Chrome is willing to do the work if another UA is also
> game, to that end I have added Tim so we can see if Mozilla is willing to
> make a commitment to address this issue also, from there we can decide how
> we have to proceed.
>
>
>
>
>
> rmh
>
>
>
> On Sat, Mar 26, 2016 at 9:38 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
>
> On Fri, Mar 25, 2016 at 11:52 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>
> Options going forward:
>
> 1.  Completely give up on the idea of supporting algorithms specificity for
> the import/export routines with ASN.1.  This is really the only option that
> is going to be viable in terms of getting the work done even close to the
> schedule laid out.
>
> 2.  Make a (small) step toward getting the algorithms part of the keys by
> doing what the current PSS and OAEP IETF standards say to do for public
> keys, but probably not for private keys.
>
> 3.  Go for broke and keep things as they are now.
>
> 4.  Kill the idea of doing any ASN.1 import and export code at all.
>
>
>
> Hi Jim,
>
>
>
> While I appreciate you spelling out these options, unfortunately, they
> ignore the root cause of the interoperability issues, and thus fails to
> address what's causing it. While the historical context is useful,
> fundamentally what we have is a question regarding implementors plans
> towards interoperability.
>
>
>
> As it stands today, implementations - Chrome and Firefox, at least - are
> deferring to the underlying cryptographic libraries to perform their ASN.1
> parsing. This, unsurprisingly, leads to incompatibility. One might also
> assume that Microsoft is or will do the same - thus adding to it, as NSS,
> BoringSSL, and CryptoAPI/CNG all output keys in slightly different ways,
> and are all *liberal* in different ways..
>
>
>
> I want to stress that this is a cause of interoperability issues. If one
> implementation accepts "rsaEncryption" and "id-RSA-PSS", but the others
> don't, then that's an interoperability issue - even if all implementations
> can and do import rsaEncryption. If, say, it was Chrome being liberal in
> what it accepted (accepting both), then in order for Firefox to support
> id-RSA-PSS, it would have to reverse engineer Chrome's implementation - or
> do something incompatible.
>
>
>
> So let's set the first order goal as needing to have all implementations
> being uniformly consistent in what they import, or, alternatively, fully
> specifying what all implementations import.
>
>
>
> So if we set that as our problem statement, we will see why we have
> challenges today. Because browsers are deferring to their underlying
> cryptographic libraries, and because THOSE libraries don't make stable API
> guarantees in what they will accept (after all, from the perspective of the
> library, there is no web compat concern because it's "just" a library), we
> can't have interoperability. To solve these, we would need the browsers
> themselves to do the ASN.1 parsing / normalization / validation, BEFORE
> handing to the underlying cryptographic library.
>
>
>
> This is not hard. It's not entirely unreasonable. But it needs to be
> called out here as the root cause of the interoperability concerns. And
> unless and until we know what other implementations plan to do on that
> problem, then we can't say we'll have interoperability. As such, your
> Options 1-3 are not options - they're really just variations of continuing
> the status quo, because they don't actually move to a world where things
> behave as expected.
>
>
>
> So what we have is simply two options:
>
>
>
> 1) Keep ASN.1 key types, but process them (first) in the browser, rather
> than the underlying cryptographic library
>
> 2) Remove ASN.1 key types
>
>
>
> These are the only options that move us to a Web Platform level of
> interoperability. Changes to the spec language, whether moving to
> 'informative' or loosening (as Harry has suggested in the past) or, for the
> matter, your Options 1 & 2, don't actually address interoperability - it
> requires implementation side changes. The question is: Are implementors
> willing to make the necessary changes? If not, then we should remove the
> types.
>
>
>
> If there's strong feeling that supporting these types is important, THEN
> the only viable, responsible path forward for the web platform is for
> implementations to do #1.
>
>
>