- From: <bugzilla@jessica.w3.org>
- Date: Tue, 05 Aug 2014 19:38:06 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26411 --- Comment #6 from Richard Barnes <rlb@ipv.sx> --- (In reply to Ryan Sleevi from comment #5) > Note that I don't have any real or imagined use case for this. It was just > worth documenting as a limitation. I don't hear anyone screaming for > support, either. Sure. I would be OK letting this drop. > (In reply to Richard Barnes from comment #4) > > Another way you could go about this is to add a way to get the public key > > that corresponds to a given private key. This is clearly possible for EC > > and DH keys, and should pretty much always be possible for RSA keys. That > > way the API could default to private key import if the private parameters > > are present, then you could translate over to the public if you need it. As > > a bonus, this seems like something that could be useful more generally. > > I intentionally avoided this during early drafts, because in many > cryptographic libraries and implementation, this isn't > possible/easy/reliable. This is, admittedly, primarily a concern induced by > how hardware tokens behave, but one that has been reflected into the system > APIs. It seems like this isn't necessarily a system API issue. An implementation of CryptoKey could simply do two imports (public and private) and store both, even if the platform doesn't support private->public conversion. I admit that it does impose some overhead. As above, I'm OK letting this drop, but the private->public conversion does seem kind of handy. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 5 August 2014 19:38:08 UTC