Subject: Binding between keys and schemes?

From: Pedro Félix <[email-masked]>
Date: Thu, 20 Jan 2000 10:42:48 -0000

1) As defined by PKCS#1 v2.0 an RSA key can be used in two diferent
encryption schemes:
rsaEncryption (PKCS#1 v1.5 scheme) and the new OAEP based scheme
(id-RSAES-OAEP OID).
Is a PKIX certificate with rsaEncryption OID (on the subjectPublicKeyInfo)
binded only to the first scheme?

2) Probably in the future there will be various signature and encryption
schemes using the same type of key. As an example the P1363 draft 11 defines
two signature schemes IFSP-RSA1 and IFSP-RSA2 used with an Encoding method
(EMSA2) that can be updated in the future. They all use the same type of IF
(RSA) key.
How will an certificate manage this 1<->N relation between keys and schemes?
There will be a different certificate for each scheme or the same key
certificate will be used with different schemes?
If the second applies, how will the schemes capabilities of a certificate
subject be identified?

I gave a quick browse on the archives and didn't found any reference to this
subject?

I apologise if this question is off-topic or doesn't make sense in this
context!
I also thanks (in advance) any replies.

Pedro Felix
Centro de Calculo do Instituto Superior de Engenharia de Lisboa.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Jan 2000 16:10:50 -0500

Prdro,

First, a certificate doesn't purport to characterize the capabilities 
of the subject wrt the algorithms with which a public key may be 
used.  Rather, a certificate expresses the algorithm with which the 
key may be used.  This is a fine distinction, but we have avoided 
loading other user crypto capability info into certs in the past, 
e.g., what symmetric crypto algorithms a user's S/MIME implementation 
supports.

If a single key can be used with various algorithms, a certificate is 
capable of expressing only one, as currently specified, and thus one 
might need to have multiple certificates, if multiple algorithms are 
to be employed.  One might imagine defining an algorithm ID that 
captures a set of algorithms with which a key may be used, by the 
subject.  Syntactically, that has been done in the past, e.g., in DMS 
certificates specified that the SubjectPublicKey field contained two 
keys, one for KEA and one for DSA.  It's a hack.  The deliberations 
that led to X.509 v3 made clear that putting two keys into this field 
was discouraged. Still, this example suggests that one might define 
an Algorithm ID that conveys a more complex notion of what 
algorithm(s) can be used with a key.

Steve