Summary

  • IESG opened a last call on 2 September for a draft carrying remote attestation in certificate requests, with comments due on 16 September.
  • When several verifiers support the same format identifier, the draft leaves selection rules to that format’s specification. This makes routing behaviour part of an implementation’s compatibility claim.

The next integration question for certificate automation may be deceptively ordinary: where should this evidence go?

The IETF last call announced on 2 September concerns revision 29 of a proposal for carrying remote attestation in certificate signing requests, or CSRs. IESG is considering it as a Proposed Standard and has requested comments by 16 September. It is still a working draft; the announcement does not establish deployment or an approved RFC.

The proposed carrier accommodates standard and proprietary evidence formats in PKCS#10 and CRMF requests. A certification or registration authority can perform verification itself or send material to an external verifier. That flexibility raises a less visible question than whether the request can be decoded: which verifier is intended?

A shared identifier can leave a choice

Section 4.3 of revision 29 explicitly addresses several verifiers supporting the same attestation-format object identifier, or OID. It gives two recommended ways to remove ambiguity: distinguish verifier or verification types through separate OIDs, even if their underlying structures match, or wrap the opaque object with an explicit hint. The precise routing and nonce-selection mechanism belongs in the format specification.

This is not a claim that an OID is an endpoint address. It identifies a format; several services can understand that format. A receiving system still needs an agreed rule for selecting the intended processing context. The draft locates that agreement outside its common carrier.

The distinction has a governance consequence. In an integration, whoever maintains the permitted mapping can influence which service evaluates the request. Merely listing supported formats would not explain that choice. A supplier’s claim of compatibility is more useful if it also identifies the routing convention, the relevant specification and what happens when a hint is absent or inconsistent.

Two different identifier questions

The IANA S/MIME attribute table currently lists value 59 as id-aa-evidence. The draft requests a name change to id-aa-attestation, keeping that value. This concerns the outer CSR attribute. It should not be confused with a registry choosing verification services or assigning every format identifier carried inside it.

Indeed, section 4.2 leaves individual attestation-format OIDs to their specification authors, using identifier arcs they control. The common carrier and the carried format have different custodians. Reading the outer registration alone therefore cannot settle an implementation’s dispatch rules.

RFC 9334’s architecture helps explain why selection matters. The verifier’s owner supplies the policy used to appraise evidence. The relying party’s owner supplies the policy for using the result. Choosing a processor can thus choose an appraisal context, not simply a machine capable of parsing bytes. These roles may be combined operationally, but their responsibilities remain distinguishable.

For a certificate operator, a practical test would be to present the same supported format under each documented routing condition and establish that the intended verifier is selected. That is an editorial proposal for testing the design, not an extra requirement introduced by IETF. Nor does dispatch settle the later security work: revision 29 keeps responsibility for binding the evidence to the requested public key with the CA or RA.

There is no documented misrouting incident or measured switching cost in the sources reviewed here. The news is the design boundary now under last call. A portable envelope can reduce integration work while leaving service selection dependent on a separate, explicit agreement.

Sources

  1. IESG last-call announcement
  2. CSR attestation draft, revision 29
  3. RFC 9334: RATS architecture
  4. IANA SMI identifier assignments