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