Re: A draft ASN.1 module for Cryptographic Message Syntax

John,
> > 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.]
Most of the constraints are common between CER and DER, so it actually
requires a very small amount of effort to add CER if you already support DER.

> > 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.]
I disagree. Embedding an ASN.1 encoding within the value of an OCTET STRING or 
a BIT STRING requires two passes of ASN.1 parsing, unless you write special 
case code. It is much better to define the syntax properly to enable it to be 
parsed in one pass. An Information Object Set replaces the now deprecated use 
of ANY, to give a syntax like:

SignerInfo ::= SEQUENCE {
        version Version,
        issuerAndSerialNumber IssuerAndSerialNumber,
        digestAlgorithm DigestAlgorithmIdentifier,
        authenticatedAttributes [0] Attributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SIGNATURE-VALUE.&Type 
({SignatureValueTable}{(_at_)signatureAlgorithm(_dot_)algorithm}),
        unauthenticatedAttributes [1] Attributes OPTIONAL }

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

SIGNATURE-VALUE ::= CLASS {
        &id  ALGORITHM.&id,
        &Type }
        WITH SYNTAX {&Type IDENTIFIED BY &id }

SignatureValueTable SIGNATURE-VALUE ::= { rsa-signature-value, 
dss-signature-value, x509-signature-value, another-signature-value, ... }

rsa-signature-value SIGNATURE-VALUE ::= { RSASignatureValue IDENTIFIED BY 
id-rsa-signature }

RSASignatureValue ::= ENCRYPTED { DigestInfo }

DigestInfo ::= SEQUENCE {
        digestAlgorithm DigestAlgorithmIdentifier,
        digest Digest }

Digest ::= HASHED { CHOICE {
        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
        authenticated-attributes [0] EXPLICIT Attributes } }

dss-signature-value SIGNATURE-VALUE ::= { DSSSignatureValue IDENTIFIED BY 
id-dss-signature }

DSSSignatureValue ::= SEQUENCE {
        r INTEGER,
        s INTEGER }

x509-signature-value SIGNATURE-VALUE ::= { BIT STRING IDENTIFIED BY 
id-x509-signature }

another-signature-value SIGNATURE-VALUE ::= { OCTET STRING IDENTIFIED BY 
id-another-signature }

> > 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.]
I disagree, for reasons stated in previous messages.

Jim