3. CSR Attributes Handling
This section preserves the RFC text for EST CSR Attributes, including CSR attribute OIDs and values, ASN.1 syntax, id-ExtensionReq, CertificationRequestInfoTemplate, Base64 examples, ASN.1 dump output, IANA registrations, and security considerations.
Original RFC Text
3. CSR Attributes Handling
3.1. Extensions to RFC 7030, Section 2.6
This document replaces the second paragraph in Section 2.6 of
[RFC7030] with the following text:
| These attributes can provide additional information that the EST
| server cannot access itself, such as the Media Access Control
| (MAC) address of an interface of the EST client. The EST server
| can also provide concrete values that it tells the client to
| include in the CSR, such as a specific X.509 Subject Alternative
| Name extension. Moreover, these attributes can indicate the type
| of the included public key or which crypto algorithms to use for
| the self-signature, such as a specific elliptic curve or a
| specific hash function that the client is expected to use when
| generating the CSR.
3.2. Extensions to RFC 7030, Section 4.5.2
The ASN.1 syntax for CSR Attributes as defined in EST ([RFC7030],
Section 4.5.2) is as follows:
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
type ATTRIBUTE.&id({IOSet}),
values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
This remains unchanged, such that bits-on-the-wire compatibility is
maintained.
Key parts that were unclear were which OID to use in the 'type' field
and that the 'values' field can contain an entire sequence of X.509
extensions.
The OID to use for such attributes in the 'type' field MUST be id-
ExtensionReq, which has the value 1.2.840.113549.1.9.14. Note that
this is the same as pkcs-9-at-extensionRequest defined in PKCS#9
[RFC2985]. There MUST be only one such attribute.
The 'values' field of this attribute MUST contain a set with exactly
one element, and this element MUST be of type Extensions, as per
Section 4.1 of [RFC5280]:
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
An Extension comprises the OID of the specific X.509 extension
(extnID), optionally the 'critical' bit, and the extension value
(extnValue).
An Extensions structure, which is a sequence of elements of type
Extension, MUST NOT include more than one element with a particular
extnID.
When not using the template-based approach of Section 3.4, specifying
the requirement for a public key of a specific type and optionally
its size and other parameters MUST be done as follows: Include
exactly one Attribute with the type field being the OID specifying
the type of the key, such as ecPublicKey or rsaEncryption. The
'values' field MAY be empty to indicate no further requirements on
the key. Otherwise, it MUST contain suitable parameters for the
given key type, such as a singleton set containing the OID of an
elliptic curve (EC) (e.g., secp384r1) or containing an integer value
for the RSA key size (e.g., 4096). Many examples for this are given
in Section 5.
3.3. Update to RFC 9148
The updates to EST in this document equally apply when using the
Constrained Application Protocol (CoAP) as a transport mechanism as
described in [RFC9148]. This document therefore adds the following
paragraph after the second paragraph of [RFC9148], Section 1:
| EST over CoAP as specified in [RFC9148] applies unchanged to
| [RFC7030], which is updated by RFC 9908. Hence, all references to
| [RFC7030] in [RFC9148] are assumed to indicate that [RFC7030] is
| updated by RFC 9908.
3.4. Use of CSR Templates
As an alternative to the unstructured inclusion of CSR Attributes
specified in Section 4.5.2 of [RFC7030] with its limitations and
ambiguities, Appendix B of [RFC8295] describes an approach using a
CSR template. An entire CSR object is returned with various fields
filled out and other fields waiting to be filled in. In that
approach, a pKCS7PDU attribute includes a PKIData content type
[RFC5272] and that, in turn, includes a CSR [RFC2986] or a
Certificate Request Message Format (CRMF) formatted request (for
details, see 5 or 9 of [RFC6268], respectively).
One drawback to that approach, particularly for the CSR, is that some
unused fields have to be included; specifically, the 'signature'
field on the CSR is faked with an empty bit string.
A similar method has been defined in "Internet X.509 Public Key
Infrastructure -- Certificate Management Protocol (CMP)" [RFC9810]
and "Lightweight Certificate Management Protocol (CMP) Profile"
([RFC9483], Section 4.3.3) using a CSR template as defined for CRMF
[RFC4211]. Like the approach mentioned before, this method does not
properly deal with absent Relative Distinguished Name (RDN) values,
as it would encode them as invalid empty strings. Also, encoding an
absent 'subjectPublicKey' value as an empty BIT STRING and an absent
X.509 extension value as an empty OCTET STRING can cause issues with
strict ASN.1 parsing and decoding.
These drawbacks are avoided as follows:
This specification defines a new Certificate Request Information
Template attribute for CsrAttrs (as given in Section 3.2) that is
essentially a partially filled-in PKCS#10 CSR minus the signature
wrapper:
CertificationRequestInfoTemplate ::= SEQUENCE {
version INTEGER { v1(0) } (v1, ... ),
subject NameTemplate OPTIONAL,
subjectPKInfo [0] SubjectPublicKeyInfoTemplate
{{ PKInfoAlgorithms }} OPTIONAL,
attributes [1] Attributes{{ CRIAttributes }}
}
Appendix A contains all details.
The CertificationRequestInfoTemplate closely resembles the
CertificationRequestInfo from [RFC5912], Section 5:
CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...),
subject Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes [0] Attributes{{ CRIAttributes }}
}
with the following differences:
* The 'subject' field has been made OPTIONAL. It MUST be present if
the server places any requirements on the RDNs of the subject
name; otherwise, it MUST be absent.
* RDNs in the 'subject' fields are allowed to have no value, which
has been achieved by adding OPTIONAL to the 'value' field of
SingleAttributeTemplate. If the client is expected to provide an
RDN of a certain type such as commonName, the respective RDN MUST
be present in the 'subject' field; otherwise, it MUST be absent.
In addition, if the server gives an RDN value, this means that the
client is expected to use this value for the RDN; otherwise, the
client is expected to fill in a suitable value. The example at
the end of this section has a 'subject' field that contains both
forms of RDN specifications.
SingleAttributeTemplate {ATTRIBUTE:AttrSet} ::= SEQUENCE {
type ATTRIBUTE.&id({AttrSet}),
value ATTRIBUTE.&Type({AttrSet}{@type}) OPTIONAL
}
* The 'subjectPKInfo' field has been made OPTIONAL. The field MUST
be absent if the server places no requirements on the key;
otherwise, it MUST be present, and the 'algorithm' field specifies
the type of key pair the client is expected to use.
* The 'subjectPublicKey' field contained in
SubjectPublicKeyInfoTemplate has been made OPTIONAL because it is
usually not needed. In case the server requires use of an RSA key
and needs to specify its size, the field MUST be present and
contain a placeholder public key value of the desired RSA modulus
length; otherwise, the subjectPublicKey MUST be absent.
SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE {
algorithm AlgorithmIdentifier{PUBLIC-KEY, {IOSet}},
subjectPublicKey BIT STRING OPTIONAL
}
* A new OID id-aa-extensionReqTemplate and the related
ExtensionTemplate structure is defined where the 'extnValue' field
has been made OPTIONAL. This is only needed to enable specifying
partial extensions with values to be filled in by the client;
otherwise, the id-ExtensionReq OID and the respective value of
type ExtensionReq MUST be used for specifying requirements on
X.509 extensions.
For each extension of type Extension or ExtensionTemplate provided by
the server, the client is expected to include an extension of the
type given by the extnID. If the 'critical' field is present, the
client SHOULD use it in the extension as well. If the 'extnValue' is
present (which is always the case when type Extension is used), the
client SHOULD use the given extension value in its CSR. When the
type ExtensionTemplate is used, the 'extnValue' can be absent, and
then the client SHOULD provide an extension value in an Extension
with the given extnID. For instance, if the server includes an
ExtensionTemplate with the extnID 'subjectAltName' but without an
extnValue, the client SHOULD include a SAN extension with a suitable
value.
In case the server includes an ExtensionTemplate with the extnID
'subjectAltName' and a partially filled-in extnValue, such as a
'directoryName' choice containing the NULL-DN (i.e., an empty
sequence of RDNs) or the 'iPAddress' choice with an empty OCTET
STRING, it means that the client SHOULD fill in the respective
GeneralName value.
ExtensionTemplate {EXTENSION:ExtensionSet} ::= SEQUENCE {
extnID EXTENSION.&id({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING (CONTAINING
EXTENSION.&ExtnType({ExtensionSet}{@extnID}) OPTIONAL
-- contains the DER encoding of the ASN.1 value
-- corresponding to the extension type identified
-- by extnID when present
}
The 'version' field of the 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.
The 'values' field of an id-aa-extensionReqTemplate attribute MUST
contain a set with exactly one element, and this element MUST be of
type ExtensionTemplate.
Suppose the server requires that the CSR will contain:
* the 'subject' field with a common name to be filled in by the EE
and two organizational unit names with given values "myDept" and
"myGroup",
* the 'publicKey' field with an Elliptic Curve Cryptography (ECC)
public key on curve secp256r1,
* the 'subjectAltName' extension with two entries; one DNS entry
with name "www.myServer.com" and IP entry that is empty for the IP
address to be filled in,
* the 'keyUsage' extension marked critical with the values
digitalSignature and keyAgreement, and
* the 'extKeyUsage' extension with the value to be filled in by the
EE.
Then, the CertificationRequestInfo structure constructed by the
server will be as follows:
SEQUENCE {
INTEGER 0
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String "myDept"
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String "myGroup"
}
}
}
[0] {
SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
}
}
[1] {
SEQUENCE {
OBJECT IDENTIFIER id-aa-extensionReqTemplate
(1 2 840 113549 1 9 62)
SET {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17)
OCTET STRING, encapsulates {
SEQUENCE {
[2] "www.myServer.com"
[7] ""
}
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
BOOLEAN TRUE
OCTET STRING, encapsulates {
BIT STRING 3 unused bits
"10001"B
}
}
SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
}
}
}
}
}
}