Re: Commitment request from Mozilla and/or Microsoft

On Tue, Mar 29, 2016 at 8:40 AM, Mark Watson <watsonm@netflix.com> wrote:

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

(Just a slight tweak - they need to have enough functionality outside to
validate import and construct the export; both, not either/or)

Oh, to be clear, my view is that _if we do nothing_, it's all terribly
broken and won't work. That said, we do have paths forward to make it work.
The problem is making sure that we have consensus that this is the way to
solve the problem (on a conceptual stage), and to a lesser extent, a
committment on UAs to actually move towards that.

The problem is that, on the conceptual point, we heard some objection in
the past from Microsoft with respect to treating ASN.1 outside of the
crypto library (this had been echo'd primarily through Vijay, Brian, and
the crypto team at Microsoft), and we certainly know that Safari has not
done anything to treat that. It's useful, for both points, to understand if
this is a fundamental objection, a matter of resources/priorities, or
something different.

It would also mean that Mozilla would need to change their implementation.
You wanted concrete examples, and there's plenty - the key import accepts
BER, rather than DER, so it's very easy to find any number of BER
pemutations accepted by Firefox but rejected by Chrome (indefinite length,
constructed BITSTRINGs). With a little more work, you can find more subtle
DER behaviours in Chrome (the handling of parameters for RSA keys, for
example).

On the Chrome side, we're absolutely committed that, if we continue to
support ASN.1, we'll do the processing as spec-compliant as possible, and
when there are bugs, we'll work to address them. But that work only works
and makes sense if other implementations share the same vision of the
end-goal - which is the two conditions I outlined, and which you accurately
restated. If we're not in agreement that this is where we should be moving
towards, then it's more fundamental a problem than a matter of resources
and staffing, and we absolutely need to solve what that vision is or should
be (if not this), before we progress.