Re: Commitment request from Mozilla and/or Microsoft

Mark,

There's two aspects here, and you're focused on the one that Jim was, which
is expressly what I was trying to discourage.

One aspect of interoperability is ensuring everything that should pass
(e.g. is in the spec) does pass.

However, the aspect of interoperability more concerning to Jim's proposal
of a path forward is everything that should not pass, does not pass (or, if
it does pass, that *some* spec exists for it somewhere). This is where the
dynamics of, say, rsaEncryption becomes important, or NSS's support for
BER, rather than DER, becomes relevant. That's because if someone codes
against that (unspecified) behaviour, it creates an interoperability issue.
When people complain "It works in Firefox", then it becomes a matter of
"What does the spec say?" - and if sites have come to depend on the Firefox
behaviour, that creates a reverse engineering need for other UAs to support
those same sites and use cases. In effect, the first 10-15 years of W3C web
"specs".

This isn't academic. The choice of implementation strategy in Chrome and
Firefox, for example, rests on implicit *undocumented* behaviours of the
underlying cryptographic libraries - creating compat problems. The ECDH
import/export problem is a case of the first interop scenario, not the
second - the second can be observed through the BER vs DER handling of
Firefox vs Chrome.

Both matter.

On Mon, Mar 28, 2016 at 4:54 PM, Mark Watson <watsonm@netflix.com> wrote:

> I think we will have a more productive discussion - and be more likely to
> get answers from the implementors - when we can point to specific tests
> which we can point to which pass on some platforms and fail on others.
>
> Ryan - I have no reason to doubt anything you say, but could you be more
> specific ? Perhaps to the level of providing a specific test with the
> property above ?
>
> ...Mark
>
> Sent from my iPhone
>
> On Mar 28, 2016, at 9:56 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
> On Mar 28, 2016 9:45 AM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> >
> >
> >
> >
> >
> > From: Ryan Sleevi [mailto:sleevi@google.com]
> > Sent: Monday, March 28, 2016 12:57 AM
> > To: Jim Schaad <ietf@augustcellars.com>
> > Cc: public-webcrypto@w3.org; Ryan Hurst <rmh@google.com>; GALINDO
> Virginie <Virginie.Galindo@gemalto.com>
> > Subject: Re: Commitment request from Mozilla and/or Microsoft
> >
> >
> >
> >
> > On Mar 27, 2016 6:59 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> > >
> > > Can we get a commitment from Mozilla and/or Microsoft to implement the
> > > import and export of private keys using the pkcs8 structure for ECDSA
> and
> > > ECDH?
> > >
> > > This is the gating factor to keeping the option 1 ASN.1 import/export
> > > functions as outlined in my previous mail.
> > >
> > > As the chair - can you try and get answers for this Virginie?
> > >
> > > Jim
> >
> > Jim,
> >
> > Is there a reason you focused only on ECDSA and ECDH, rather than RSA
> (PKCS#1 v1.5, PSS, and OAEP)?
> >
> > Regardless of scope, the question you pose has been repeatedly asked and
> left unanswered for several months. I appreciate the new calls for it, but
> we are precisely in this position because of the multiple unanswered calls
> in the past, on the list, from the chair, and from other implementors.
> >
> > Ryan,
> >
> > Because, as implied in my message above, for the option 1 that I laid
> out in a previous message they all work.  I believe that I have done a
> successful import of keys for RSA v1.5, RSA PSS and RSA OAEP using the
> rsaEncryption OID.
>
> Jim, for the reasons outlined in my previous message, I hope you can
> realize that while this interoperability is a positive step, it is
> insufficient for the level of the Web Platform. As we try to clean up the
> past decades' worth of decisions like this, and the interoperability
> problems it has caused, we should be wise to not repeat it.
>
> If an implementation exposes behaviour, it should be specced, so that
> other implementations can expose similar behaviour. If there is not
> consensus to expose that behaviour, it should be removed.
>
> For that reason, the RSA algorithms are and remain a problem, even with
> the rsaEncryption interoperability. I simply must stress this - your
> proposal does not solve the concerns for RSA, and we still need
> implementors to assist.
>
> > I have successfully done import for ECDSA and ECDH for JWK public, JWK
> private, and ASN.1 public using ecPublicKey but do not have a success for
> using ecPublicKey to do private key import.
> >
> > Jim
> >
> >
>
>