Re: Suggested agenda topics

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?
>
>
To be clear this isn't just for AES-GCM, but also AES-CBC, and AES-CTR.
Chromium doesn't support 192-bit keys for any of them (and doesn't plan to
- http://crbug.com/533699)

I know for AES-CBC at least there are more than 1 implementation that
support 192-bit keys (Firefox and WebKit).

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

That sounds good to me.

Chromium certainly doesn't support importing JWK RSA private keys with just
n,e,d.

We investigated doing so for the implementation (https://crbug.com/374927)
and decided against supporting it using OpenSSL, as there didn't seem to be
a good reason for it.

As for other crypto libraries, NSS supports deriving the other parameters
but requires minimally at least p or q to do so. (Which doesn't really help
here based on JWA's requirements).


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

Agreed this is a problem.

(Right now there are incompatibilities between Chromium and Firefox, for
example (for instance Chromium can't import ECDH keys that Firefox exports
using PKCS8); Chromium in this case is not spec compliant, as it doesn't
accept OID id-ecDH which Firefox generates)

Perhaps this discussion belongs on the thread titled "ASN.1
Encoding/Decoding Compatability".

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