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

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<mailto:sleevi@google.com>> wrote:

On Fri, Mar 25, 2016 at 11:52 PM, Jim Schaad <ietf@augustcellars.com<mailto: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.