RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (3)

RFC 3852, "Cryptographic Message Syntax (CMS)", July 2004

Note: This RFC has been obsoleted by RFC 5652

Note: This RFC has been updated by RFC 4853, RFC 5083

Source of RFC: smime (sec)

Errata ID: 222
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Russ Housley
Date Reported: 2005-01-22

Section 6.1 says:

          IF (originatorInfo is present) AND
             ((any certificates with a type of other are present) OR
             (any crls with a type of other are present))
          THEN version is 4
          ELSE
             IF ((originatorInfo is present) AND
                (any version 2 attribute certificates are present)) OR
                (any RecipientInfo structures include pwri) OR
                (any RecipientInfo structures include ori)
             THEN version is 3
             ELSE
                IF (originatorInfo is absent) OR
                   (unprotectedAttrs is absent) OR
                   (all RecipientInfo structures are version 0)
                THEN version is 0
                ELSE version is 2

It should say:

          IF (originatorInfo is present) AND
             ((any certificates with a type of other are present) OR
             (any crls with a type of other are present))
          THEN version is 4
          ELSE
             IF ((originatorInfo is present) AND
                (any version 2 attribute certificates are present)) OR
                (any RecipientInfo structures include pwri) OR
                (any RecipientInfo structures include ori)
             THEN version is 3
             ELSE
                IF (originatorInfo is absent) AND
                   (unprotectedAttrs is absent) AND
                   (all RecipientInfo structures are version 0)
                THEN version is 0
                ELSE version is 2

Notes:

Errata ID: 1744
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jan Vilhuber
Date Reported: 2009-03-26
Verifier Name: Tim Polk
Date Verified: 2009-06-05

Section 5 says:

A recipient independently computes the message digest.  This message
digest and the signer's public key are used to verify the signature
value.  The signer's public key is referenced either by an issuer
distinguished name along with an issuer-specific serial number or by
a subject key identifier that uniquely identifies the certificate
containing the public key.  The signer's certificate can be included
in the SignedData certificates field.

It should say:

A recipient independently computes the message digest.  This message
digest and the signer's public key are used to verify the signature
value.  The signer's public key is referenced in one of two ways.
It can be referenced by an issuer distinguished name along with an
issuer-specific serial number to uniquely identify the certificate
that contains the public key.  Alternatively, it can be referenced
by a subject key identifier, which accommodates both certified and
uncertified public keys.  While not required, the signer's
certificate can be included in the SignedData certificates field.

Notes:

The original text seems to indicate that a subjectKeyIdentifier also uniquely identifies a certificate, when in fact no certificate may exist at all. This clarification clarifies some possibly conflicting text from the CMC rfc.

Errata ID: 1756
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Russ Housley
Date Reported: 2009-04-04
Verifier Name: Tim Polk
Date Verified: 2009-06-05

Section 10.1.2 says:

   The SignatureAlgorithmIdentifier type identifies a signature
   algorithm.  Examples include RSA, DSA, and ECDSA.

It should say:

   The SignatureAlgorithmIdentifier type identifies a signature
   algorithm, and it can also identify a message digest alforithm.
   Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with
   SHA-256.

Notes:

Some people have taken the original text to mean that compound signature algorithm identifiers should not be used. This is not the case. Section 12.2 of RFC 2630 (the grandfather of RFC 3852) clearly requires the implementation of id-dsa-with-sha1, which is a compound signature algorithm.

Report New Errata



Advanced Search