ASN.1 encoding. What is wrong and some possible ways forward.

I will start with a bit of history in part because I remember it having
participated in pieces of it.

For this document we can divide the OIDs dealing with asymmetric keys into
three different piles.  Those for public keys, those for private keys and
those for algorithms.  (The reason that I separate public and private keys
will be covered later.)

In the beginning, there was rsaEncryption.  This OID was used for the public
key, the private key and both signature and encryption algorithms.  As time
went by, there was a drive to define signature algorithms as being a
combination of a hash algorithm with an asymmetric algorithm.  This lead to
the creating of OIDs like md5WithRSAEncryption.  It was part of the PKCS#7
transition from RSA to the IETF as CMS that it was decided that
rsaEncryption would no longer be a legal signature algorithm.  However, it
has never really gone away since it is part of all the old PKCS#7 packages
including OpenSSL the last time I checked.

The next "advancement" was the decision that we should really be using
signature algorithms rather than public key algorithms as part of the SPKI
structure (see for example RFC 4055 of which I was a co-author).  There was
no push to make the same changes when dealing with private keys because at
that point in time the IETF was neurotic about the concept of doing either
server side generation of private keys or archiving private key's even in a
corporate environment.

This step was not widely adopted, for better or worse, and RFC 5756 then
came along and rescinded part of the statements that were made in RFC 4055.
Specifically, it was still true that one should include the PSS and OAEP
OIDs in an SPKI structure, but now the parameters were declared to be
verboten and should only appear where the algorithm version of the OID is to
be present.  Thus the public key and algorithm structures were made distinct
at this point.

The long and short of this is that although the group really expressed a
preference to tying the signature algorithm to the key when it is imported
and exported, this is only going to work today with the JWK format.  It will
not work correctly with either spki or pkcs#8 asn.1 encoding today.

Options going forward:

1.  Completely give up on the idea of supporting algorithms specificity for
the import/export routines with ASN.1.  This is really the only option that
is going to be viable in terms of getting the work done even close to the
schedule laid out.

2.  Make a (small) step toward getting the algorithms part of the keys by
doing what the current PSS and OAEP IETF standards say to do for public
keys, but probably not for private keys.

3.  Go for broke and keep things as they are now.

4.  Kill the idea of doing any ASN.1 import and export code at all.


Outline of what changes need to be made:

RSA -
    option 1 remove all references to *WithRSAEncryption in the import and
export routines
    option 2 ditto

RSA-PSS
    option 1 - remove all references to id-RSASA-PSS and change export to
use rsaEncryption
    option 2 - change the import of id-RSASSA-PSS to use absent for the
parameters
               change the export of id-RSASSA-PSS to use absent for the
parameters

RSA-OAEP
    option 1 - remove all references to id-RSAES-OAEP and change export to
use rsaEncryption
    option 2 - change the import of id-RSAES-OAEP to use absent for the
parameters
               change the export of id-RSAES-OAEP to use absent for the
parameters

ECDSA
   Need to test - but I don't see any changes right off the bat.

ECDH
   option 1 - remove all references to id-ecDH and change export to use
id-ecPublicKey
   option 2 - leave things as they are

DH and DSA have been killed from the spec (or never appears) so no changes
are needed there.

Received on Saturday, 26 March 2016 06:53:19 UTC