- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 22 Sep 2014 17:16:22 +0200
- To: public-webcrypto@w3.org
-----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.
Mark Watson, do you have time to go through the spec and update it by
Friday this week?
> 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 15:16:34 UTC