Karen Rosenthal <karenr(_at_)premenos(_dot_)com> writes:
Cutting to the chase ... S/MIME and MSP merge, and a completely revamped
PKCS#7. Great. How long are we talking about to get these completed,
and through the IETF process (or does the IETF process get dropped?).
We've got S/MIME product in the market place right now. And our
customers want standards compliant, interoperable products (the word
"standards" used loosely - truly for "most" clients, standards compliant
really does mean interoperable!!!), that, with all the current press,
provide for DSS and DH, as well as RSA. In asking the question, can
S/MIME and PKCS#7 v1.5 support DSS and/or DH, I've gotten no details,
but answers ranging the gambit from:
a. can't be done
b. can be done as a hack
c. can be done, in a standards* compliant manner
d. we've done it
(Could someone please technically prove any of the above?)
DSS is no substantial problem. The text and the ASN.1
both refer to encrypting the message digest, which isn't how
DSS works, but it's still perfectly straightforward to
put the DSS signature in the EncryptedDigest field
in the SignerInfo. [1]
SignerInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes
[1] IMPLICIT Attributes OPTIONAL }
EncryptedDigest ::= OCTET STRING
KEA/DH, however, can't really be done in a cool way.
In general, both KEA and DH require that the recipient
have the sender's public key (Y) available to them.
Y needs to be represented some way. Typically, in
the FORTEZZA world, Y comes out of the sender's certificate.
Technically, this isn't necessary, and in the DH world,
one can typically choose between having a raw Y
(in which case the sender is anonymous as with RSA) and
having a sender certificate which carries the Y. [2]
The problem is that the RecipientInfo structure in
PKCS7:
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
doesn't have any room for ANY of this stuff,
Ys, certificates, anything. Now, you could imagine putting
this stuff in a number of places:
1. In the parameters to the AlgorithmIdentifier
2. In the EncryptedKey itself. E.g.
FortezzaWrappedKey::={
senderIssuerAndSerialNumber IssuerAndSerialNumber,
certificates [0] IMPLICIT Certificates OPTIONAL,
rSender OCTET STRING,
wrappedDEK OCTET STRING -- 12 octets
So, you see, it can be done without changing the
EnvelopedData ASN.1, but it's pretty ugly. I'd call
this a hack.
The correct way to do this is to change the ASN.1 just
a little bit. If you do it correctly, you can arrange
that the Bits on the Wire are identical if RSA is used,
but that things are different if KEA/DH is used. It's
fairly easy to write this using ASN.1 OPTIONALs.
-Ekr
[1] Note that one needs to decide precisely what OID one
is going to use and how to encode R and S (e.g. concatenate
them, represent them as a SEQUENCE OF INTEGER, etc.) but these
decisions have already been made for PKIX, so no problem.
[2] Incidentally, both KEA and DH (at least in the X9.42 variant)
are usually used with two random numbers Ra (generated by the
sender) and Rb (generated by the recipient). For store and
forward applications, Rb is usually fixed. This needs to
get carried as well.
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."