Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
updates
- rfc-2634 — Enhanced Security Services for S/MIME
Extracted elements (20)
The default hash algorithm in ESSCertIDv2 is SHA-256 (not SHA-1), reflecting the intent to move away from SHA-1. The structure allows any AlgorithmIdentifier, providing full algorithm agility for future hash function transitions.
The issuer/serial number pair in the sid field of SignerInfo is not covered by the signature, making it vulnerable to substitution. Placing it in the issuerSerial field of ESSCertIDv2 (which is within the signed attribute) ensures it is cryptographically protected.
The original ESSCertID structure in RFC 2634 was hardwired to use SHA-1 for certificate identification. Recent attacks on SHA-1 necessitated a new attribute (SigningCertificateV2) that allows algorithm agility by including an AlgorithmIdentifier field.
This document specifies continued use of the original ESSCertID (SHA-1 only) to ensure backward compatibility with existing implementations, while defining ESSCertIDv2 for algorithm-agile use. Both attributes coexist and are evaluated independently when both are present.
Applications SHOULD recognize both SigningCertificate and SigningCertificateV2 attributes as long as SHA-1 is considered sufficient to distinguish between two different certificates. If both attributes exist in a single message, they are independently evaluated.
Attribute certificates and additional public key certificates not included in the SignedData object SHOULD be identified by the IssuerSerial object, since obtaining the correct certificate based only on a hash is more difficult without this identifier.
For non-attribute certificates, the issuer field in IssuerSerial MUST contain only the issuer name from the certificate encoded in the directoryName choice of GeneralNames. For attribute certificates, it MUST contain the issuer name field from the attribute certificate.
For SigningCertificate (v1), the first certificate in the certs sequence MUST be the certificate used to verify the signature; its ESSCertID SHOULD include the issuerSerial field. If the certificate hash does not match, the signature MUST be considered invalid.
If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid.
SigningCertificate (v1) MUST be a signed attribute and MUST NOT be unsigned. A SignerInfo MUST NOT include multiple instances, and the attribute MUST include exactly one AttributeValue.
SigningCertificateV2 MUST be a signed attribute; it MUST NOT be an unsigned attribute. A SignerInfo MUST NOT include multiple instances of the SigningCertificateV2 attribute, and the attribute MUST include only a single instance of AttributeValue.
The first certificate identified in the certs sequence of SigningCertificateV2 MUST be the certificate used to verify the signature. The encoding of ESSCertIDv2 for this certificate SHOULD include the issuerSerial field.
When the SHA-1 hash function is used, the SigningCertificate attribute MUST be used. The SigningCertificateV2 attribute MUST be used if any algorithm other than SHA-1 is used and SHOULD NOT be used for SHA-1.
SigningCertificate (version 1) is identified by OID id-aa-signingCertificate (pkcs9 smime id-aa 12) and is defined as a SEQUENCE of ESSCertID (which uses an implicit SHA-1 hash) and an optional SEQUENCE OF PolicyInformation.
SigningCertificateV2 is a new signed attribute identified by OID id-aa-signingCertificateV2 (pkcs9 smime id-aa 47), defined as a SEQUENCE containing a SEQUENCE OF ESSCertIDv2 and an optional SEQUENCE OF PolicyInformation.
A poorly selected hash algorithm may provide inadequate protection against certificate substitution or result in denial of service. Selecting the same hash algorithm used for message signing ensures commensurate security and increases the likelihood the algorithm is supported for certificate identification.
The attributes must be placed in locations protected by the signature; placing them in unsigned or unauthenticated locations provides no additional security. The document addresses certificate substitution attacks where an attacker replaces the unprotected issuer/serial number field to point to a different certificate with the same public key.
When both ESSCertID and ESSCertIDv2 are included in the same message for legacy compatibility, their contents could conflict — particularly where a signer has multiple certificates with the same public key, the two attributes could specify different signing certificates. Recipients may choose to reject such messages.
ESSCertID is a SEQUENCE containing certHash (Hash, an OCTET STRING computed over the entire DER-encoded certificate using SHA-1) and an optional issuerSerial (IssuerSerial).
ESSCertIDv2 is a SEQUENCE containing hashAlgorithm (AlgorithmIdentifier, DEFAULT SHA-256), certHash (Hash, an OCTET STRING computed over the entire DER-encoded certificate), and an optional issuerSerial (IssuerSerial).