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

I am planning to try and get some time with some of the people maintaining OpenSSL next week at the IETF to see what would be required to get them to accept the PSS OID for public keys.  Given the move of TLS towards eliminating RSA v1.5 and only allowing PSS signatures for RSA in the core algorithm, there will hopefully be a push to get RSA-PSS keys in certificates as well.  There are lots of arguments about this on the list but it might be enough to start pushing this implementation into accepting them.

 

This would not do anything to get OAEP moving forward to be algorithm specific however.

 

Jim

 

 

From: Eric Roman [mailto:ericroman@google.com] 
Sent: Monday, March 28, 2016 10:34 AM
To: Ryan Sleevi <sleevi@google.com>
Cc: Jim Schaad <ietf@augustcellars.com>; public-webcrypto@w3.org
Subject: 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 <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.