for what it's worth, and largely for compatibility with existing keys around, i would vote for option 1, too. On Tue, Dec 8, 2015 at 10:10 AM, Mark Watson <watsonm@netflix.com> wrote: > Virginie, all, > > We are actively using SPKI import for RSA keys and include PKCS#8 in the > test suite that browsers must support to enable our application. As a > result, my preference is for Option 1. I wonder, though, if the support > required for PKCS#8 and SPKI in the specification could be scoped down such > that achieving (1) becomes a simpler task for browsers ? > > ...Mark > > On Tue, Dec 8, 2015 at 4:10 AM, GALINDO Virginie < > Virginie.Galindo@gemalto.com> wrote: > >> Dear implementers, and all, >> >> >> >> There is one last important incompatibility bug in the Web Crypto API to >> solve, for which Ryan Sleevi has suggested some directions. If you were to >> indicate your preference among the options raised by Ryan, that would >> unlock the situation, insuring implementers consensus [1]. We have not been >> heard anything from you, provided my recent emails and that the team >> contacted you directly. >> >> >> >> As chair, my perception of the situation is that this does not seem to be >> a problem or a priority for you to solve that bug. Nevertheless, the Web >> Crypto API has been delaying its move to PR too long. >> >> >> >> In order to help progressing, I am calling for a decision to be made by >> next week. Ryan suggested 3 options for progressing on the key format >> aspects, and in case we don’t hear any answer from you by next Monday @ >> 20:00 UTC, I suggest that we adopt the option 2 which is : >> >> “Option 2) Remove support for SPKI and PKCS#8 entirely as KeyFormats. >> Forcing everything as JWK.” >> >> >> >> Regards, >> >> Virginie >> >> Chair of the Web Crypto WG >> >> >> >> >> >> [1] >> https://lists.w3.org/Archives/Public/public-webcrypto/2015Dec/0001.html >> >> >> >> // please ignore the following statement >> ------------------------------ >> 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 Tuesday, 8 December 2015 18:14:12 UTC