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

@Rob/@Tim, see below:

On 03/28/2016 01:33 PM, Eric Roman wrote:
> 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).

+1 to "handle import/export of ASN.1 types outside of our crypto library
if necessary to enforce the spec's requirements.". This sounds very
sensible and while I support both specific WebCrypto OIDs if possible
(but think rejigging our underlying SSL libraries is going to be a
non-starter for the time being) but we do need to get interop using
OpenSSL OIDs.

One  problem has been resourcing. However, if we can get a consensus
method way forward, note that Microsoft and Mozilla have allocated
resources to WebCrypto.

Rob? Tim? Any opinions on whether or not to go forward ?

I think we should should try to get the proposals (and have a few
variations) as specific as possible before our next telecon next week.

  cheers,
      harry

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