Re: [W3C Web Crypto WG] about extensions to Web Crypto specification

Sent from my iPhone

> On Sep 22, 2014, at 8:17 AM, Harry Halpin <hhalpin@w3.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>> On 09/16/2014 04:15 PM, GALINDO Virginie wrote:
>> Thanks Mark for that wise suggestion. Let’s set the limit to
>> propose alternatives on your proposal below to *Friday 19th of Sept
>> 23:59 (California time)*.
>
> Since I haven't seen any other alternative proposals, we can go
> forward with Mark Watson's approach. While a  parameterized hash
> algorithms would be nice, it's probably not necessary.

My approach does support such things as parameterized hash algorithms,
as we allow extension specifications to redefine the entire import /
export procedure.

>
> Mark Watson, do you have time to go through the spec and update it by
> Friday this week?

Yes.

>
>> Virginie
>>
>>
>> From: Mark Watson [mailto:watsonm@netflix.com] Sent: mardi 16
>> septembre 2014 16:08 To: GALINDO Virginie Cc:
>> public-webcrypto@w3.org; Ryan Sleevi; Harry Halpin; Wendy Seltzer;
>> Mike Jones Subject: Re: [W3C Web Crypto WG] about extensions to Web
>> Crypto specification
>>
>> Note that it would take a few days to replicate this approach
>> across the other parameterizable algorithms. I suggest we set a
>> deadline and in the absence of constructive comments or concrete
>> alternatives we go ahead with this approach.
>>
>> ... Mark
>>
>> Sent from my iPhone
>>
>> On Sep 16, 2014, at 6:48 AM, GALINDO Virginie
>> <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>>
>> wrote: Hi all,
>>
>> Any reaction to that proposal ? Silent means consent, at this
>> stage. Reminder : we will exit Last Call Monday 29th of Sept. And
>> this one is the last outstanding bug open…
>>
>> Regards, Virginie
>>
>> From: Mark Watson [mailto:watsonm@netflix.com] Sent: jeudi 11
>> septembre 2014 19:18 To: Mike Jones Cc: Ryan Sleevi; GALINDO
>> Virginie; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>;
>> Harry Halpin; Wendy Seltzer Subject: Re: [W3C Web Crypto WG] about
>> extensions to Web Crypto specification
>>
>> All,
>>
>> So, by way of an example and to move the discussion forward I have
>> implemented extensibility for RSA-OAEP hash algorithms in the
>> Editor's Draft. Obviously we need to agree a common approach for
>> all algorithms, so this text is subject to change.
>>
>> As it happens, the encrypt, decrypt and generate key procedures are
>> already independent of the hash algorithm. In Generate it just
>> copies the name (in particular, generate key does not fail if the
>> hash algorithm is unsupported, though we might want to reconsider
>> that). For encrypt and decrypt, the RFC3447 procedures referenced
>> are not hash-algorithm-specific.
>>
>> So we are left with import and export. We could take an approach
>> where an extension specification must define procedures which map
>> OIDs to hash algorithm names, hash algorithm names to OIDs, JWK alg
>> values to hash algorithm names and hash algorithm names to JWK alg
>> values i.e. there would be four procedures in the extension
>> specification which we might call "OID to hash algorithm mapping
>> steps" etc.
>>
>> However, this is a limited form of extensibility, in that it
>> assumes that any future hash algorithm is fully specified only by
>> its name. One can imagine parameterized hash algorithms, like {
>> name: "sha-next+1", params: { iterations: 200 } } and the limited
>> extensibility above would not support that.
>>
>> What I have implemented is more general (and also simpler to
>> implement in the specification). Extension specifications are free
>> to define their own import / export process and only if the
>> extension specification steps return "NotSupportedError", or if
>> there are no applicable specifications, do we follow the procedures
>> of our specification.
>>
>> Comments welcome!
>>
>> ...Mark
>>
>> On Wed, Sep 10, 2014 at 3:53 PM, Mike Jones
>> <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
>> wrote: I think it would be highly useful to see an actual write-up.
>> That way we’d have something to review and either adopt or tweak.
>>
>> -- Mike
>>
>> From: Ryan Sleevi
>> [mailto:sleevi@google.com<mailto:sleevi@google.com>] Sent: Monday,
>> September 08, 2014 12:15 PM To: Mark Watson Cc: Mike Jones; GALINDO
>> Virginie; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>;
>> Harry Halpin; Wendy Seltzer Subject: Re: [W3C Web Crypto WG] about
>> extensions to Web Crypto specification
>>
>>
>>
>> On Mon, Sep 8, 2014 at 9:53 AM, Mark Watson
>> <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
>>
>> ​Would people find it useful to see, in our specification, what the
>> approach referenced by Anne [0] for adopt [1] and clone [2]  in DOM
>> would look like ?
>>
>> I'd be happy to draft the changes for one algorithm (say RSA-AOEP)
>> to enable extensibility in the choice of hash algorithm.
>>
>> We should bear in mind that this approach allows only for very
>> specific extensions to existing algorithms. For example adding a
>> new hash algorithm to RSA-OAEP. If you want to do something that we
>> don't explicitly provide for, then you need a new algorithm.
>>
>> One comment to Ryan below...
>>
>> ...Mark
>>
>> [0] http://annevankesteren.nl/2014/02/monkey-patch [1]
>> http://dom.spec.whatwg.org/#concept-node-adopt [2]
>> http://dom.spec.whatwg.org/#concept-node-clone
>>
>> On Thu, Sep 4, 2014 at 11:46 AM, Ryan Sleevi
>> <sleevi@google.com<mailto:sleevi@google.com>> wrote: The previous
>> proposed wording was presented as a general "Any other spec can
>> modify anything about this", which is itself the definition of
>> monkey patching.
>>
>> The concern is that we need to be explicit and judicious in what
>> and how something is extended and how that's reflected to the user,
>> as the named curve discussion has shown at great length.
>>
>> For example, in the clone example above, it's precisely stated what
>> the inputs are and what the viable outputs are. We would need that
>> same level of precision, at a minimum, at our extension points.
>>
>>
>> ​Actually, those examples precisely state the inputs to the
>> "additional steps" defined by "applicable specifications", but they
>> don't appear to constrain what those additional steps can be - that
>> it, the outputs are not defined.
>>
>> Sure it does. Read Step 2 and Step 7 of Clone. You get a node back
>> that implements the same interfaces as the source.
>>
>>
>> In the example of providing for future hash algorithms with
>> RSA-OAEP, we would explicitly defer to "applicable specifications"
>> how the hash algorithm is represented in JWK, say, by referring to
>> "JWK serialization steps" defined by that "applicable
>> specification" to be run when the name attribute of the hash
>> parameter has a value defined by that specification. But we would
>> not need to constrain those "JWK serialization steps" to providing
>> only the "alg" member of the JWK.
>>
>>
>>
>> ________________________________ 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJUID1GAAoJEPgwUoSfMzqcHegP/iilu2KWg3TPCrjy5cHHu8yy
> aL3pAgpMjtU9fjY1EbkItgzmt58baYO7ATGmqdx+3hGwBk19G48EOJXR4JL8j9FZ
> yvbYGw2W4f9VRmmIPPpbAgQUUeAQU1mKDktO4eYakfJEgJ2HbvFl91nvnB/FHblt
> gDhwk7QBQDIB4rVkErJSTmQRfn+7rpgxTWZhC9Vnz9VyXXZdl/il4QA7naj+Ss2T
> AMR8nO73iD+dNkClSuJjX/mvlhc+6QTVSmRJI2ct/Z9X3Ui8uUf4cbnkDoXahBAH
> AhxI7eSewhLOKtpZ21cp8oRiPaH529/QwuJyKVjw9dOaSFrySkkBFSOoknGLTVEE
> FcirbjpLhgPepMUWA8a9nJP+NxUXrs9fWkWxbBkHmQ9BgItX3TZWgZsklSSBlSJZ
> GFwuQzv/1XoSFKhvno+43c/lR4vvPzEqfXZg/7/RjOH7IUgoetzMaG9KzMfCo3to
> ACg3iu6S2EByKNr2eJPvcJrStXbu1f/z+ecBQ77is6Uz6+EBOsMC349EOTCQGIE6
> uZfENt/gN2nfU5hvloSkLNGVsj81PKpbIAtYVHDD3WLeF7AOiyGEXcaejM43rZHt
> OCev9ZmXTlkGAFRe7Isgzr0CcHudgDiG6ZICKdh0QOtp4up7vJHt6KzUNa6FkkQy
> MCJrVdLejXhrlJ7/5Att
> =yLYH
> -----END PGP SIGNATURE-----
>

Received on Monday, 22 September 2014 16:35:00 UTC