Re: Commitment request from Mozilla and/or Microsoft

Hi Ryan,

Thanks - things are getting clearer, but I still read some of your response
as "it's all terribly broken and will never work", wheras I'd like to get
to a more specific understanding of exactly what is wrong.

Lets say, for arguments sake, that we can define a set of highly specific
ASN.1 formats which MUST be supported for *export* and which are supported
across browsers (anything which is not supported by 2 implementations we
would remove). No other export formats are defined in the specification.

Now, for import, we specify that those exact same format MUST be supported
and *any other formats* MUST return an error.

And, finally, suppose we have two implementations that support both of the
above requirements.

Are there any remaining problems ?

If no, then the requirement for browsers seems rather less than has been
stated: it is necessary only to have enough ASN.1 functionality outside the
crypto library to validate that the provided data is in one of the
specified formats and return an error if not.

...Mark

On Mon, Mar 28, 2016 at 5:03 PM, Ryan Sleevi <sleevi@google.com> wrote:

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