Hello.
I noticed one unfortunate inconvenience about ECC public key definition.
Currently RFC 6637 defines two types of keys:
ID 18: ECDH
ID 19: ECDSA
but no "joint" or "unlimited" ID. As shown bellow, this is needed for
easier interchangeability with PKI standards.
I was probably hypnotized by the already reserved ID 18 for ECDSA in RFC
4880 to not think in general terms, which is:
Given that EC keys can do both signing+encryption, just as RSA keys,
why there isn't a single public key ID (i.e. the analog to ID 1 for RSA).
We have key usage flags to narrow down the usage.
The issue is that it's justifiable in many cases to have a single
top-key only OpenPGP key and such a key should be capable of both
signing+encryption.
In particular, this issue comes up when one tries to map an X.509 ECC
certificate, as defined in RFC 5480, to RFC 6637.
As I understand it based on my observations of the current use of ECC
X.509 certificates, the most common usage will be sec 2.1.1 of RFC 5480,
which defines an "unrestricted" id-ecPublicKey algorithm identifier. The
problem is that there is no way to map it cleanly into an RFC 6637 ID.
RFC 5480 also has restricted id-ecDH (but not sign-only ID).
Interestingly, there is no sign-only ID in RFC 5480, thus, even CA
certificates that are restricted to signing will get id-ecPublicKey
algorithm ID.
In RFC 6637, ID 18 (ECDH) is a superset of fields of ID 19 (ECDSA)
What are the possible fixes here?
1. Add ID 20 that is ECDH+ECDSA. It will be defined identically to ID 18
(ECDH), but will also be allowed to perform the signature/verification
functionality of ID 19 (ECDSA).
2. Overload ID 18 to allow ECDSA. One problem here is that it we loose
the ability to map id-ecDH into ID 18.
3. Overload of ID 19 will not work, because it lacks KEK parameters that
are needed for encryption. Plus, sign-only application are useful for
regulatory compliance (because it's not encryption).
I assume that it will be common (or at least possible) to issue end-user
X.509 certificates for SMIME that are signing+encryption. Thus, even
though current PKI CA certificates can be mapped to ID 19 based on
keyUsage flags, we cannot do this in all cases.
I see #1 as the only perfect solution for the problem. Does anybody have
any other thought about how to proceed?
Thank you.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp