Subject: Last Call Comments on CMS-10

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Fri, 8 Jan 1999 12:01:51 -0800

Russ,

I have a few comments on the lastest version of the CMS draft published

1.  Section 2, Last paragraph, Sentence 4:  I think that "However, signed
attributes within the signed-data content type and authenticated attributes
within the authenticated-data content type require DER encoding." should
read "However, signed attributes within the signed-data content type
andauthenicated a attributes within the authenticated-data content type are
the only places where DER encoding is required."

2. ASN Module Errors 
"cms.asn", line 176 (CryptographicMessageSyntax): A0256W: 'DigestAlgorithm'
is referenced, but is not defined.
Need to change DigestAlgorithm to DigestAlgorithmIdentifier in
AuthenticatedData

3. The algorithm OIDs defined and used in section 12 are not included in the
ASN module.

4. Section 5, First pagagraph after the bullets.  The text has not been
updated to reflect the SKI addition to the signer info object.

5. Same as above:  "that uniquely identify the certificate containing the
public key" Should read "that uniquely identifies the certificate..."

6. Section 5.1:  The last two paragraphs really belong as part of section
5.2 as they are discussing EncapsulatedContentInfo.  This is especially true
given that it is refered to from places like section 7.

7.  Section 5.1: Text on version needs to be expanded to deal with SKI.
Must be 3 if any SignerInfo version is 3.

8. Section 9. nit-pik -- authenticatedAttributes is misspelt in the ASN for
AuthenticatedData (but it is consistantly misspelt).

9. Section 10.2.6 -- I don't  like the first sentence.  How about "The
UserKeyingMaterial type gives a syntax for user keying material (UKM)."

10. Section 12.3.1, paragraph 3.  I would like to change the first sentence
to "A CMS Implementation should support mixed key-encryption and
content-encryption algorithms."

11. Section 12.3.3 - Please insert the following paragraph in this section
"   A CMS implementation should support mixed key-encryption and content-
   encryption algorithms.  For example, a 128-bit RC2 content-encryption
   key may be wrapped with 168-bit Triple-DES key-encryption key.
   Similarly, a 40-bit RC2 content-encryption key may be wrapped with
   128-bit RC2 key-encryption key.
"
12. Ditto 11 for section 12.6

13. Security Considerations, pargraph 7 - Typo with wises for wishes

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 12 Jan 1999 14:27:49 -0800

At 02:35 PM 1/12/99 -0500, Russ Housley wrote:
>I know.  This is a philosophy question.  Since these identifiers will
>eventually be in the IANA registry, I did not know whether or not these values
>should be part of the module.
>
>I would be glad to add these values to the module if the working group thinks
>they belong there.  Comments?

Please do add them here. It could take a *long* time for them to get into
the IANA, and this document should stand on its own. It is common for the
IANA registries to start with a set of values that were defined in an RFC.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jan 1999 14:35:37 -0500

>the only places where DER encoding is required."

I prefer:
...   However, signed attributes within the signed-data content type and
authenticated attributes within the authenticated-data content type require DER
encoding.  Signed attributes and authenticated attributes must be transmitted
in DER form to ensure that recipients can validate a content that contains an
unrecognized attribute.  Signed attributes and authenticated attributes are the
only CMS data types that require DER encoding.

>Need to change DigestAlgorithm to DigestAlgorithmIdentifier in

Ooops.  You are correct.

>updated to reflect the SKI addition to the signer info object.

Good catch.  How about:
   ...  The signer's public key is referenced by an issuer 
   distinguished name along with an issuer-specific serial 
   number or a subject key identifier that uniquely identify
   the certificate containing the public key.

>public key" Should read "that uniquely identifies the certificate..."

I changed "identify" to "identifies."

>given that it is refered to from places like section 7.

Agreed.  I moved them to the end of section 5.2.

>Must be 3 if any SignerInfo version is 3.

Are you saying that a version 3 SignerInfo should cause parent SignedData
version to be 3?

Is there a reason to prohibit version 3 SignerInfo from being encapsulated in a
version 1 SignedData?

>AuthenticatedData (but it is consistantly misspelt).

I did a global substitution of "authenctiatedAttributes" with
"authenticatedAttributes."

>UserKeyingMaterial type gives a syntax for user keying material (UKM)."

Okay.  I added "for" to the sentence.

>content-encryption algorithms."

Disgree.  I am reluctant to change "may" to "should."  What do other people
think?

>   128-bit RC2 key-encryption key."

As with comment 10, I would like to hear what other people think before
changing "may" to "should."

>12. Ditto 11 for section 12.6

Ditto.  As with comments 10 and 11, I would like to hear what other people
think before changing "may" to "should."

>13. Security Considerations, pargraph 7 - Typo with wises for wishes

I changed it to "wishes."

Russ

---

From: Brian Korver <[email-masked]>
Date: Tue, 12 Jan 1999 16:45:31 -0800

