W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

RE: W3C Web Crypto WG - progressing on ISSUE-36

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Mon, 3 Mar 2014 21:22:21 +0000
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <e63fcb855c654b4bad655cc48a2b382d@DFM-TK5MBX15-08.exchange.corp.microsoft.com>
I opened bug 24902 for the PBKDF2 issue. (Hooray, bugzilla let me through this time!)

From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
Sent: Monday, February 24, 2014 8:47 AM
To: GALINDO Virginie
Cc: public-webcrypto@w3.org
Subject: RE: W3C Web Crypto WG - progressing on ISSUE-36

I looked through the latest draft. The password parameter is clearly called out as optional for UAs who want to provide secure prompting, and I am okay with this in principle.

However, it is not clear to me how to set baseKey in such a case. It seems natural that in this case baseKey would be null, but that does not seem to be allowed by the descriptions of deriveKey and deriveBytes.

If we can't easily clarify how it would be used by a developer, I propose to just strike this optional parameter for v1 and revisit it later. I suspect the entire question of UA-driven trustworthy UI would be a significant one and IIRC this is why we stayed away from UI issues in the rest of the spec.

From: GALINDO Virginie [mailto:Virginie.GALINDO@gemalto.com]
Sent: Monday, January 20, 2014 5:40 AM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: RE: W3C Web Crypto WG - progressing on ISSUE-36

Vijay and all,
Let's close ISSUE-36.
Lets see where does that password concern comes from. At a first glance I do not see any bug related to that problem (if any).
Virginie




From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
Sent: mardi 14 janvier 2014 18:39
To: GALINDO Virginie
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: RE: W3C Web Crypto WG - progressing on ISSUE-36

I think you are referring to the email where I raised these two issues:


1.      I am leery of the password parameter in the AlgorithmIdentifier for PBKDF2. This is key material and I think we should be very careful about putting key material in identifiers. As mentioned in the other thread I would prefer something like importKey to create a Key here.


==> I don't recall the discussion we had about this and I can't find the Shenzhen minutes. Does anyone else remember?

2.      For deriveKey and generateKey, I am not sure I understand the algorithm descriptions. Nowhere does either description say that these methods should construct and return a Key object. Shouldn't the penultimate step be something like "Let keyMaterial be the result of executing the key generation algorithm defined by the algorithm indicated in normalizedAlgorithm, and result be a Key object obtained by executing the importKey procedure with format set to "raw", keyData set to keyMaterial, and algorithm to derivedKeyType"?


==> This was addressed on the call - the data types of the return values are in the algorithm-specific sections. So consider this resolved.

From: GALINDO Virginie [mailto:Virginie.GALINDO@gemalto.com]
Sent: Thursday, January 9, 2014 9:58 AM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: W3C Web Crypto WG - progressing on ISSUE-36

Hi Vijay,
In order to progress on the ISSUE-36 [1], can you confirm that you are happy with the derivebits recent proposal ?
Your last mail related to it raised some issue, did you transform it into bugs ?
Here again, I am trying to define if the ISSUE-36 and/or ACTION-127 can be closed.
Regards,
Virginie

[1] http://www.w3.org/2012/webcrypto/track/issues/36

________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus

________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus
Received on Monday, 3 March 2014 21:22:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:21 UTC