Re: Suggested agenda topics

On Thu, Mar 3, 2016 at 3:00 PM, Jason Proctor <jason@mono.hm> wrote:

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

That is because Safari doesn't support the "spki" (or "pkcs8") key format.

Chrome and Firefox do however.


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