Re: Technology Nexus Web Cryptography API use-cases

Virginie,
Thank you very much for this elaborate answer!

I have sometimes difficulties seeing how all these things fit together.

The HTML5 WG defined <keygen> as a standard without much discussion.
If they had researched the issue a bit more they would have noted that
Apple doesn't support it in iOS and that Microsoft doesn't support it all.
The only proper conclusion they could have made is that there exists no
standard for key generation in browsers and AFAICT there is no candidate
proposal either.  IMO key-generation has nothing to do with HTML.

I recently reviewed the <keygen> implementation in Android and compared it
with a proprietary BankID app.  It is not surprising that banks do not
use <keygen>. It was great back in 1996 (!) when Netscape created it;
now we know better :-)

F.Y.I. the IETF has started a new certificate enrollment effort that
(according to the authors) is intended for "everything":
http://datatracker.ietf.org/doc/draft-ietf-pkix-est

Best regards,
Anders

On 2012-07-14 12:56, GALINDO Virginie wrote:
> Samuel, Anders,
> 
>  
> 
> Thanks for taking time to discuss your experience with the W3C Web Crypto WG.  Let me share with you few things, related to your discussion based on the use cases brought by Nexus Group (initial mail attached as a reminder).
> 
>  
> 
> The use cases related to certificate management (meaning, authenticate with certificate, sign form data, certificate enrollment) do fall into the secondary features of our charter, as suspected by Anders. This implies that it will not be treated as a priority for us, as we already have a huge work to do in 2012 to address our primary features. See our charter here for more information http://www.w3.org/2011/11/webcryptography-charter.html
> 
>  
> 
> The use cases related to sign a file, signing uploaded file, storing symmetric key in a protected area are perfectly fitting our primary features on which we are currently working on. As such, we will see how to integrate them into our use case wiki. Channy (CCed) is editing this part of our deliverables and should handle this.
> 
>  
> 
> Regarding the crypto providers you are mentioning, the group has started to discuss that possibility during one of our conference call. But at the moment, we are trying to define the different ‘properties’ of a key and see if this is not enough. In other words, instead of defining where are the key stored, we are defining specific properties of keys (e.g. key is not extractable) and it should be up to the browser to fine the appropriate implementation. We will see if this is enough to address all the possible usage, but we will keep in mind your discussion.
> 
>  
> 
> The W3C Web Crypto WG will soon publish the First Public Working Draft – probably during the summer, and thus will ask feedbacks from people like you, willing to use this Web Crypto API. We rely on you to check if this API will be usable for your respective use cases, if failing in our primary features.
> 
>  
> 
> Regards,
> 
> Virginie Galindo
> 
> gemalto
> 
> Chair of Web Crypto WG
> 
>  
> 
>  
> 
>  
> 
> *From:*Anders Rundgren [mailto:anders.rundgren@telia.com]
> *Sent:* mercredi 4 juillet 2012 08:21
> *To:* Samuel Erdtman
> *Cc:* public-webcrypto-comments@w3.org
> *Subject:* Re: Technology Nexus Web Cryptography API use-cases
> 
>  
> 
> On 2012-07-04 07:49, Samuel Erdtman wrote:
> 
>     Hi Anders,
> 
>      
> 
>     Thanks for the comments, I´ll try to explain how I was thinking.
> 
>      
> 
>     I´m not aiming to build a complete replica of Nexus Personal, what I´m mainly looking for is a common way to access a crypto provider from the browser, and then register e.g. Nexus Personal as a crypto provider to give access to smart cards. This summarizes most of the use-cases that I sent in.
> 
> 
> Hi Samuel,
> You are not alone asking for this kind of functionality.   I'm personally hesitant to this due to my negative experiences with Microsoft's "CertEnroll" scheme.   The problem (as I see it...) is that cryptographic subsystems like CryptoAPI and PKCS #11 were never designed for access by arbitrary code download from the web.   As an analogy TLS-client-certificate-authentication does its entire job without exposing any API method to the web, only the URL is needed.  Due to this I have essentially lost interest in the Web Cryptography WG; as far as I can tell it won't address "our" applications :-(
> 
> 
>  
> 
> I think that Wan-Teh's signature write-up (http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0007.html) is a subset of mine. Mine is just a more generalized description of the need for smart-card support, but with a more specific technical description.
> 
>  
> 
> Further I wanted to put soma extra focus on signatures in the Web Crypto API which currently have very few use-cases on signing (http://www.w3.org/2012/webcrypto/wiki/Use_Cases).
> 
> 
> I wonder if this WG really is properly geared for taking on a web-signature signature application.   It is MAJOR undertaking since you can end-up with anything from crypto.signText() to a 10 Mb+ application!  OTOH, few people are actually interested in this rather esoteric topic so it may pass easy :-)
> 
> 
>  
> 
> In the cases where PIN is not supported by the a SoftToken I would imagine the crypto provider either just blindly accepting the request signing it or provide the user with a dialog to accept signing operation.
> 
> 
> Yes, however, on the market were we both operate (!), this is not an accepted behavior which is the reason why BankID have (together with NexusSafe I think...) developed specific soft token solutions, most recently Mobile BankID.
> 
> Regards,
> Anders
> 
> 
>  
> 
> Cheers
> 
>  
> 
> *Samuel Erdtman*  |  Developer
> 
> *Nexus Group*  |  www.nexussafe.com <http://www.nexussafe.com/>
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> *From:*Anders Rundgren [anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>]
> *Sent:* Monday, July 02, 2012 10:13
> *To:* public-webcrypto-comments@w3.org <mailto:public-webcrypto-comments@w3.org>; Samuel Erdtman
> *Subject:* Re: Technology Nexus Web Cryptography API use-cases
> 
> Hi Samuel,
> I think most the stuff you write about is out-of-scope for the WebCrypto WG.
> 
> I don't think that you actually can build applications that mimic the Nexus "Personal" product based on /transient downloaded code/ running in a browser window.
> 
> Wan-Teh's signature write-up is though an exception since it is really a complete application:
> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0037.html
> 
> I have earlier developed a more advanced version of a Web Signature proposal:
> http://webpki.org/papers/wasp/wasp-tutorial.pdf
> http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/wasp/wasp-core.xsd
> 
> I'm (nowadays) mainly interested in Certificate Enrollment since the schemes supported by the current platforms are (as I have been banging on peoples' heads about for/years/) essentially inadequate, /in addition to being all-over-the map/.  The PIN you are mentioning in your use-case is often not even supported by the underlying crypto system like the NSS "SoftToken".
> 
> Best regards
> Anders Rundgren
> User of Nexus personal, Vendor to BankID, and PKI/Web Technologist.
> 
>  
>

Received on Sunday, 15 July 2012 05:44:29 UTC