Re: Web Crypto API Scope (primary/secondary/out of scope) - gemalto comments

On 12/11/2011 06:20 PM, GALINDO Virginie wrote:
> Dear all,
>
> you will find here my comments on the current version of the Web Crypto API Scope.
>
> - On the primary features I feel quite comfortable with the existing list.
>
> - Nevertheless I can not imagine that the charter is classifying as a secondary feature the  multiple key container configuration. Mobile do have multiple secure storage today (UICC, plus SD, plus sometimes Trusted Execution Environment or MTM, plus  local mobile memory), PC do have multiple storage today (TPM, plus  smart card, plus local PC memory). In June 2013 this will be a common configuration. How will the browser monitor the location of the credentials ? If this WG is only envisaging the storage of credentials in a local memory of the device, then I dont see where the security improvement is.

Primary scope is basically DOMCrypt as it stands plus the simplest key 
storage mechanism we can imagine, as currently DOMCrypt only does 
ephemeral keys. While of course most devices will have multiple key 
containers, unless I see a clear and ideally strawman on actually to how 
to do multiple key containers in a developer-friendly manner on top of 
something that resembles DOMCrypt.

You have to identify key containers, but how? Do you want to enable 
keypair export/import per container? How do you do that without a good 
ACL system? Tough questions that it seems a WG could address, but for me 
putting this within primary scope will be tough unless we get a clear 
strawman.

To me, the real question is should any persistent key storage and 
control be moved to secondary scope? At TPAC people wanted it in scope 
(such as Netflix), which is why I moved it into primary scope.

> -->  As a consequence, I would recommend to migrate the multiple key container configuration as a primary feature.
>

See above.
> - The  out of scope session is fair and will definitely the group to stay in the right boundaries. But frankly speaking I can not agree with the vague wording "sophisticated access control mechanism, advanced smartcard or other device-specific features". This boundary will definitely not help the group to make the  decision of what is, and what is not in the scope. I do have  thousands of advanced smart card feature which will fall in the  scope of this API :-). Depending on where industry you come from, you might interpret differently.
> -->  This  section definitely need some wording : which feature do you want to avoid ? (I guess there must be an historical background somewhere in the 500 mails exchanged over the public mailing list, but in 6 months it will not be clear to new  comers).
>

I would say device-specific features that require the special calls or 
parameters per the type of device would be out of scope at this point. 
So, this would include things like "EnableSmartCardEvents" in Channy's 
draft [1], or SIMcard-based GBAA . Now, I would say 
"EnableNewKeyContainer" would be in scope of secondary features, where 
that KeyContainer could be a smartcard with trusted hardware, or GBAA 
enabling the generation of a keypair.

  Again, I'd like to see a strawman of how that would work in a generic 
way that doesn't trap Javascript WebApp Developers in smartcard, SIM, or 
other device-specific parameterization. Because there's a lot of devices 
out there, and I'm not sure if it makes sense to try to handle all of 
them. Any strawmen besides Channy's?

Things that don't have implemented or at least complete strawmen I'm 
inclined to keep in secondary features or out-of-scope.

[1] http://html5.creation.net/webcrypto-api
> Hope this makes sense to you, guys.
>
> Regards,
> Virginie
> gemalto
>
>
>
>
>

Received on Monday, 12 December 2011 14:38:40 UTC