- From: Mountie Lee <mountie.lee@mw2.or.kr>
- Date: Wed, 10 Oct 2012 10:49:02 +0900
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Web Cryptography Working Group <public-webcrypto@w3.org>, webcrypto@googlegroups.com
- Message-ID: <CAE-+aYKQCSDLdf8XTwqQrKBBVKu_sa4wG5RAkZgUr54ni91dQA@mail.gmail.com>
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
Received on Wednesday, 10 October 2012 01:49:49 UTC