- From: Ryan Sleevi <sleevi@google.com>
- Date: Sun, 5 Aug 2012 21:32:01 -0700
- To: Web Cryptography Working Group <public-webcrypto@w3.org>
On Sun, Aug 5, 2012 at 9:24 PM, Web Cryptography Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: > crypto-ISSUE-15: Discovering certificates associated with (private) keys [Web Cryptography API] > > http://www.w3.org/2012/webcrypto/track/issues/15 > > Raised by: Ryan Sleevi > On product: Web Cryptography API > > During the July Face-to-Face, one attribute that was desired to be associated with the Key object was if the user has any associated certificates for that key. > > For operations involving digital signatures, it's highly desirable to be able to produce both a signature and embed an associated certificate. See, for example, S-MIME. > > However, exposing certificates opens a host of implementation and privacy concerns: > - Certificates associated with Keys may be transient (for example, backed on temporary storage). Should discovery be static (ie: as an attribute of the Key) or dynamic (ie: as a method on the Key) > - What is the form that certificates should take? Does this API require specifying an X.509v3 API as well? ASN.1 -> WebIDL representation? > - What are the privacy risks associated with exposing certificates to an application? Some pre-provisioned certificates may contain personally identifying information, and thus user consent may be desired before granting access to the certificate. > - Additionally, if the application can construct (temporary/ephemeral) public keys, and then execute certificate discovery on those key, they might be able to discover sensitive information about the user, without requiring access to the key handle itself. > - If key handles can be shared between origins (either at the application's discretion during key generation or based on some form of user assent/input), do certificates represent a way to smuggle information between origins, using application/x-x509-user-cert to deliver cert payloads? > > > Because of the complexities enumerated above, I would like to leave Certificates OMITTED from the FPWD. If someone feels particularly strong about certificates and exposing them via the low-level API, it would be helpful if you could provide both prose and a WebIDL description of certificates and their relationship to the Key object. Please consider use-cases and privacy concerns for pre-provisioned keys - both in terms of application/user-agent specific keys and in terms of generic pre-provisioned keys such as OS-backed keys - as well as application-generated keys. Additionally, consider alternative forms of key/cert bindings. For example, a user may upload a public certificate as part of registration, thus eliminating the need for certificate discovery. Alternatively, the application might make use of Web Intents [1] to discover a Cert-Selecting application that can allow a user to centrally manage their certificates independent of the user-agent. In light of these alternatives, I do not believe it's strictly necessary to tie Certificate objects in with the FPWD draft. [1] http://www.w3.org/TR/web-intents/
Received on Monday, 6 August 2012 04:32:29 UTC