RE: Commitment request from Mozilla and/or Microsoft

Ryan,

 

I am working on, and plan to continue working on what I see as both sides of what you are covering below.  

 

The make sure what is in the spec passes is, of course, both the easiest and the only one that the spec itself cares about.  However, I am also trying to write the other side of the tests.  That is to make sure that what the spec says is supposed to fail does fail.   I care less about these tests from the stand point of what the spec states in they are blocking from the stand point of an implantation is doing the wrong thing rather than the spec is wrong.  There is nothing that can be done from the W3C perspective to fix this.  As far as I know there is no international set of stocks that we can place all of the NSS developers in in the event that Firefox does allow BER rather than failing on BER.

 

If you feel that the current specification is the only possible correct one for ASN.1, then I can understand you position.  On the other hand, if you think that ASN.1 needs to work at some level and we can potentially negotiate what that level is then I don’t understand your position.

 

I do not know if Chrome is using the same library for what you are currently doing with WebCrypto and what it does for processing certificates.  But I do know that the number of broken certificates available on the market that are BER rather than DER encoded is, unfortunately, substantial.  I can hope that the percentages are decreasing but would not be surprised the X.509 chain validation people accept BER as well as DER.  This is probably the position of the NSS code and since common code is being used it makes sense for them to be in a position to currently accept BER encodings.  It might be that after we have tests they can correct this.  It might be that they believe this is wrong behavior and then you get the market argument that you have below.  Again the spec cannot fix this type of problem by itself.

 

Jim

 

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Monday, March 28, 2016 5:03 PM
To: Mark Watson <watsonm@netflix.com>
Cc: Jim Schaad <ietf@augustcellars.com>; public-webcrypto@w3.org; GALINDO Virginie <Virginie.Galindo@gemalto.com>; Ryan Hurst <rmh@google.com>
Subject: 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 <mailto: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 <mailto:sleevi@google.com> > wrote:


On Mar 28, 2016 9:45 AM, "Jim Schaad" <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:
>
>  
>
>  
>
> From: Ryan Sleevi [mailto:sleevi@google.com <mailto:sleevi@google.com> ] 
> Sent: Monday, March 28, 2016 12:57 AM
> To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >
> Cc: public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> ; Ryan Hurst <rmh@google.com <mailto:rmh@google.com> >; GALINDO Virginie <Virginie.Galindo@gemalto.com <mailto: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 <mailto: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
>
>