Subject: [AAA-WG]: CMS Security Application procedures (I)

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 16 Aug 2001 12:03:53 +0200

Hi again,

I've trying to get a comprehensive view of CMS Security Application. I
began with the CMS Security draft and with the CMS RFC (along with the
RSA's specification of PKCS#7 and the Layman's Guide of ASN.1 as a
starting point). I forgot to mention than I had no previous experience
with MIME or S/MIME. The task has proved to be hard because there are
a number of RFCs or drafts that must be read, there are a lot of
backwards references and CMS Security uses just a subset of S/MIME
which in turn uses only a subset of CMS.

So that, finally, I've missed certain points (that should be clear for
experts in S/MIME, but are not for me). I've been dealing with the
process of getting CMS-Signed-Data and CMS-Encrypted-Data. What
follows below is what I understantd is the process of getting a
CMS-Signed-Data AVP, along with my doubts and concerns. Could someone
light me? Many thanks in advance.

==========================================================

In order to get a CMS-Signed-Info AVP, the following steps 
are necessary:

a) the Diameter node collects all the AVPs with need to be
protected (AVPs with the 'P' bit) in a Diameter message.

b) those APVs are concatenated in the order in which they 
occur in the Diameter message, including padding [CMSSec, 
6.1]

First concern: According to [CMSSec, 6.1, second paragraph],
the result of step b) is the entry to the signing process. 
But when [SMIME, 3.1 ("Preparing the MIME Entity for 
Signing and Enveloping")] describes the procedure to create
MIME entities that are to be "signed, enveloped, or both 
signed and enveloped", it points that the procedure 
comprises the following steps:

  1. The MIME entity is prepared according to the local 
  convencions (which might be the process described in b)
  i.e. concatenating)
  2. The leaf parts of the MIME entity are converted to 
  canonical form
  3. Appropriate transfer encoding is applied.
    
Is that three-step procedure necessary to generate the 
message which will signed (or enveloped) to produce a 
CMS-Signed-Data AVP? Or is it intended that just the 
concatenation is enough? Or maybe I'm missing anything 
(because of my slight knowledge of MIME). Could anyone 
add any clarification to this process?

BTW, according to [MIME5, 4 ("Canonical Encoding Model")],
there is a fourth step: "Insertion into entity", which 
implies the setting of appropiate MIME headers. I assume 
that this step isn't necessary anyway (if not, which 
Content-type to use? application/octect-stream?)

c) creation of the CMS-Signed-Data AVP. According to [CMS], 
SignedData type comprises the following components:

  1. version
  2. digestAlgorithms (as [CMSSec] just considers SHA-1 as 
  hash algorithm, that will be the content of this field)
  3. encapContentInfo (type EncapsulatedContentInfo). This 
  type comprises the content type of the content being signed
  (eContentType) and the content itself (eContent, which is 
  optional). According to [SMIME] eContentType must be 
  id-data while according to [CMSSec], eContent is absent.
  4. certificates. This field might convey digital 
  certificates but, as far as I understand, [CMSSec] intends
  that digital signatures and certificates will be carried in
  different AVPs CMS-Signed-Data and CMS-Certs, respectively),
  so that this optional field will be absent in 
  CMS-Signed-Data AVPs. Am I right?
  5. crls. The same comments than in the previous item are 
  applied.
  6. signerInfos (type SignerInfos), a collection of 
  per-signer information (values of type SingerInfo), each
  containing:
    - version
    - sid (type SingerIdentifier, the identifier of the signer)
    - digestAlgorithm (SHA-1)
    - signatureAlgorithm (RSA)
    - the signature itself (signature, type SignatureValue)
    - and, optionally, a set of signed and unsigned 
    attributes (type Attribute). No mention about these 
    fields is done in [CMSSec], but [SMIME, 2.5] states that 
    "sending agents" should generate a set of signed 
    attributes (like signingTime or sMIMECabilities). I suppose
    that these signed attributes aren't necessary here, but ...

d) the CMS object is encoded by means of the BER (Basic 
Encoding Rules)

e) here we have an only CMS-Signed-Data to be included in the 
Diameter message

There are, still, some additional doubts:

- [CMSSec] says in 6.1:

     Instead, the digest value within the SignedData 
     structure contains the digest produced in the 
     signature process.
   
   Which digest value is it talking about? There isn't any 
   direct digest field in a SignedData value. Just two fields 
   can convey "data": SignedData EncapsulatedContentInfo 
   eContent (which carries the data being signed and is 
   absent according to [CMSSec]) and SignedData SignerInfos
   signature (which is the signed digest).
   
   The only possibility is that we're talking about a value 
   of message-digest attribute type (as defined in [CMS, 
   11.2]). An attribute of this type may be inserted into 
   any of the SignerInfo values that comprises Signed Data
   SignerInfos (take into account that this value would be
   the same for all the SingerInfo value, so that only one
   digest algorithm must be supported in [CMSSec]). However,
   this attribute is only required (in [CMS, 11.2]) if any
   other attribute is present (if present, message-digest 
   is a SignedAttribute). Is it mandatory to add this 
   attribute in CMS-Signed-Data (maybe in order to allow
   further countersignature operations)? If so, [CMSSec]
   should include the following paragraph in 6.2:

     The CMS SignedData value encapsulated as a 
     CMS-Signed-Data MUST include a message-digest attribute
     in the SingerInfo value as specified in [CMS] since its
     presence is necessary to compute further
     countersignature attributes (whose utility is depicted
     below). This attribute MUST be always signed.
   
- When dealing with multiple entities wishing to add 
   signatures, the countersignature attribute is introduced.
   This attribute belongs to the UnsignedAttributes in a 
   SignerInfo value. May I assume that there will be only one 
   singerInfo in a SignedData value (including a 
   message-digest attribute) and that multiple signatures
   will be handled only like countersignature attributes
   (which allows not to resign the whole set of AVPs)? Or
   is it possible to have more than one signerInfo
   structure within a CMS-Signed-Data AVP?

References:
[CMSSec] "Diameter CMS Security Application"
[CMS] "Cryptographic Message Syntax", RFC 2630
[SMIME]: "S/MIME v3 Message Specification", RFC2633.
[MIME5]: "Multipurpose Internet Mail Extensions (MIME) Part 
Five: Conformance Criteria and Examples", RFC 2045

==========================================================

Regards

  // M.A.