Clarification and Enhancement of the CSR Attributes Definition in RFC 7030
updates
Extracted elements (21)
Prior template approaches (RFC 8295 Appendix B via pKCS7PDU, and RFC 9810/RFC 9483 via CRMF) had drawbacks: absent RDN values encoded as invalid empty strings, absent subjectPublicKey as empty BIT STRING, and absent extension values as empty OCTET STRING causing strict ASN.1 parsing failures. The new CertificationRequestInfoTemplate avoids these by making those fields genuinely OPTIONAL.
RFC 7030, Section 4.5 was sufficiently ambiguous that there was no universal understanding of how the CSR Attributes Response should encode extension values, leading to implementation challenges in deployments such as RFC 8994 (ACP). This document clarifies the encoding rules and adds a template-based alternative.
EST servers MAY continue serving legacy clients using the unstructured CsrAttrs approach from RFC 7030 and MAY simultaneously include the new CertificationRequestInfoTemplate for newer clients. Clients that understand both formats MUST use only the template and ignore all other CsrAttrs elements; older clients will ignore the new element.
An Extensions structure (SEQUENCE OF Extension) MUST NOT include more than one element with a particular extnID. This prevents duplicate extension types in the CSR attributes response.
In a CertificationRequestInfoTemplate, the 'subject' field MUST be present if the server places any requirements on RDNs of the subject name; otherwise it MUST be absent. An RDN type that the client must include MUST appear in the 'subject' field; absent RDN types MUST be omitted.
RFC 9148 (EST-coaps) is updated by this document: all references to RFC 7030 in RFC 9148 are assumed to indicate RFC 7030 as updated by RFC 9908, so the clarifications apply equally to CoAP-based EST transport.
The OID used in the 'type' field of a CSR Attributes element carrying X.509 extensions MUST be id-ExtensionReq (1.2.840.113549.1.9.14), which is the same as pkcs-9-at-extensionRequest from PKCS#9 (RFC 2985). There MUST be only one such attribute in the CsrAttrs structure.
The 'subjectPKInfo' field of CertificationRequestInfoTemplate MUST be absent if the server places no requirements on the key; if requirements exist, it MUST be present and its 'algorithm' field specifies the required key type.
The 'values' field of an id-aa-extensionReqTemplate attribute MUST contain a SET with exactly one element of type ExtensionTemplate (not the regular Extension type). For each extension specified, the client SHOULD include the given critical flag and SHOULD use the given extnValue when present.
The 'values' field of the id-ExtensionReq attribute MUST contain a SET with exactly one element, and that element MUST be of type Extensions (a SEQUENCE OF Extension as defined in RFC 5280, Section 4.1).
The 'version' field of CertificationRequestInfoTemplate MUST contain v1 (0). The 'attributes' field MUST NOT contain multiple id-aa-extensionReqTemplate attributes and MUST NOT contain both id-ExtensionReq and id-aa-extensionReqTemplate attributes.
When specifying a required public key type outside the template approach, the server MUST include exactly one Attribute whose 'type' OID identifies the key algorithm (e.g., ecPublicKey or rsaEncryption). The 'values' field MAY be empty (no further constraints) or MUST contain suitable parameters such as an EC curve OID or an RSA modulus size integer.
When the server requires an RSA key of a specific size, the 'subjectPublicKey' field in SubjectPublicKeyInfoTemplate MUST be present and contain a placeholder public key value of the desired RSA modulus length; otherwise the 'subjectPublicKey' MUST be absent.
An EST server may use the CSR Attributes mechanism to instruct clients to replace a manufacturer IDevID serial number (which may constitute personally identifiable information) with a new random opaque identifier in the CSR. This is especially desirable when the CA and EST server have different operators.
CertificationRequestInfoTemplate is a new ASN.1 SEQUENCE structure that resembles PKCS#10 CertificationRequestInfo but omits the signature wrapper. Fields 'subject' and 'subjectPKInfo' are OPTIONAL, and 'subjectPublicKey' within SubjectPublicKeyInfoTemplate is OPTIONAL, allowing partial server specification of CSR contents.
ExtensionTemplate is an ASN.1 SEQUENCE similar to Extension (RFC 5280) but with an OPTIONAL 'extnValue' OCTET STRING. When extnValue is absent, the client is expected to fill in an appropriate extension value; when present, the client SHOULD use the provided value.
SingleAttributeTemplate is an ASN.1 SEQUENCE with a required 'type' OID and an OPTIONAL 'value' field. When the value is absent, the client is expected to supply a suitable value for that RDN type; when present, the client is expected to use the given value.
The CsrAttrs ASN.1 structure is a SEQUENCE OF AttrOrOID, where each element is either a bare OBJECT IDENTIFIER or an Attribute containing a 'type' OID and a 'values' SET. This structure is unchanged from RFC 7030 to maintain bits-on-the-wire compatibility.
IANA assigned OID decimal 82 (id-mod-critemplate) in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry for the ASN.1 module defined in Appendix A of this document.
IANA assigned two OIDs in the 'SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)' registry: decimal 61 (id-aa-certificationRequestInfoTemplate) for the CSR template attribute, and decimal 62 (id-aa-extensionReqTemplate) for the extension request template attribute.
The security considerations from RFC 7030, Section 6 are unchanged by this document. The clarifications and new template mechanism do not introduce new security properties beyond those already present in EST.