Jim,
As CER is a subset of BER I cannot see how the cost of adding support for CER
can be so significant.
[JSP: It is significant to a small company. For example, we are adding DER
capabilities to a BER-capable ToolKit. It takes a significant amount of
time to add the many blocks of code required to enforce the additional
constraints imposed by DER and then to test these new capabilities. I am
assuming that adding yet another type of encoding (i.e. CER) would require a
similar amount of effort to develop and test the capabilities.]
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.
[JSP: The current CMS spec states that all data to be hashed must be DER
encoded. This implies that a CMS implementation only needs to support DER
and BER. Your draft CMS ASN.1 module included: "-- In Cryptographic
Message Syntax the HASHED parameterised type applies the hash function to
the contents octets component of a CER or DER encoding of a value of the
parameter." This implies that a CMS implementation must support DER and BER
and should support CER to accommodate signature algorithms that require it.
This adds expense and somplexity.]
Are you proposing the syntax defined in PKCS#7 for RSA algorithms?
[JSP: No. I am proposing that SignatureValue should simply be defined as an
OCTET STRING and that the SignerInfo signatureAlgorithm will indicate
exactly what data is to be encrypted (signed) to form the SignatureValue.]
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.
[JSP: I agree. The PKCS #7-like syntax could be included in an Appendix to
the CMS describing how the RSA signature algorithm is used in conjunction
with the CMS spec.]
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.
[JSP: When DSS is used to sign a cert, then the signatureValue BIT STRING
includes the ASN.1 encoded SEQUENCE of the R and S INTEGERs.]
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?
[JSP: In DSS-signed SignerInfos, the SignatureValue OCTET STRING will
contain the ASN.1 encoded SEQUENCE of the R and S INTEGERs.]
Why not just make the SignatureValue be the sequence of the two integers in
the DSS case?
[JSP: Because then the CMS definition would need to define SignatureValue as
ANY to provide sufficient flexibility to support a variety of signature
algorithms. I believe that defining SignatureValue as an OCTET STRING is
the better choice.]
RecipientKeyIdentifier
[JSP: I don't believe that RecipientKeyIdentifier needs to be changed from
the existing CMS-01 syntax, because the RecipientIdentifier provides the
CHOICE of issuerAndSerialNumber and RecipientKeyIdentifier. I believe that
the current CMS-01 syntax provides sufficient flexibility to uniquely
identify any X.509 Certificate.]
Jim