RE: Suggested agenda topics

 

 

From: Eric Roman [mailto:ericroman@google.com] 
Sent: Thursday, March 03, 2016 3:43 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: public-webcrypto@w3.org
Subject: Re: Suggested agenda topics

 

 

 

On Thu, Mar 3, 2016 at 2:12 PM, Jim Schaad <ietf@augustcellars.com <mailto: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)

 

Just to be clear – I was only talking about the one item that I had tested and I am not surprised that this is true across all of the AES algorithms supported by Chromium.  For the moment I was more interested in the procedure question than in should it be supported everywhere.   

 

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

 

Once I get a review of the RSA SSA test case code and it gets merged, I plan on dealing with the rest of the asymmetric key algorithms to do coverage testing on them as well.  It is good to know that there are going to be some errors as things go forward.  We need to get them cleared up in the spec or well documented somewhere.

 

Jim

 

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