Re: ASN.1 encoding. What is wrong and some possible ways forward.

On Tue, Mar 29, 2016 at 3:55 PM, Jason Proctor <jason@mono.hm> wrote:

>
> On Tue, Mar 29, 2016 at 11:00 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>>
>> On Tue, Mar 29, 2016 at 8:33 AM, Jason Proctor <jason@mono.hm> wrote:
>>
>>> i for one have to redo my entire web client strategy if we lose it.
>>>
>>
>> Can you explain why this is? Why doesn't simply using asn1.js to ingest
>> the BER/DER data and spit out a JWK for import, or, on export, take a JWK
>> and convert using asn1.js to BER/DER, suffice?
>>
>> What functionality is provided by the ASN.1 support that cannot simply be
>> done by converting to/from JWK?
>>
>
> well, i could write a chunk of conversion code, true enough. but then
> everyone who has to support asn.1 keys has to do it, and i'd prefer it get
> done once by people who know what they're doing and then shared, instead.
> so i'm in support of the browser doing it.
>

I appreciate you humoring me with your reply.

Can you explain what you mean by what "has to support ASN.1 keys" means? In
particular, what requirement is there?

As you can see from this thread, and the many archives, unfortunately,
there's a clear lack of consensus in the world today (independent of
browsers) as to what valid keys are. This comes from a variety of reasons -
PKCS#8/CMS using BER (rather than DER), bugs in DER encoders/decoders
leading to gross spec violations (e.g. OpenSSL and negative BIG INTEGERs),
partial implementations. So there's no guarantee, today, that a key you
export via OpenSSL will be imported via NSS or CryptoAPI, for example.
Further, this albatross of legacy prevents resolving real security bugs
(e.g. NSS's recent *three* remote-code-execution bugs in the BER parser).

So, as a practical matter, you already should be ensuring that
1) The keys you export - whether JWK or ASN.1 DER - conform to the
WebCrypto spec if you're going to send to a browser
2) The keys you import into your proprietary system - whether JWK or ASN.1
DER - can be converted into a format your system finds acceptable.

It doesn't sound at all like there's a fundamental reason you can't use
JWK; merely, that you'd prefer not to have to write code to convert. Is
that a fair and accurate statement?


> IMHO, if WC doesn't support the standard(ish) formats that people have
> around, that's a barrier to adoption, and i'd like to see as few of those
> as possible.
>

Well, now you're talking about something even more different :)

It sounds like you're wanting to interact with some other (non-WebCrypto)
system, is that correct? As presently spec'd, there are no guarantees of
that - precisely because we, as the WebCrypto WG, have no idea what other
non-WebCrypto system you're trying to interact with, nor that it will
reliably export the same format as spec'd as viable for import, nor that it
will import what WebCrypto has spec'd for output.

In short, while the "spki" and "pkcs8" formats may seem appealing, they
don't seem necessary for your use case. However, I'd like to make sure I
haven't misunderstood your requirements - if there is functionality you
need that is intractably and inextricably linked to needing the browser to
process SPKI/PKCS8.