Re: Suggested agenda topics

fwiw, i'm encountering some incompatibilities shipping public keys around.
i have a long-existing app which stores public keys in X509 containers
(specifically, using the Bouncy Castle JCE provider's X509EncodedKeySpec).

Chrome and Firefox will happily import such a public key using the SPKI
format, but Safari won't. i'm not sure offhand whether this is Chrome and
Firefox being liberal or an issue with Safari, but ideally, this would be
uniform across browsers.

also fwiw, Bouncy Castle will happily import public keys exported using
Chrome and Firefox's SPKI export format.




On Thu, Mar 3, 2016 at 2:12 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> Based on the first set of tests that I have written, I would suggest that
> the following topics be considered for the agenda on the next meeting:
>
> 1.  If there is not support for a key size, does that key size need to be
> removed.
>
> Looking at doing generation of keys for AES-GCM, Firefox supports 128, 192
> and 256 bit keys.  However Chrome only supports 128 and 256 bit keys.  From
> a policy perspective, if we do not find another implementation that is
> supporting 192-bit keys does this need to be removed from the document
> before progressing?
>
> 2. Should the spec be updated to require all of the secondary fields for
> importing an RSA key?
>
> JWA states that d MUST be present and that the other fields SHOULD be
> present.  The spec currently just refers to JWA for requirements of
> presence
> for these fields.  I remember, but did not find, mail that asked if anybody
> did a "d" only import and there was nobody.  Thus the question.
>
> 3.  Should the spec be updated so that the signature algorithm variants of
> RSA are not used as OIDs when importing a key.  (Opposite would be to
> update
> the export so that it does use these OIDs).
>
> There is currently a bug in the data base on this issue is at
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27255. I have gone back and
> done some research on this issue looking at the various PKCS and IETF
> documents that discuss importing and exporting of private keys as oppose to
> public keys (i.e. "pkcs8" vs "spki").  The PKCS series has never written a
> tight ASN.1 module specifying what the OIDs are that should be associated
> with the different private key structures.  Thus most implementations has
> stuck to using the single OID of rsaEncryption.  This is basically a
> historical artifact since there has never been a strong movement to key the
> different key algorithms separate.  The closest that the IETF came to this
> is an ASN.1 module that I wrote that still did not do the complete job as
> the IETF has historically had a reluctance to enable the ability for
> archiving of private keys.  This means that it has never completed the
> issue
> and the separation of all of the public and private key structures made it
> too difficult to finish filling out the ASN.1 objects in the update to 2008
> ASN.1 that I did with Paul Hoffman.
>
> One possible way to move forward with solving the issue would be to use the
> attributes section of the private key structure and define a W3C specific
> attribute to hold the OID of the signature algorithm.  This would work for
> all of the different structures and not cause any problems in general.  It
> could then be enforced by WebCrypto code.
>
> Another possible way forward is to decide that it is too much work to keep
> the binding of algorithm to key for the pkcs8 export formats.
>
> It is not clear to me that this is what should be adopted for the public
> key
> formats.  Libraries should be setup to be able to import these with the
> correct algorithm identifier so I believe that should be considered to be a
> bug in the implementation and not in the specification.   This is what is
> commonly done today in certificates.
>
> Jim
>
>
>
>