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

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


-- 
Mountie Lee

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

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World