Suggested agenda topics

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

Received on Thursday, 3 March 2016 22:13:14 UTC