ietf-smime
[Top] [All Lists]

SIGNED {} - Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax

1997-11-18 10:06:42
In "Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax"

John Pawling wrote:

All,

snip

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

snip


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.

The text "expands to a SEQUENCE of the data being signed, an algorithm 
identifier, and a bit string" means that after parameterized type text
substitution on the nested parameterized types that make up the X.509
SIGNED {} type, you get the equivalent ASN.1 definition:

   SIGNED { ToBeSigned } ::= SEQUENCE {
      toBeSigned  ToBeSigned,
      algorithm   AlgorithmIdentifier,
      signature   BIT STRING
   }

This definition is signature scheme neutral. The four parameterized
type definitions used in X.509 are not. They imply that a digital
signature scheme perform an encrypted hash to sign an object. The
HASHED {}, ENCRYPTED {}, SIGNATURE {}, and SIGNED {} that follow 
should be replaced with a simpler version of SIGNED {}.

The text "encryption (or signature) algorithm is applied" refers
to the problem for elliptic curve DSA and many other signature
schemes posed by the X.509 definitions. RSA uses an encryption
based signature scheme, and is called for in X.509. But with
DSA, there's no need to encrypt the hash. The hash is merely
"signed". A simplified SIGNED {} type that says nothing about
which signature scheme is applied should be used. S/MIME should
not require RSA signatures.


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. 

Hard to tell the following is true from looking at ENCRYPTED {}.

The DSA is then used to sign the hash, resulting in the signature.

snip

Phil
-- 
Phillip H. Griffin         Griffin Consulting
asn1(_at_)mindspring(_dot_)com        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------