John,
I accidently resent a message sent last week - I would apologise for this,
except
that resending it has generated some discussion! I don't think that you can
interpret the lack of discussion as a consensus against my proposals any more
than I could interpet it as a consensus in favour!
1) Your module mentions the hashing of CER-encoded data. I don't believe
that the WG has approved of that option, so I recommend deleting any mention
of CER.
I recommend that the option is discussed before it is decided whether to delete
it!
Note that CER encoding can always be used (though not necessarily efficiently)
even
if DER alone is specified, as a digestAlgorithm can be defined to decode the
DER and
re-encode in CER before applying the hash function. It is more efficient to
have the
digestAlgorithmIdentifier specify which of CER or DER is to be applied, however.
2) Your module mandates that a SignatureValue must be an ENCRYPTED SEQUENCE
of digestAlgorithm and digest. CMS, Section 5.4 does not mandate the
inclusion of the digestAlgorithm in the message signature generation
process. In fact, only the digest itself is input to the DSS algorithm. I
recommend replacing your current SignatureValue, DigestInfo and Digest
definitions with the definition of SignatureValue as an OCTET STRING. The
SignerInfo signatureAlgorithm will indicate exactly what data is to be
encrypted to form the SignatureValue. There should be appendices to CMS for
DSS, RSA, Elliptical curve (future), etc.
This depends on the extent to which CMS is to be compatable with PKCS#7, which
does mandate that the digestAlgorithm is included within the signature value.
While it would be possible to have the signatureAlgorithm define the structure
of the data that is signed, what is the benefit? Is there any reason not to
retain compatability with PKCS#7 here?
3) Your module includes "originatorCertificateSelector CertificateAssertion
OPTIONAL" in RecipientInfo. I don't believe that the WG has formed a
consensus that originatorCertificateSelector must be a part of
RecipientInfo. I believe that omitting the originator cert and including
originatorCertificateSelector in RecipientInfo adds significant complexity
to an already complex protocol.
I have not proposed omitting the originator certificate. I propose use of the
CertificateAssertion syntax since this is exactly the syntax used to select
certificates from a directory,
4) I don't believe that the WG has approved of your definition of
RecipientKeyIdentifier (including Name and CertificateAssertion) which is
significantly more complicated than the current CMS defnition.
Again, I would welcome some discussion of this.
Jim