Re: ASN.1 Encoding/Decoding Compatability

On 12/03/2015 11:25 PM, Ryan Sleevi wrote:
>
>
> On Dec 3, 2015 8:04 PM, "Harry Halpin" <hhalpin@w3.org
> <mailto:hhalpin@w3.org>> wrote:
> >
>
> > I was hoping the rest of the browser vendors would respond
> > enthusiastically, and fixing key exchange between browsers is important.
> > However, given I haven't seen a response, I'm worried that this bug may
> > take a while to fix. It's not a bug in how the spec is written (the spec
> > is correct), it's a bug in underlying key libraries.
>
> No, that's not correct. The bug is either spec or implementation - the
> key libraries are just an implementation detail, and from the POV of
> that particular key library, it is entirely conforming to its spec
>
Seems like an implementation bug to me.

Yes, but you are asking for a modification in underlying key libraries
across all browsers?

Do you think this is realistic, and if so, within which time-frame would
you expect it to ship?

W3C is trying to move to a 'ship to Rec and revise' mode, so I suspect
this would be the way forward on this bug. I'm OK with either 2) or 3),
just not waiting an indefinite amount of time - but if we have firm
commits from implementers then that makes sense. If we don't, we don't :(
>
> >
> >  Could one proposed solution simply be to *call* this bug out in the
> > spec and say that the currently for cross-browser support JWK is
> > recommended, and other key formats may not be interoperable?
> >
>
> No, that's just Option 3 by a different name - it's giving up and not
> really a spec at that point.
>
> > Since it may take some time, perhaps months (hopefully not years) to fix
> > this issue, we could put non-JWK key compatibility as part of the
> > 'maintenance mode' of the charter - and thus able to trigger a new
> > CR/Rec of WebCrypto when fixed.
> >
>
> That's just Option 2 in another name.
>
> >    cheers,
> >       harry
> >
> > >
> > > Recall that the main reasons for including the ASN.1-based formats
> was two-fold:
> > > - Support implementations that wished to defer the cryptographic
> operations - including the handling of key material - to other
> cryptographic libraries (such as those afforded by the operating
> > > system)
> > > - Support implementations that wished to communicate with other,
> non-browser cryptographic libraries (e.g. browser to
> > > server-running-OpenSSL)
> > >
> > > A third, lesser priority was that the compact, binary encoding was
> far more useful for key encapsulation (such as via RSA-OAEP), without
> needing to resort to strange JSON hacks like space-padding or larger
> key sizes to fit the larger JWK payloads.
> > >
> > > Practically speaking, I see several ways to resolve this, and
> especially wanted to get feedback from other implementers about
> concerns and direction.
> > >
> > >
> > > Option 1 [aka the current situation]) Require that implementers
> > > (browsers) have ASN.1 encoders/decoders that conform to the spec.
> > >
> > > As mentioned above, Safari doesn't support the ASN.1
> encoding/decoding at all.
> > > As I understand it, Edge is deferring to CryptoAPI at present,
> which means it also does not conform (since CryptoAPI doesn't conform
> nor should it necessarily) Firefox is currently deferring to NSS,
> which does not conform spec.
> > > Chrome is using BoringSSL, which does not conform to the spec.
> > >
> > > So basically, everyone would need to implement DER
> encoding/decoding themselves - for these specific types/formats.
> > >
> > > On the one hand, it's DER (not BER), and so it's rather 'simple'
> to do the right thing, and safely. (Firefox at present has four
> encoders, the most recent of which was very quick to write and is the
> only correct one :P)
> > >
> > > On the other hand, this means handling cryptographic keying
> material directly in the browser, and being unable to 'punt' on issues
> to another library (BoringSSL, CryptoAPI, CommonCrypto, NSS).
> > >
> > > Depending on the implementation strategy for handling JWK,
> implementations MAY already be doing this (in part), or they may be
> parsing the JWK and handing it to a crypto-library-specific,
> encoding-independent structure.
> > >
> > >
> > > Option 2) Remove support for SPKI and PKCS#8 entirely as KeyFormats.
> > > Force everything as JWK.
> > >
> > > This would remove a non-trivial part of the spec, and would
> certainly throw out backwards compatability with previous versions of
> the API (and previously authored scripts), but would not necessarily
> be the end of the world.
> > >
> > > Developers would need to write compatability shims if they wished
> to deal with SPKI/PKCS#8, such as using asn1.js or the like, much like
> they do for more advanced structures (such as X.509 or CMS messages)
> > >
> > >
> > > Option 3) Reduce the level of detail in the spec, such that it's
> up to individual implementations to 'figure out' what the encoding
> should be.
> > >
> > > To some extent, this is the state of the world in cryptographic
> libraries today. For example, OAEP when within an SPKI MUST NOT
> include the parameters, but OAEP when used as a key transport MUST
> include the parameters. Given that the API is agnostic to the
> application developers' intended usage of the public key, these sorts
> of compat problems have long existed, and are generally left to
> individual protocols to clarify.
> > >
> > >
> > > I'm not terribly keen on Option 3 - I think leaving it unspecified
> is worse for interop. Option 2 is sort of the nuclear option, but I'm
> not clear what the positions are of other browsers with respect to
> Option 1. If Mozilla and Microsoft feel the same as Apple - that is,
> > > SPKI/PKCS#8 is neither a priority nor something desired to be
> implemented in the userland - then Option 2 really is our only option.
> > >
> > > On the Chrome/Google side, we're happy to go with Option 1, and
> could live with Option 2 if we have to, but would prefer not to.
> > >
> > > Thoughts?
> > >
> > > ________________________________
> > >  This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> > > E-mails are susceptible to alteration. Our company shall not be
> liable for the message if altered, changed or falsified. If you are
> not the intended recipient of this message, please delete it and
> notify the sender.
> > > Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
> >
>