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

On Tue, Mar 29, 2016 at 4:10 PM, Ryan Sleevi <sleevi@google.com> wrote:

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

i'm not following you.


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

well supposing someone wanted to develop a web client for an existing
application which has been happily using asn.1 keys, and for one reason or
another couldn't force adoption of JWK throughout.


>
> 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. (snip)
>

that's as may be, but so far i've been able to achieve what i would call
very good compatibility between Bouncy Castle, Web Crypto, and OpenSSL with
only a reasonable amount of work on my part. so either i just got lucky, or
the situation isn't necessarily as bad as all that.


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

i think my previous point still stands. it's not about just me. we can
either have a situation where WC presses on and finishes its asn.1
compatibility, which would presumably incorporate a quality peer-reviewed
implementation, or we can take it out, and oblige anyone needing this
functionality to cobble something together. which is better?


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

and that's why i started a new paragraph :-)


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

yes, i'm interacting with another non-WebCrypto system and i would submit
that this case isn't unusual. i accept that there are no inter-system
interoperability obligations, but thanks to implementation of standard
formats by various packages, stuff demonstrably works.

it may not be that much work for me to go to JWK throughout, but again,
this isn't about just me. there are a lot of asn.1 keys around, and if the
WC API doesn't take a step towards existing standards, then my fear is that
it will get sidelined as just another ideal-world thing that didn't make it.

and hey, i'm no crypto expert, i'm just a developer trying to make stuff
work, and i want to see WC succeed.

best regards
J




>
>