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

Thanks for summarizing the issues and history!

Speaking as Chrome's WebCrypto implementor, I would like to keep ASN.1.

I am fine with doing some variation of #1 -- handle import/export of ASN.1
types outside of our crypto library if necessary to enforce the spec's
requirements.

In fact we already need to do this for implementing the JWK format today,
so having a similar situation for PKCS8/SPKI formats doesn't appreciably
change the architecture or implementation burden for our software-based
implementation.

If we go route #1, then we have full flexibility on which OIDs are accepted
by import and used during export. But even with this power we may want to
limit ourselves to things commonly supported as Jim summarized.

I am of the opinion that being able to interoperate with the "openssl"
command line in terms of accepted OIDs is of value, and whatever other
numerous codebases that rely on OpenSSL for ingesting ASN.1 keys.

My fear with the very specific OIDs is we may end up with WebCrypto
implementations that perfectly interoperate with each other on SPKI/PKCS8
and hence close out this bug, but fail to provide in real-world use-cases
to provide a useful export format that can be fed to other (non-WebCrypto)
applications.

For this reason (and not just out of laziness because Chromium doesn't
currently accept these OIDs being BoringSSL-based), I am of the opinion
that we should drop support for the more specific OIDs as the default for
export in the spec.

Sure, this does lose round-trip information which the spec has
painstakingly tried to preserve. But I think compatibility trumps this for
usefulness. If Chromium had issues supporting the the WebCrypto specified
format, it stands to reason that other implementations will too, so we are
setting ourselves up for problems.

If we do decide to just use the generic well-supported OIDs for export
(rsaEncryption, ecPublicKey), we can still choose to accept the more
specific ones during import.

Lastly, I believe if we go this route we still have a reasonable iterative
path forward to support the more specific OIDs in future spec revisions
once the dust has settled.

The precise mechanism would of course need to be discussed by the WG, but
as a simple example we could introduce a parameter to exportKey() /
wrapKey() that lets you select the alternate (more specific) OIDs for a
fuller fidelity round-trip (exportKey parameters have already been
discussed, but just mentioning for completeness).

Cheers.

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