]> Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

sn3rd llc

Washington, DC US sean@sn3rd.com

LAMPS CMS attribute algorithm identifier This document updates RFC 6211. It corrects errors in the definition of the id-aa-CMSAlgorithmProtect ASN.1 object identifier. The IANA registry entry has always been correct.

Introduction This document corrects errors in , especially an error in the definition of the id-aa-CMSAlgorithmProtection ASN.1 object identifier. The IANA registry entry for this ASN.1 object identifier does not need to be updated; it has always been correct. The authors are aware of two implementations of RFC 6211, but they did not interoperate because one used the ASN.1 object identifier from RFC 6211 and the other used the ASN.1 object identifier from the IANA registry. The ASN.1 object identifier error was reported in and . In addition, the body of the says that a set of attributes will "include only one instance of the algorithm protection attribute" and that there "MUST NOT be zero or multiple instances of AttributeValue present" in the attribute instance. The second requirement can be included as guidance in the ASN.1 definition, but neither requirement can be automatically enforced. This update to RFC 6211 will hopefully resolve future interoperability troubles.

Update to Section 2 of RFC 6211 OLD: NEW:

Update to Appendix A of RFC 6211 OLD: NEW:

IANA Considerations No IANA registry updates are needed. The IANA registry is correct.

Security Considerations The CMS attribute specified in is designed to address the security issue of algorithm substitutions. That is, the originator uses one algorithm, an attacker modifies the message, and then the validator uses a different algorithm. The specified protection is not successful unless all implementers use the same ASN.1 object identifier for the attribute.

References Normative References The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK] Informative References RFC Editor RFC Editor

Acknowledgments Thanks to Paul Timmel for being the first person to spot the error in . Thanks to Corey Bonnell, Mike StJohns, Daniel Van Geest, Carl Wallace for their careful review and constructive comments. The document is much better because of their review.