Re: Commitment request from Mozilla and/or Microsoft

On Mon, Mar 28, 2016 at 8:33 PM, Jim Schaad <ietf@augustcellars.com> wrote:

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

Jim,

I'm not sure we're on the same page of concerns. It's absolutely relevant
if Firefox exposes that functionality, just as it would be if Chrome
exposed some functionality that was unspecified.

That's why committment for ASN.1 has multiple dimensions:
1) We need agreement that it's something to keep
2) We need agreement that if we do keep it, we consistently accept 'good'
inputs
3) We need agreement that if we do keep it, we consistently reject 'bad'
inputs

"Bad", in this case, is anything which doesn't have a spec attached.

We can write tests for 'good'. We can write tests for 'bad'. We can't
exhaustively cover every 'bad' permutation (e.g. what if Chrome only
accepts this input on the 5th Friday of years divisible by 4), but we can
cover ample.

However, to get even a modicum of baseline regarding #2/#3, this requires
that implementations *not* just expose their underlying ASN.1
implementation, because you can't guarantee #2 / #3 if you do. And because
of that, that's why we're having the debate about #1.

Does that make it clearer as to where the concerns are?


> 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 have no idea why you introduced the idea of negotiation. It's really
quite simple. A conforming implementation should accept what the spec says
is valid, and reject *everything* else. Anything which it accepts as valid,
but which the spec does not say is valid, is an implementation bug that
will create compatibility hell.

There are ample examples of this already. To address this, you simply
*cannot* use your (BoringSSL, OpenSSL, NSS, CryptoAPI/CNG) ASN.1 parser,
because none of these libraries guarantee the interop necessary for the web
platform. They guarantee interop among themselves and their respective
consumers, but not across the broad spectrum.


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

I wholly and completely disagree with this philosophy, for the reasons I
expressed above. This is nothing new here that any spec author has to deal
with. We're quite adept at dealing with it. That's why we need to make sure
not to repeat the mistakes we've done.