Fwd: [Moderator Action] Re: ASN.1 Encoding/Decoding Compatability

Redirecting - harry


-------- Forwarded Message --------
Subject:  [Moderator Action] Re: ASN.1 Encoding/Decoding Compatability
Date:  Wed, 02 Dec 2015 21:14:58 +0000
From:  RenThraysk <renthraysk@gmail.com>
To:  GALINDO Virginie <Virginie.Galindo@gemalto.com>
CC:  Ryan Sleevi <sleevi@google.com>, Oliver Hunt <oliver@apple.com>,
Richard Barnes <rbarnes@mozilla.com>, Michael Jones
<Michael.Jones@microsoft.com>, public-webcrypto@w3.org
<public-webcrypto@w3.org>



Hi,

Regarding the EDCH cross browser problem. I opened the chrome bug #532728.

If Chrome had raw importing/exporting implemented ( #437576 ), this
would be less of a problem.

The workaround was to export as spki, and then discard the tags. (Taking
the last 65, 97 or 133 bytes depending on which curve. Ugly.) to send
keys across the wire, and prefix them to import.

Ren




On Wed, Dec 2, 2015 at 5:06 PM, GALINDO Virginie
<Virginie.Galindo@gemalto.com <mailto:Virginie.Galindo@gemalto.com>> wrote:

    Ryan, Olivier, Richard, Michael,
    I can only encourage you to progress on that incompatibility issue
    and see which of the option below better suit your implementations.
    As chair my favorite choice goes for option 1 or 2.
    We really need to come across that problem and move on towards PR
    (or go back to WD in case of substantial changes).
    Do you want that we set up a call so that we all discuss that  ?
    Thanks for your reactivity.
    Regards,
    Virginie


    -----Original Message-----
    From: Ryan Sleevi [mailto:sleevi@google.com <mailto:sleevi@google.com>]
    Sent: mercredi 2 décembre 2015 04:33
    To: public-webcrypto@w3.org <mailto:public-webcrypto@w3.org>
    Cc: Richard Barnes; Oliver Hunt; Michael Jones
    Subject: ASN.1 Encoding/Decoding Compatability

    One concern with advancing to PR is that, although we have some
    degree of implementation of the underlying cryptographic algorithms,
    there still exists a large swath of compatability and compliance
    issues with respect to the encoding and decoding of key material.

    I'd like to propose that we HOLD on advancing to PR until we can
    agree on a plan to resolve this, especially given that some of the
    options may break backwards compatability. To put a concrete example
    on it, Chrome and Firefox ECDH keys are not exchangable, due to a
    Chrome spec issue. Further, Safari doesn't implement the spki/pkcs#8
    bits at all, and Edge doesn't support ECDH, so we fail to meet the
    necessary number of minimum implementations for what is arguably a
    highly-desirable algorithm!

    As presently specified, the WebCrypto spec attempts to be very clear
    exactly how the SubjectPublicKeyInfo and PKCS#8 PrivateKeyInfo are
    encoded. However, as specified, this presents issues for
    interoperability between browsers, but also between other
    cryptographic libraries. The Chrome compat issue, for example, is
    caused by the underlying BoringSSL library, and it's behaviour in
    rejecting that key is consistent with that of all versions of OpenSSL.

    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.