Skip navigation.
Home
Home » NATO MMHS Working Group

CMS Profiles

The Cryptographic Message Syntax (CMS) is used for security services in a number of different military messaging standards. The security services are usually

  • origin authentication;
  • message integrity;
  • non-repudiation of origin; and
  • security labelling

which can be provided using the SignedData content type. (Encryption services are usually provided at the transport or network layer.)
Annex B of STANAG 4406 Edition 1 was the first to formally to use CMS SignedData to define the Protecting Content Type (PCT).

However, subsequent standards (and systems) have defined alternative profiles which raises the question of interoperability. These systems include:

  • NATO Messaging System
  • STANAG 4406 Edition 2/STANAG 4631
  • ACP145

The following table shows of a summary of the different profiles of CMS used by the standards.

[NMS Profile not yet complete]

Base PCT NMS STANAG
4631		 ACP
145
Ref. Element O R O R O R O R O R Comments
1 ContentInfo
1.1   ContentType m m m m m m m m m m Set to id-signedData
1.2   Content m m m m m m m m m m
2 SignedData
2.1   version m m m m m m m m m m See Ref. Row 3
2.2   digestAlgorithms m m m m m m m m m m See Ref. Row 4
2.3   encapContentInfo m m m m m m m m m m See Ref. Row 5
2.4   certificates o o c12 c12 c12 c12 m m m m See Ref. Row 6
2.5   crls o o o o o o x x x x See Ref. Row 7
2.6   signerInfos m m m1 m m1 m m16 m16 m16 m16 See Ref. Row 8
3 CMSVersion
3.1   v1(1) c2 m i m i m i m i m
3.2   v3(3) c2 m mr m mr m mr m mr m
4 DigestAlgorithmIdentifier
4.1   SHA-1 m m m m m m m m m m
4.2   MD5 o o o o o o o o o o
4.3   other o o o o o o o o o o
5 EncapContentInfo
5.1   eContentType m m m3 m m3 m m3 m m3 m
5.2   eContent o m mr m mr m mr m mr m
6 CertificateSet
6.1   CertificateChoices m m m m m m m m m m
6.1.1     certificate m m m m m m m m m m
6.1.2     extendedCertificate i i i i i i i i i i
6.1.3     attrCert o o o o o o o o o o
7 CertificateRevocationLists
7.1   CertificateList m m m m m m m m m m
8 SignerInfos
8.1   SignerInfo m m m m m m m m m m
8.1.1     version m m m m m m m m m m See Ref. Row 9
8.1.2     sid m m m m m m m m m m See Ref. Row 10
8.1.3     digestAlgorithm m m m m m m m m m m See Ref. Row 4
8.1.4     signedAttrs o m mr m mr m mr m mr m See Ref. Row 11
8.1.5     signatureAlgorithm m m m m m m m m m m See Ref. Row 12
8.1.6     signature m m m m m m m m m m
8.1.7     unsignedAttrs o m o m o m o m o m See Ref. Row 13
9 CMSVersion
9.1   v1(1) c4 m m m m m m m m m
9.2   v3(3) c4,15 m c15 m c15 m c15 m c15 m
10 SignerIdentifier
10.1   issuerAndSerialNumber c4 m m m m m o m o m
10.2   subjectKeyIdentifier c4 m o m o m m m m m
11 SignedAttributes See Ref. Row 19
11.1 attrType c5 c5 m m m m m m m m
11.2 attrValues c5 c5 m m7 m m7 m m7 m m7
12 SignatureAlgorithmIdentifier
12.1   DSA m m m m m m o17 m o17 m
12.2   RSA o o o o o o o17 m o17 m
12.3   other o o o o o o o o o o
13 UnsignedAttributes See Ref. Row 20
13.1   attrType c8 c8 c8 m c8 m c8 m c8 m
13.2   attrValues c8 c8 c8 m c8 m c8 m c8 m
14 Data m m i i i i i i i i Not relevant
15 EnvelopedData m m i i i i i i i i Not relevant
16 DigestedData m m i i i i i i i i Not relevant
17 EncryptedData o o i i i i i i i i Not relevant
18 AuthenticatedData o o i i i i i i i i Not relevant
19 CMS Signed Attributes
19.1   contentType c9,13 m mr14 m mr14 m mr14 m mr14 m
19.2   MessageDigest c10 m mr m11 mr m11 mr m11 mr m11
19.3   SigningTime o m o m6 o m6 o m6 o m6
19.4   ESSSecurityLabel o o o o m m m m m m
19.5   EquivalentLabels o o o o o o o o o o
19.6   SMIMECapabilities o o o o o o o m o m
19.7   SMIMEEncryptionKeyPreference o o o o o o o m o m
19.8   SigningCertificate o o o o o o o o o o
19.8   ReceiptRequest o o o o o o o o o o
19.9   ContentIdentifier o o o o o o o o o o
19.10   MLExpansionHistory o o o o o o m m o o
19.11   ContentHints o o o o o o o o o o
19.12   ContentReference o o o o o o o o o o
19.13   MsgSigDigest o o o o o o o o o o
19.4   (any other attribute) o o o m6 o m6 o m6 o m6
20 CMS Unsigned Attributes
20.1   counterSignature o o o o o o o o o o
20.2   (any other attribute) o o o o o o o o o o
NOTES:
1 One and only one instance of the signerInfo element shall be present.
2 At least one of these values shall be supported.
3 Must be an X.400 extended content type identifier. Note that this effectively prohibits nested instances of the signedData element.
4 At least one of these values shall be supported.
5 Conditional on Signed Attributes being supported.
6 An implementation is required to support all signed attributes on reception for the purpose of validating the signature value. No processing of the internal structure or semantics of any attribute, or any of its sub-elements is required unless a specific claim of conformance is made to support the attribute type.
7 Implementations should always support the attribute value when supporting the attribute type.
8 Conditional on Unsigned Attributes being supported.
9 If any content type other than id-data is present or any other signed attributes are present then mr, else o.
10 If any other signed attributes are present then mr, else o.
11 The hash value received in this attribute shall not be used for signature validation (i.e. it shall be recalculated).
12 Support for the generation and processing of this field shall depend on PKI policy agreements.
13 When present, its value specifies the content type of the contentInfo being signed.
14 Its value specifies the content type of the contentInfo being signed, see note 3.
15 If the SignerIdentifier is subjectKeyIdentifier, then the version shall be 3, else the version shall be 1.
16 Both the originator and the recipient MUST be able to handle multiple instances of SignerInfo.
17 Implementations are to support generating [at least] one [of RSA and DSA algorithms].

So how interoperable are these standards? Well, there are all based on CMS SignedData which provides a strong basis for interoperability. The main issues are:

  • Algorithms - PCT is not required to support the reception of RSA
  • Multiple SignerInfos - to provide additional signatures
  • MLExpansionHistory - though it is not clear what the intent of STANAG 4631 in mandating this on origination, or reception when receiptRequest is not mandated.
  • Certificates - including at least the signer's certificate in the message
  • ESSSecurityLabel - PCT uses an alternative labelling mechanism

In reality, multiple signerInfos are infrequently used, implementations can verify signatures without the certificates being present in the message and the MLExpansionHistory is only really applicable to MLAs. So implementations using DSA should provide interoperable non-repudation, authentication and integrity services.

Which leaves security labelling. The Implementer's Guide for STANAG 4406 Edition 1 now actually deprecates the use of P772 content security label in favour of the ESS label. So if the PCT (STANAG 4406 Edition 1) implementation follows the implementor's guide then even security labelling is interoperable

»