John,
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.
[JSP: Please note that many ASN.1 Tool kits do not support CER, so addition
of CER as a requirement will significantly increase the cost of complying
with the CMS spec.]
As CER is a subset of BER I cannot see how the cost of adding support for CER
can be so significant. However, I didn't think that I was requiring support
for CER. Any such requirement would be contained in a requirement for
mandatory support of a signature algorithm defined to use CER. I am simply
stating an existing fact in a way that allows efficient implementation for
signature algorithms which use CER. That is not a requirement, but a help
for implementors who encounter signature algorithms defined to apply the
signature to the CER encoding.
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?
[JSP: The benefit is for the CMS to allow the DSS (aka DSA) signature
applied to a CMS SignedData object to be compliant with the 21 June 1996
ANSI X9.57, "Public Key Cryptography For The Financial Services Industry:
Certificate Management" specification
Are you proposing the syntax defined in PKCS#7 for RSA algorithms? If the
PKCS#7 syntax is to be used in some cases then it is essential to retain its
ASN.1 definition, but this could be in an Information Object Set which varies
according to the algorithm identifier. What syntax is required for elliptic
curves?
If I understand the description of the DSS algorithm its output is two
integers, which are encoded into an ASN.1 sequence. If this is used in the
X.509 SIGNATURE parameterised type then the DER encoding of this sequence is
placed within the BIT STRING which is the ENCRYPTED parameterised type. Above
you say that the SignatureValue should be an OCTET STRING. Were you proposing
that this contained the encoding of the BIT STRING or the SEQUENCE? Why not
just make the SignatureValue be the sequence of the two integers in the DSS
case?
Notes:
2) The SIGNED type does not include the signature algorithm identifier in
the signature computation. In order to deter attacks based upon modifying
the hash or signature algorithm identifiers conveyed in the message,
applications using the SIGNED type should include the algorithm identifier
in the actual data being signed.
That should be formalised in the ASN.1
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.
[JSP: How about if we defined RecipientKeyIdentifier as a
CertificateAssertion (rather than a sequence of subjectName and
CertificateAssertion) (except that I would like to see text in the CMS spec
prohibiting the use of the CertificateAssertion "pathToName" choice)??]
I agree that the subjectName is not always necessary (e.g. if the
CertificateAssertion contains issuer and serialNumber) but I disagree
that it is never necessary here. For example, if the CertificateAssertion
contains just subjectKeyIdentifier then a subjectName may be essential
for economic processing by each recipient if a CA's allocation of values
for subjectKeyIdentifier give the same value to many users (e.g. if the
value is a sequence number for each user, or the date of issue).
I agree with prohibiting pathToName. So my revised proposal is:
RecipientKeyIdentifier ::= SEQUENCE {
certificateSubjectName [0] Name OPTIONAL,
recipientCertificateSelector CertificateAssertion(WITH COMPONENTS{...,
pathToName ABSENT}) }
Jim