Re: draft for certificate management

On Fri, Mar 29, 2013 at 4:21 AM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> On 2013-03-29 11:55, Aymeric Vitte wrote:
>> Maybe I have a too simplistic view of the certificate subject but as I
>> see it the API should provide tools to create, manage, store
>> certificates and associated keys based on the WebCrypto API,
>
> As far as I can see _all_is_already_there_ if IndexDB can be used to
> hold arbitrary attributes associated with a key including certificates.
>
>
>> then people can build on top of it CMP, EST things if they like and
>> if web technics allow it securely, the API should support the "standard"
>> enrollment/provisioning procedures (see next sentence).
>
> They may be able to do that although it would be pretty pointless
> since they anyway have to provide JS-based bootstrap code and ASN.1
> encoding/decoding.
>
>
>> Now, as someone else mentionned in another thread, it seems like we have
>> to read between the lines to know what everybody want, would be good to
>> have clear scenario of what is required from any interested people.
>
> In particular how they intend to use an API that doesn't support
> PIN-code-protected keys which at least in the context of e-banking
> and e-government PKIs is the _de-facto_standard_.
>
> Since none of the browser-vendors have figured out how to do this in
> their current web-platforms, this brings up the #1 question:
> _What_ is the target audience?
>
> And then we have the hardware security issues...
>
> Regards,
> Anders
>

+1

Anders has accurately captured just *some* of the many problems that
are intrinsic in *any* certificate proposal.

What's also important to note is that many of these issues are
directly related to notions of key "provisioning" - which is why I
have advocated so ardently against anything more than opaque key
handles.

Received on Friday, 29 March 2013 17:50:55 UTC