Now, for my question: In the draft, I didn't see anything that struct
me as being the equivalent of MIC-ONLY. I would assume that you would
do a MIC-ONLY by using this construct. Am I correct?
Content-Type: multipart/signed; protocol="application/pem-signature";
micalg="rsa-md5"; boundary="Signed Message"
--Signed Message
Content-Transfer-Encoding: radix-64
Content-Type: text/plain
SIGNED-MESSAGE
--Signed Message
Content-Type: application/pem-signature
SIGNATURE INFORMATION
--Signed Message--
I don't want to comment now on the redundancy of the micalg part..
For MIC-ONLY capability you are free to define a transfer encoding as
you have shown. Watch out for this, though: In RFC 1421, the
signature is computed on the same text, whether it is recoded for
MIC-ONLY or left in the clear for MIC-CLEAR. When an RFC 1421
application receives a MIC-ONLY message, it decodes it first, then
computes the signature check on the decoded text. However, in
MIME/PEM if you recode the text when preparing a message, the
signature is computed on the recoded value. Therefore, when a
MIME/PEM application receives such a message, it computes the
signature check on the recoded value first, then decodes. This is
stated in the section 3.1 of the draft:
As may be required by MIME, an appropriate Content-Transfer-Encoding:
header is added and included with the data to be signed. Upon receipt,
a MIME implementation would verify the signature of the data prior to
decoding the data and displaying it to the recipient.
I don't want to comment now on the redundancy of the micalg part..
To anticipate your question: Why does the micalg appear in the header
as well as in the application/pem-signature at the end? (If this is
your question...) This is done to allow single pass processing. A
receiving application needs to know the digest algorithm up front so
that it can digest while it processes the text. It appears again in
the MIC-Info of the application/pem-signature since it was originally
there in the first place (;-) ), but also in case there are parallel
signatures: If one user signs with RSA and MD5 and another signs with
RSA and MD2, then there will be two different signature blocks at the
end. In this case, both MD2 and MD5 micalg paramters would need to be
up front in the header.
- Jeff