RE: crypto-ISSUE-15: Discovering certificates associated with (private) keys [Web Cryptography API]

Hello Mountie,

Thanks for sharing the use cases.

At the moment the WG is not focusing its effort on the management of certificate, but we definitely need to archive your request. You are raising here two technical points that we will have to manage when we come to this topic :

-          Which information the API will access to search keys by certificate?

-          How to solve the coding fragmentation aspects on this information ?

-          How to make this search after user consent - which is definitely out of the scope.

Regards,
Virginie



From: mountie@paygate.net [mailto:mountie@paygate.net] On Behalf Of Mountie Lee
Sent: mercredi 10 octobre 2012 03:49
To: Ryan Sleevi
Cc: Web Cryptography Working Group; webcrypto@googlegroups.com
Subject: Re: crypto-ISSUE-15: Discovering certificates associated with (private) keys [Web Cryptography API]

Hi.
I think NOW is right time to discuss more about certificate.

in low level API, I want to make sure followings related certificate.

1.  language specific issues
- when CA issue the certificate, they add some display text into the certificate that is non-ascii text.
- because of MS IE feature, UTF8String was not available to be used to Korean in DisplayText,
- and BMPString is accepted to display Korean.
- BMPString is also one of available options by RFC 3280
- can Webcrypto API handle BMPString that is extracted from certificate via API ?

2. retrieving information from certificate
- I know it has privacy issues.
- in Korea, many informative/operational information is inserted to X509 Certificate Extensions.
- some custom extensions were also added to certificate
- to which level the API will allow accessing certificate information?
- can we handle the certificate as the different type of public key ? (that is theoretically can be open to the public)

regards
mountie.

On Mon, Aug 6, 2012 at 1:32 PM, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:
On Sun, Aug 5, 2012 at 9:24 PM, Web Cryptography Working Group Issue
Tracker <sysbot+tracker@w3.org<mailto:sysbot%2Btracker@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/



--
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net<mailto:mountie@paygate.net>


=======================================

PayGate Inc.

THE STANDARD FOR ONLINE PAYMENT

for Korea, Japan, China, and the World