Skip to main content
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

I'm really grinding my teeth against digest calculation explanationdigest calculation explanation in the CMS standard.

Let's consider the case when the signedAttrs are present.

The first paragraph says

initial input to the message digest calculation process is the "value" of the encapsulated content being signed.

To me that implies that whatever digest value that will be signed, somehow "starts" with being the digest of the message.

The second paragraph says:

When the [signedAttrs] field is present, however, the result is the message
digest of the complete DER encoding of the SignedAttrs value
contained in the signedAttrs field.

To me this does sound like the result is solely derived from the signedAttrs value, but then the first paragraph seems to be contradictory because it said that no matter what, the digest must start with encapsulated content. The second paragraph does then mention that the content hash will be indirectly included, because it must be present, but to me that still doesn't negate implication made in the first paragraph.

P.S. Based on OpenSSL implementation, I figure that the "correct" behavior is only hashing signedAttrs.

I'm really grinding my teeth against digest calculation explanation in the CMS standard.

Let's consider the case when the signedAttrs are present.

The first paragraph says

initial input to the message digest calculation process is the "value" of the encapsulated content being signed.

To me that implies that whatever digest value that will be signed, somehow "starts" with being the digest of the message.

The second paragraph says:

When the [signedAttrs] field is present, however, the result is the message
digest of the complete DER encoding of the SignedAttrs value
contained in the signedAttrs field.

To me this does sound like the result is solely derived from the signedAttrs value, but then the first paragraph seems to be contradictory because it said that no matter what, the digest must start with encapsulated content. The second paragraph does then mention that the content hash will be indirectly included, because it must be present, but to me that still doesn't negate implication made in the first paragraph.

P.S. Based on OpenSSL implementation, I figure that the "correct" behavior is only hashing signedAttrs.

I'm really grinding my teeth against digest calculation explanation in the CMS standard.

Let's consider the case when the signedAttrs are present.

The first paragraph says

initial input to the message digest calculation process is the "value" of the encapsulated content being signed.

To me that implies that whatever digest value that will be signed, somehow "starts" with being the digest of the message.

The second paragraph says:

When the [signedAttrs] field is present, however, the result is the message
digest of the complete DER encoding of the SignedAttrs value
contained in the signedAttrs field.

To me this does sound like the result is solely derived from the signedAttrs value, but then the first paragraph seems to be contradictory because it said that no matter what, the digest must start with encapsulated content. The second paragraph does then mention that the content hash will be indirectly included, because it must be present, but to me that still doesn't negate implication made in the first paragraph.

P.S. Based on OpenSSL implementation, I figure that the "correct" behavior is only hashing signedAttrs.

Source Link

What does CMS standard mean by "initial input to the message digest"

I'm really grinding my teeth against digest calculation explanation in the CMS standard.

Let's consider the case when the signedAttrs are present.

The first paragraph says

initial input to the message digest calculation process is the "value" of the encapsulated content being signed.

To me that implies that whatever digest value that will be signed, somehow "starts" with being the digest of the message.

The second paragraph says:

When the [signedAttrs] field is present, however, the result is the message
digest of the complete DER encoding of the SignedAttrs value
contained in the signedAttrs field.

To me this does sound like the result is solely derived from the signedAttrs value, but then the first paragraph seems to be contradictory because it said that no matter what, the digest must start with encapsulated content. The second paragraph does then mention that the content hash will be indirectly included, because it must be present, but to me that still doesn't negate implication made in the first paragraph.

P.S. Based on OpenSSL implementation, I figure that the "correct" behavior is only hashing signedAttrs.