On 07/18/2013 04:04 PM, Andrey Jivsov wrote:
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?
Your first proposed solution (#1) seems reasonable to me, and not
without precedent. It's similar to the asymmetric key IDs allocated for
RSA:
https://tools.ietf.org/html/rfc4880#section-9.1
1 - RSA (Encrypt or Sign) [HAC]
2 - RSA Encrypt-Only [HAC]
3 - RSA Sign-Only [HAC]
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp