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

On Mon, Sep 22, 2014 at 9:34 AM, Mark Watson <watsonm@netflix.com> wrote:

> 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.
>

​Done. See changesets referenced in bug 25618​.

...Mark



>
> >
> >> 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-----
> >
>