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

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.