> only CMS data types that require DER encoding.

Agreed.

[snip]
> they belong there.  Comments?

Either include the OIDs, or include a pointer to a document containing the
OIDs (that of course, uses the same names).

[snip]
> Is there a reason to prohibit version 3 SignerInfo from being encapsulated in a
[snip]

I can see arguments on each side:

If the SignedData version is bumped, that will possibly make some ASN.1
decoders happier.

If the SignedData version is left as is, then messages that contain
multiple SignerInfos, some of which are v1/v2, may be partially processed.

Neither of these are critical (both problems can be programmed around),
but I
think the later would be better for implementors (although the spec needs
to state
what to do when there are SignerInfos with "too high" version numbers).
 
On the other hand, my guess would be that bumping the SignedData version number
is ASN.1 Best Current Practice.  Does anyone know?

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 19 Jan 1999 17:49:35 +0100

Russ,

As advertised at the last IETF meeting in Orlando, I have a comment on the
lastest version of the CMS draft published.

On page 12, in the section 5.6  Message Signature Validation Process the text
says “ The input to the signature validation process includes the result of the
message digest calculation process and the signer’s public key”.

The problem is how to get the right signer’s public key and how to know that is
valid or not. If no indication is given, then different results will be obtained
between different implementations. The process is thus much more complicated
than currently indicated as this is explained later on.

The knowledge of the certificate of the signer as well as the time of the
signature are both important. If there is an ambiguity on one or the other
component then the end-result may be quite the opposite.

The certificate is important because a user might use the same public key for
different certificates which include different attributes. In such a case it is
important to know which certificate has been selected by the signer.

The time of the signature is important because the certificate may have been
revoked since the document was signed and thus it is important to verify that
the certificate was valid when the document was signed.

In order to care for these cases, the following text is proposed for section
5.6:

 “ When a signed CMS structure is received, it is important to know who the
signer is and whether the digital signature valid or not. The certificate allows
to identify the signer and possibly some other attributes. A signer may have
multiple certificates, e.g. with the same public key in it. In such a case,
these certificates will have different security attributes in it. It is thus
important to know which certificate has been selected by the signer.

The time of the signature is important because the certificate may have been
revoked since the document was signed and thus it is important to verify that
the certificate was valid when the document was signed.

This means that the certificate to be used for the verification process has to
be verified as valid, i.e. before verifying that the result of the message
digest, the digital signature and the signer’s public key match altogether.

Two cases may be considered:

1) the certificate of the signer is already securely known in advance from the
context and is checked to be valid according to a security policy (i.e. not
individually revoked and the trusted path not revoked as well). In that case it
may be used directly and the public key may be extracted out of it and used as
an input to the verification process.

2) Neither the certificate of the signer,  nor the signature time are known in
advance from the context.. In such a case it is needed to obtain all the
information, i.e. both the certificate of the signer and the correct signing
time, from the data that has been received, in particular from the CMS
structure.

The SignerIdentifier may be used to obtain the right certificate. In some cases
that information may however be insufficient or/and insecure (see [ESS], section
5.4) and the ESSCertId signed attribute shall be used in addition.

If the signer’s certificate and all the cross-certificates from the
certification path are all valid (e.g. not on the appropriate certificate
revocation list (CRL) or authority  revocation list (ARL) or a « not revoked »
status is given back by an OCSP server) and during their validity period at the
time the verification is made, then the public key may be used as an input to
the signature verification process. Otherwise the signature is said to be
invalid.

If the signer’s certificate has been revoked but all the cross-certificates from
the certification path are valid (e.g. at the time the verification is made,
then additional information is needed to know whether the certificate may be
used or not. It is then needed to verify that the signer’s certificate was valid
at the time the signature was made. The signing-time attribute, when present,
may only be used as an hint, since it only specify the time at which the signer
(purportedly) performed the signing process. The time contained in a time stamp
over the CMS structure from a TSA (Time Stamping Authority) will be needed to
know whether or not the certificate was revoked at the time the signature was
made. If the time from the time stamping authority is prior to the reviocation
of the signers’ certificate then the public key may be used as an input to the
signature verification process. Otherwise the signature is said to be invalid.

If one of the cross-certificates is revoked, a time stamp prior to the
revocation of that cross-certificate shall be obtained for that
cross-certificate (or alternatively on the whole certification path). This will
prove that the cross-certificate was valid before the revocation (or even the
key compromise) of that CA. If it is missing, the signature is said to be
invalid.

The input to the signature verification process includes the result of the
message digest calculation process and the signer's public key. The details of
the signature verification depend on the signature algorithm employed.

The recipient may not rely on any message digest values computed by the
originator.  If the signedData signerInfo includes signedAttributes, then the
content message digest must be calculated as described in section 5.4.  For the
signature to be valid, the message digest value calculated by the recipient must
be the same as the value of the messageDigest attribute included in
thesignedAttributes of the signedData signerInfo. »

Denis