ietf-smime
[Top] [All Lists]

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

1997-11-17 16:59:30
All,

In the enclosed message, I stated:

"[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 need to change this to:

[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.]

- John Pawling
 

To: "Jim Craigie" TEL +44-1635-202124 
<Jim(_dot_)Craigie(_at_)net-tel(_dot_)co(_dot_)uk>
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Cc: ietf-smime(_at_)imc(_dot_)org

Jim,

Thank you for your responses.  My responses are in-line:

[JSP] is: 
================================
John Pawling   
jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.           
================================

At 07:04 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
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!

[JSP: Agreed.]


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!

[JSP: Agree that this option needs to be further discussed.]


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.]




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 which states:

"5.3.  Signatures

5.3.1. Single Signatures

Signatures are defined by the use of the SIGNED parameterized type, which
expands to a SEQUENCE of the data being signed, an algorithm identifier, and
a bit string which is the actual signature.  The SIGNED type, in turn, uses
the ENCRYPTED and HASHED types.  A public key encryption (or signature)
algorithm is applied to the hash of the data to be signed.

HASHED {ToBeHashed} ::= OCTET STRING (CONSTRAINED BY {
   -- must be the result of applying a hashing procedure to 
   -- the DER-encoded octets of a value of
   ToBeHashed })

ENCRYPTED {ToBeEnciphered} ::= BIT STRING (CONSTRAINED BY {
   -- must be the result of applying an encipherment
   -- procedure to the DER-encoded octets of a value of
   ToBeEnciphered })

SIGNED {ToBeSigned}::=SEQUENCE {
   data          ToBeSigned, 
   COMPONENTS OF  SIGNATURE {ToBeSigned} }

SIGNATURE {OfSignature} ::= SEQUENCE {
   algorithm        AlgorithmIdentifier,
   encryptedDigest   ENCRYPTED { HASHED {OfSignature} } }
   -- For the DSA, the contents octets of the signature BIT STRING shall be 
   -- interpreted as being the DER encoding of the type: 
   --  SEQUENCE {
   -- r       INTEGER,
   -- s       INTEGER }

The data to be signed is encoded using the ASN.1 distinguished encoding
rules (DER) as described in ANSI TG-9-199x, Abstract Syntax Notation and
Encoding Rules for Financial Industry Standards and X.509.  The complete
encoding is hashed using the hash algorithm implied by the signature
algorithm ID.  The complete encoding is hashed using the hash algorithm
implied by the signature algorithm ID.  The DSA is then used to sign the
hash, resulting in the signature.

Notes:

1) According to the definition above, the DSA is applied to the DER
encoding of the hash, which has a length of 22 bytes (tag, length, and
contents).  Since the input to the DSA signature process is only 160 bits,
the tag and length bytes of the DER encoding are not included in the
computation of the signature; only the actual contents of the encoding (the
hash) is signed.

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. 

For the DSA, the contents octets of the signature BIT STRING shall be
interpreted as being the DER encoding of the type:

SEQUENCE {
r      INTEGER,
s      INTEGER }

That is, the encoding of the sequence is wrapped inside a BIT STRING."


Is there any reason not to
retain compatability with PKCS#7 here?

[JSP: Yes for the aforementioned reason.]



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,

[JSP: Agree with your proposal except that I would like to see text in the
CMS spec prohibiting the use of the CertificateAssertion "pathToName" choice.]



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)??]



Jim