Automatic Certificate Management Environment (ACME) Device Attestation Extension
draft-ietf-acme-device-attest-10

[Ballot comment]
Hi Brandon, Ganesh, Sven, Corey, and Ryan,

The changes [1] address almost all the comments [2]. I ACK that the authors will remove RFC8809 from the normative references.

I still think a change is needed for this one:

# Display format: mismatch type vs. payload

CURRENT:
  Content-Type: application/jose+json

  {
    "protected": base64url({
      "alg": "ES256",
      "kid": "https://example.com/acme/acct/evOfKhNU60wg",
      "nonce": "SS2sSl1PtspvFZ08kNtzKd",
      "url": "https://example.com/acme/chall/Rg5dV14Gh1Q"
    }),
    "payload": base64url({
      "attObj": base64url(/* WebAuthn attestation object */),
    }),
    "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
  }

Can we please add some text to explain how the displayed payload should be interpreted.

Better, maybe update the example to follow the convention used in the examples in RFC7515.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-acme-device-attest-07&url2=draft-ietf-acme-device-attest-08&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/acme/0O-8TlKh0j3hRw-JLBOWyXCF-Aw/

[Ballot discuss]
# IESG review of draft-ietf-acme-device-attest-08

Thank you for your update, which addresses a number of my DISCUSS and COMMENT points.
I've updated this ballot to focus on the remaining issues.

CC @MikeBishop

## Discuss

In Sections 3.2 and 4.2, clients and servers MAY violate a MUST in RFC8555.
Section 7.4 reiterates this permission again and recommends the new,
noncompliant behavior.

Although -08 now does explicitly update RFC8555, it doesn't state what the
change is. I would presume that the MUST has become either a "SHOULD" or a
"MUST ... unless..." to permit this new path.

[Ballot comment]
## Comments

### Section 2, paragraph 2

You use a number of terms from other RFCs without direct pointers; I'd
encourage you to add a Terminology section here for things like Assigner
Authority (RFC4043).

### Section 6.1.1, paragraph 1

A reference to Section 7.3.4 of RFC8555 would be useful here.

### Section 6.1.3, paragraph 1

What is the difference between 6.1.2 and 6.1.3? They appear to say the
same thing, that multiple challenge types MAY be deployed in parallel.

### Section 7.4, paragraph 1
```
    Implementers should treat this privacy-preserving mode as the default
    posture unless there is a specific operational requirement for the
```
This is probably a SHOULD.

### Section 9, paragraph 1

Please include links to the IANA registries.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.2, paragraph 6
```
-    PermanentIdentifier in the subjectAltName extension.  See the
-                                                            ----
```

### Section 4.2
```
- Section 7 section for more information.
-          --------
```

[Ballot comment]
I support all outstanding DISCUSS ballots and will avoid repeating their concerns.

In the mean time, I would suggest adding some consideration text regarding the use of the "detail" field in the problem document, as referenced in Section 5:

> If any of the steps fail, then the Server MUST respond to the Client
> with a "badAttestationStatement" error and set the status of the
> challenge object to "invalid". The Server SHOULD provide the reason
> for rejecting the challenge in the "detail" field of the problem document.

Various DNS WGs discussed at length the implications of different data formats provided in DNS error responses, namely the risks of placing URLs there. While this situation is clearly different, I still imagine there are wise and less-wise things for implementations to expose to potentially malicious peers about the nature of the failure. In addition, the use of SHOULD implies there are situations where it is acceptable for the Server to not explain itself. What are those situations? I imagine the answer overlaps with any reason any subset of potential explanations for a failure should not be revealed.

[Ballot comment]
Thanks for the text and attestation based extension.  Especially thanks for the extensive privacy considerations.  And thanks to Mike O. for the shepherd write up; and even adding another paragraph on top after last call edits.

I am not blocking on any of my comments, because most of them are already noted and DISCUSSed by other ADs; so everything in here is really just foot stomping issues already raised.

* 3.1 - yes as noted, the ABNF needs to be fixed.  I think it has more issues than just the parenthesis mismatch; the `device-identifier-value `does not start with a bunch of control sequences, (the %x00-2E), but I’m not really sure what was intended.

* 3.2 ¶2 “ Subject Alternative Name” should become “Subject Alternative Name (SAN)” so that the use of “SAN” in ¶4 is explained.

* 4.1 - as noted in other reviews, the ABNF needs to be fixed.

* 7.4 - As others noted, “MUST consider” is not a protcol mandate.

* 7.6 - ditto on the use of “SHOULD work through…” and “SHOULD treat the attestation…”

* As others noted, this draft does update RFC8555 and should be marked as such

[Ballot comment]
Thanks for the text and attestation based extension.  Especially thanks for the extensive privacy considerations.

I am not blocking on any of my comments, because most of them are already noted and DISCUSSed by other ADs; so everything in here is really just foot stomping issues already raised.

* 3.1 - yes as noted, the ABNF needs to be fixed.  I think it has more issues than just the parenthesis mismatch; the `device-identifier-value `does not start with a bunch of control sequences, (the %x00-2E), but I’m not really sure what was intended.

* 3.2 ¶2 “ Subject Alternative Name” should become “Subject Alternative Name (SAN)” so that the use of “SAN” in ¶4 is explained.

* 4.1 - as noted in other reviews, the ABNF needs to be fixed.

* 7.4 - As others noted, “MUST consider” is not a protcol mandate.

* 7.6 - ditto on the use of “SHOULD work through…” and “SHOULD treat the attestation…”

* As others noted, this draft does update RFC8555 and should be marked as such

[Ballot discuss]
# IESG review of draft-ietf-acme-device-attest-07

CC @MikeBishop

## Discuss

### Updates RFC 8555

In Section 1, paragraph 6, "Variances" is not a defined term in RFC terminology
that I'm aware of.

Are these modifications to RFC8555? Are these new object types being defined for
its extension points? I suspect the latter for the first two; it defines two new
identifier types and one new challenge type. However, the third appears to be a
change to the requirements of RFC8555, which would necessitate an Updates: tag.

In Sections 3.2 and 4.2, clients and servers MAY violate a MUST in RFC8555, which
is a fairly explicit sign that this document Updates RFC8555. Section 7.4 reiterates
this permission again and recommends the new, noncompliant behavior.

### Section 6, paragraph 1
```
    Although this document focuses guidance on implementing new
    identifier types and a challenge for certificate issuance using ACME,
    it does not define a new protocol, a protocol extension, or an
    architecture.
```
Defining new identifier and challenge types for ACME certainly smells like a
protocol extension. How is it not?

### Section 7.1, paragraph 4
```
    Implementers SHOULD assess whether the operational benefit of
    unchanging device identification outweighs this correlation exposure.
    In deployments where device anonymity or pseudonymity is a
    requirement, such as systems handling sensitive workloads on behalf
    of individuals, implementers SHOULD consider whether alternative
    validation mechanisms that do not bind the certificate to a permanent
    hardware identifier are more appropriate.
```
How does an implementation follow the SHOULDs when the guidance is on the
deployment? "SHOULD consider" is straight from Section 2 of
RFC 6919. (Please do not normatively reference RFC 6919.)

### Section 7.2, paragraph 3
```
    Implementers operating ACME Clients SHOULD be aware that the
    attestation format selected may expose more device state than is
    necessary to satisfy the server's authorization policy.  Where
```
How does one implement this SHOULD? I suspect it should be "should" instead.

[Ballot comment]
## Comments

### Section 1, paragraph 7
```
    Using ACME and device attestation to issue client certificates for
    enterprise PKI will be a common use case.  The following variances to
```
This is speculative. Perhaps this could be phrased as enabling this use-case?

### Section 2, paragraph 2

You use a number of terms from other RFCs without direct pointers; I'd
encourage you to add a Terminology section here for things like Assigner
Authority (RFC4043).

### Section 6.1.1, paragraph 1

A reference to Section 7.3.4 of RFC8555 would be useful here.

### Section 6.1.3, paragraph 1

What is the difference between 6.1.2 and 6.1.3? They appear to say the
same thing, that multiple challenge types MAY be deployed in parallel.

### Section 7.4, paragraph 1
```
    Implementers should treat this privacy-preserving mode as the default
    posture unless there is a specific operational requirement for the
```
Contrary to the DISCUSS above, this is probably a SHOULD.

### Section 9, paragraph 1

Please include links to the IANA registries.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.2, paragraph 6
```
-    PermanentIdentifier in the subjectAltName extension.  See the
-                                                            ----
```

### Section 3, paragraph 1
```
    typically a serial number.  Additionally, the assigner of the
    identifier MAY also be specified.  The name of this identifier type
```
Use only one of "Additionally" or "also".

### Section 3.1, paragraph 2
```
  first-and-second-components = (("0" / "1") "." (*1(%x31-33) %x30-39))) / ("2" "." component)
```
Unbalanced ')' in this production and similar

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-acme-device-attest-07
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-acme-device-attest-07.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

My DISCUSSes all center on BCP14 language. I also support Roman's DISUCSS.

### MUST consult

420          specific account key.  The Server MUST consult format-specific
421          documentation to determine which construction applies and MUST
422          verify accordingly.  Attestation formats whose signing procedure

How does a server consult documentation? If this is about conforming to
another specification, maybe:

    The server MUST conform to the specification of a given format and MUST
    verify the attestation accordingly.

Hopefully I got the gist of that correct.

### SHOULD be aware

635        Implementers operating ACME Clients SHOULD be aware that the
636        attestation format selected may expose more device state than is
637        necessary to satisfy the server's authorization policy.  Where
638        multiple attestation formats are available, Clients SHOULD prefer
639        formats that minimize the set of disclosed attributes.

I am not sure the SHOULD on line 635 is normative and to be uppercase.

For the SHOULD on line 638, is there a realistic reason a client would not prefer these formats?
If not, can this be a MUST?

### Implementers operating

718        Implementers operating servers SHOULD store account-to-device
719        bindings using the minimum fidelity necessary for authorization
720        decisions.  Where the operational requirement is only to confirm that
721        a given device is authorized to request certificates, it may be
722        sufficient to store a hash or other one-way transformation of the
723        device identifier rather than the identifier itself.  Implementers
724        should also define and enforce retention limits on historical
725        account-to-certificate linkage records.

This advice appears to be addressing operators and not implementations.
Would it be better to say "Implementations SHOULD store"?

Also, why isn't this a MUST? Is there a realistic reason for not doing this? And if so, can it be stated?

### SHOULD work through

729        Implementers considering whether to include permanent-identifier or
730        hardware-module in CSRs and issued certificates SHOULD work through
731        the following questions before enabling these identifiers:

Can this be a MUST as well? What reason would somebody have for not following these best practices?

[Ballot discuss]

Section 3.2, paragraph 5
>    [RFC8555] section 7.4 mandates that "The CSR MUST indicate the exact
>    same set of requested identifiers as the initial newOrder request".
>    However, there are some environments where the Server requires
>    validation of the identifier but does not include the identifier in
>    certificates due to privacy concerns.  To support privacy-preserving
>    certificates, Clients MAY omit this identifier in the certificate
>    signing request (CSR).  Similarly, if the Server wishes to issue
>    privacy-preserving certificates, it MAY reject CSRs containing a
>    PermanentIdentifier in the subjectAltName extension.  See the
>    Section 7 for more information.

If this document is deviating from RFC8555 on how the Clients
"MAY omit this identifier" and the Server  "MAY reject CSRs containing
a PermenantIdentifier", is that not updating RFC8555? Please either

(a) add a "Updates RFC8555
(b) provide a clear technical argument for why these deviations fall
    within RFC 8555's extensibility provisions (and hence do not constitute
    a modification of its normative requirements).

Section 4.1, paragraph 14
>    The value of the hwSerialNum field of the HardwareModuleName MUST be
>    an octet-for-octet match of the hw-serial-num-value value as encoded
>    in the Order resource.  If the hw-type-value value is included in the
>    identifier as encoded in the Order resource, then the hwType field of
>    the HardwareModuleName MUST be the encoding of the "dotted-decimal"
>    object identifier encoded as the hw-type-value value.

RFC 4108 defines HardwareModuleName with hwType as a required OBJECT
IDENTIFIER (it is not marked OPTIONAL in the ASN.1). When hw-type-value
is absent from the Order, this section is silent on what OID to use for
hwType in the certificate. This is a protocol gap: there is no
interoperable basis for constructing the HardwareModuleName SAN when
hw-type-value is absent.

The document must specify one of:

(a) the OID to use in hwType in this case,
(b) that the identifier may only appear in an issued certificate when
    hw-type-value was specified, or
(c) that a hardware-module Order without hw-type-value can only be
    satisfied in privacy-preserving (identifier-omitted) mode.

[Ballot comment]
Section 3.1, paragraph 1
> assigner-value = first-and-second-components *("." component)
> first-and-second-components = (("0" / "1") "." (*1(%x31-33) %x30-39))) / ("2" "." component)
> component = "0" / (%x31-39 *%x30-39)
> device-identifier-value = 1*(%x00-2E / %x30-FF)

I believe the first-and-second-components statement here and all subsequent such statements have a spurious closing brace (as highlighted by my editor).

Section 5, paragraph 13
>    1.  Perform the verification procedures described in Section 6 of
>        [WebAuthn].

Please check if you have the correct Section here. I believe it should be
Section 7.1 (for WebAuthn Level 2) and Section 8 as applicable.

[Ballot discuss]
Section 3.1, paragraph 1
> assigner-value = first-and-second-components *("." component)
> first-and-second-components = (("0" / "1") "." (*1(%x31-33) %x30-39))) / ("2" "." component)
> component = "0" / (%x31-39 *%x30-39)
> device-identifier-value = 1*(%x00-2E / %x30-FF)

I believe the first-and-second-components statement here and all subsequent such statements have a spurious closing brace (as highlighted by my editor).

Section 3.2, paragraph 5
>    [RFC8555] section 7.4 mandates that "The CSR MUST indicate the exact
>    same set of requested identifiers as the initial newOrder request".
>    However, there are some environments where the Server requires
>    validation of the identifier but does not include the identifier in
>    certificates due to privacy concerns.  To support privacy-preserving
>    certificates, Clients MAY omit this identifier in the certificate
>    signing request (CSR).  Similarly, if the Server wishes to issue
>    privacy-preserving certificates, it MAY reject CSRs containing a
>    PermanentIdentifier in the subjectAltName extension.  See the
>    Section 7 for more information.

If this document is deviating from RFC8555 on how the Clients
"MAY omit this identifier" and the Server  "MAY reject CSRs containing
a PermenantIdentifier", is that not updating RFC8555? Please either

(a) add a "Updates RFC8555
(b) provide a clear technical argument for why these deviations fall
    within RFC 8555's extensibility provisions (and hence do not constitute
    a modification of its normative requirements).

Section 4.1, paragraph 14
>    The value of the hwSerialNum field of the HardwareModuleName MUST be
>    an octet-for-octet match of the hw-serial-num-value value as encoded
>    in the Order resource.  If the hw-type-value value is included in the
>    identifier as encoded in the Order resource, then the hwType field of
>    the HardwareModuleName MUST be the encoding of the "dotted-decimal"
>    object identifier encoded as the hw-type-value value.

RFC 4108 defines HardwareModuleName with hwType as a required OBJECT
IDENTIFIER (it is not marked OPTIONAL in the ASN.1). When hw-type-value
is absent from the Order, this section is silent on what OID to use for
hwType in the certificate. This is a protocol gap: there is no
interoperable basis for constructing the HardwareModuleName SAN when
hw-type-value is absent.

The document must specify one of:

(a) the OID to use in hwType in this case,
(b) that the identifier may only appear in an issued certificate when
    hw-type-value was specified, or
(c) that a hardware-module Order without hw-type-value can only be
    satisfied in privacy-preserving (identifier-omitted) mode.

[Ballot comment]
Section 5, paragraph 13
>    1.  Perform the verification procedures described in Section 6 of
>        [WebAuthn].

Please check if you have the correct Section here. I believe it should be
Section 7.1 (for WebAuthn Level 2) and Section 8 as applicable.

[Ballot discuss]
** Use of BCP14 key words for underspecified behavior

-- Section 7.4
  *  If the certificate is intended for use in certificate transparency
      logs, implementers MUST consider that embedding a permanent-
      identifier or hardware-module value will make that identifier
      permanently and publicly discoverable, indexed by issuance time,
      issuer, and subject. 

Consider using non-BCP14 language.  What is the interoperable definition of “MUST consider”?

-- Section 7.6
7.6.  Implementer Decision Guidance
  Implementers considering whether to include permanent-identifier or
  hardware-module in CSRs and issued certificates SHOULD work through
  the following questions before enabling these identifiers:

Thank you for this thoughtful list of implementation considerations.  Please remove the BCP14 key words from this section.  There is no mechanism to “work though” this list in an interoperable fashion.

[Ballot comment]
Thank you to Roni Even for the GENART review.

** Section 6.1.  Editorial.

6.1.  Enterprise PKI
  ACME was originally envisioned for issuing certificates in the Web
  PKI, however this extension will primarily be useful in enterprise
  PKI.

The purpose of this text is not clear.

** Section 6.2
  Servers SHOULD consider the trust properties of each attestation
  format when establishing issuance policy, including the nature of the
  authority making the attestation and the key protection guarantees it
  can assert.

When should servers ignore the trust properties of each attestation format (i.e., why is this a BCP14 SHOULD?  Shouldn’t this be mandatory?)

** Section 7.3
  Implementers integrating ACME device attestation into enterprise PKI
  platforms should publish a clear attestation data handling policy
  that specifies what attributes are evaluated, how long they are
  retained, and whether they are shared with other systems.

Why would an enterprise PKI have to explain policy choices?

** Section 7.5
  Implementers operating servers SHOULD store account-to-device
  bindings using the minimum fidelity necessary for authorization
  decisions. 

When is it acceptable for implementations to over-collect these bindings?  Perhaps avoid using “SHOULD”?

** Section 8
  See [I-D.ietf-tls-rfc8446bis],
  Appendix C.1 for additional information on randomness requirements.

It wasn’t clear which exact “requirements” were to be extracted from Appendix C.1?  Is it that it is “RECOMMENDED to use an existing CSPRNG implementation in preference to crafting a new one”?

[Ballot discuss]
Hi Brandon, Ganesh, Sven, Corey, and Ryan,

Thank you for the effort put into this document. Appreciate, in particular, the detailed operational guidance in the document.

Please find below some points for discussion:

# IANA registry

CURRENT:
  The webauthn payload MAY contain any identifiers registered in
  "WebAuthn Attestation Statement Format Identifiers" and any
  extensions registered in "WebAuthn Extension Identifiers"
  [IANA-Webauthn], [RFC8809].

Although this is an optional feature, [IANA-Webauthn] is normative as the values are taken from that registry.

As I’m there, I don’t think [RFC8809] citation is needed here (that would also remove the downref).

# I don’t understand the practicalities of the following. What does that concretely mean?

CURRENT:
      The Server MUST consult format-specific
      documentation to determine which construction applies and MUST
      verify accordingly. 

# Strengthen the guidance

CURRENT:
  Implementers operating ACME Clients SHOULD be aware that the
  attestation format selected may expose more device state than is
  necessary to satisfy the server's authorization policy. 

Given the risk to reveal more information that needed, the requirement should be stronger here. s/SHOULD/MUST or “must” or “have to” would be more appropriate here.

[Ballot comment]
# Speculative?

CURRENT:
  Using ACME and device attestation to issue client certificates for
  enterprise PKI will be a common use case. 

Do we really need to include this in an a RFC?

# Redundant behavior

The exclusion of of “/” is covered twice.

Section 3:
  Although [RFC4043] permits any valid UTF-8 string to be used as the
  identifier, this specification mandates that identifiers MUST NOT
  contain the forward-slash "/" (UTF-8: U+002F) character. 

Vs.

Section 3.1
  In addition to the value being a
  valid UTF-8 string, the value MUST match the permanent-identifier-
  value production rule as defined in this ABNF [RFC5234] syntax:

  assigner-value = first-and-second-components *("." component)
  first-and-second-components = (("0" / "1") "." (*1(%x31-33) %x30-39))) / ("2" "." component)
  component = "0" / (%x31-39 *%x30-39)
  device-identifier-value = 1*(%x00-2E / %x30-FF)

The MUST for the ABNF is sufficient in my opinion and would change “MUST NOT” to “must not” in the first excerpt.

The same comment apply for a similar construct in Section 4.

# Valid examples

I suggest to make these changes:

OLD:
  Example identifier without an assigner:
  …
  Example identifier with an assigner:


NEW:
  Example of a valid identifier without an assigner:
  …
  Example of a valid identifier with an assigner:


and

OLD:
  Example identifier with the type of the hardware module represented
  …
  Example of identifier with no type specified and a serial number of

NEW:
  Example of a valid identifier with the type of the hardware module represented
  ….
  Example of a valid identifier with no type specified and a serial number of

# Valid JSON Example

OLD:
    "type": `hardware-module`,

NEW:
    "type": “hardware-module”,

# Section 5: Clients vs The client

OLD:
  The Client can prove control over a permanent identifier of a device

I suggest to change that to

NEW:
  A Client can prove control over a permanent identifier of a device

Or

NEW2:
Clients can prove control over a permanent identifier of a device

# Missing narrative text

OLD:
  The device-attest-01 ACME challenge object has the following format:

  type (required, string):  The string "device-attest-01".

  token (required, string):  A random value that uniquely identifies
      the challenge.

  {
    "type": "device-attest-01",
    "url": "https://example.com/acme/chall/Rg5dV14Gh1Q",
    "status": "pending",
    "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
  }

NEW:
  The device-attest-01 ACME challenge object has the following format:

  type (required, string):  The string "device-attest-01".

  token (required, string):  A random value that uniquely identifies
      the challenge.

  An example message with a device-attest-01 challenge is provided below:

  {
    "type": "device-attest-01",
    "url": "https://example.com/acme/chall/Rg5dV14Gh1Q",
    "status": "pending",
    "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
  }

# Display format: mismatch type vs. payload

CURRENT:
  Content-Type: application/jose+json

  {
    "protected": base64url({
      "alg": "ES256",
      "kid": "https://example.com/acme/acct/evOfKhNU60wg",
      "nonce": "SS2sSl1PtspvFZ08kNtzKd",
      "url": "https://example.com/acme/chall/Rg5dV14Gh1Q"
    }),
    "payload": base64url({
      "attObj": base64url(/* WebAuthn attestation object */),
    }),
    "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
  }

Can we please add some text to explain how the displayed payload should be interpreted.

Better, maybe update the example to follow the convention used in the examples in RFC7515.

# Rationale

It is not clear to me the rationale followed in Section 7 for the use of normative language. That section uses key words to call out some guidance to implementers/operators, but there are some aspects that seem (at least to me) to be important as well but for which key words are not used such as the following:

CURRENT:
  Implementers operating servers must clearly
  define and document the purposes for which attestation data is
  processed and must not process attestation data for purposes
  materially different from authorization of the certificate request
  without explicit policy disclosure to the device owner or operator.

Or

  Implementers should treat this privacy-preserving mode as the default
  posture unless there is a specific operational requirement for the
  identifier to appear in the certificate. 

Or

  Implementers
  should also define and enforce retention limits on historical
  account-to-certificate linkage records.

Cheers,
Med

[Ballot comment]
Thanks for the work done in this document. I have nevertheless a non-blocking comment about the use of "SHOULD" in the operational/privacy/security sections, I note that the protocol specification does not contain such "SHOULD".

Per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, lower case "should" is probably more appropriate per `They shouldn’t be used merely to express a preference. If there are no interoperability implications to the choice being presented, using “MAY” or “OPTIONAL”, or omitting key words entirely, is likely more appropriate.`

UPDATE June 2, 2026:
During the WGLC period between January and May, two additional authors (Corey Bonnell and Ryan Hurst) were added to help address technical feedback that required design work outside the depth of the original authors.
Additionally, a new Contributors section was added to recognize the design and implementation contributions of Mariano Cano and Herman Slatman during the early phase of this draft's development.


# Document Shepherd Write-Up for Group Documents

*This version is dated 8 December 2025.*
Document History
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

This document, as a whole, has been non-contentious since it is documenting a technology already in wide adoption. There has not been much debate, but mainly because I think its usefulness as an RFC is obvious.


2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

There has been spirited debate about how this document interacts with the RATS WG, draft-liu-acme-rats, and draft-ietf-acme-client; but the debate has been about what content should be in the other drafts; this document is a well-scoped, self-contained, and broadly-deployed technology, so nobody suggested changing it.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

The protocol described in this document is implemented in Android, among others.
https://developer.android.com/privacy-and-security/security-key-attestation
We know that several public and private CAs support or intend to support carrying this data over ACME once an RFC exists. I have heard through the grapevine that CA/B Forum is waiting for an RFC and then will adopt this.

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
It interacts with IETF RATS WG, and W3C WebAuthn, but it is merely providing a way to transport those things over ACME, so I do not believe it requires review from those experts.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

I don’t know. I don’t believe that any of this applies.


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

It does not contain a YANG module.


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

None, as far as I know.


Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

This document would benefit from an HTTP dir review.


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?
This document should be Proposed Standard.
I believe it is correctly tagged in Datatracker.


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.


To my knowledge, there is no IPR relating to the new ACME mechanism defined in this document; I have no idea if the same statement is true of the re-packaged W3C WebAuthn payload which is a mandatory-to-implement part of this document. Sven and Ganesh confirm as much. Brandon is unreachable.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.


14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

Since the content is specific to WebAuthn, the authors received a WGLC comment to add the word “WebAuthn” somehow to the in-document title.
I am not aware of any other violations of the content guidelines, but I also have not looked super carefully.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

All Normative references look reasonable to me to be Normative, except that maybe [RFC8809] could be moved to Informative?


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

None.


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.
[RFC8809] is Informational. This should be moved to Informative.
[RFC2985] is Information, but already in DownRef registry.
Everything else looks fine.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).
This document has a fairly complex IANA Considerations, but it seems reasonable to create these registries in order to track which W3C-defined things are allowed in X.509 certificate requests.


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

No new registries.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-acme-device-attest-04. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions that we must complete.

First, in the ACME Identifier Types registry in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

two new registrations are to be made as follows:

Label: permanent-identifier
Reference: [ RFC-to-be ]

Label: hardware-module
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the ACME Validation Methods registry also in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

two new registrations are to be made as follows:

Label: device-attest-01
Identifier Type: permanent-identifier
ACME: Y
Reference: [ RFC-to-be ]

Label: device-attest-01
Identifier Type: hardware-module
ACME: Y
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK.”

Third, in the ACME Error Type registry also in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

a single new registration will be made as follows:

Type: badAttestationStatement
Description: The attestation statement is unacceptable (e.g. not signed by an attestation authority trusted by the CA)
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK.”

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-05-18):

From: The IESG
To: IETF-Announce
CC: acme-chairs@ietf.org, acme@ietf.org, debcooley1@gmail.com, draft-ietf-acme-device-attest@ietf.org, mike@ounsworth.ca
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automated Certificate Management Environment (ACME) Device Attestation Extension) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Automated
Certificate Management Environment (ACME) Device Attestation
  Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-05-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies new identifiers and a challenge for the
  Automated Certificate Management Environment (ACME) protocol which
  allows validating the identity of a device using attestation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8809: Registries for Web Authentication (WebAuthn) (Informational - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

*This version is dated 8 December 2025.*
Document History
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

This document, as a whole, has been non-contentious since it is documenting a technology already in wide adoption. There has not been much debate, but mainly because I think its usefulness as an RFC is obvious.


2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

There has been spirited debate about how this document interacts with the RATS WG, draft-liu-acme-rats, and draft-ietf-acme-client; but the debate has been about what content should be in the other drafts; this document is a well-scoped, self-contained, and broadly-deployed technology, so nobody suggested changing it.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

The protocol described in this document is implemented in Android, among others.
https://developer.android.com/privacy-and-security/security-key-attestation
We know that several public and private CAs support or intend to support carrying this data over ACME once an RFC exists. I have heard through the grapevine that CA/B Forum is waiting for an RFC and then will adopt this.

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
It interacts with IETF RATS WG, and W3C WebAuthn, but it is merely providing a way to transport those things over ACME, so I do not believe it requires review from those experts.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

I don’t know. I don’t believe that any of this applies.


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

It does not contain a YANG module.


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

None, as far as I know.


Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

This document would benefit from an HTTP dir review.


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?
This document should be Proposed Standard.
I believe it is correctly tagged in Datatracker.


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.


To my knowledge, there is no IPR relating to the new ACME mechanism defined in this document; I have no idea if the same statement is true of the re-packaged W3C WebAuthn payload which is a mandatory-to-implement part of this document. Sven and Ganesh confirm as much. Brandon is unreachable.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.


14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

Since the content is specific to WebAuthn, the authors received a WGLC comment to add the word “WebAuthn” somehow to the in-document title.
I am not aware of any other violations of the content guidelines, but I also have not looked super carefully.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

All Normative references look reasonable to me to be Normative, except that maybe [RFC8809] could be moved to Informative?


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

None.


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.
[RFC8809] is Informational. This should be moved to Informative.
[RFC2985] is Information, but already in DownRef registry.
Everything else looks fine.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).
This document has a fairly complex IANA Considerations, but it seems reasonable to create these registries in order to track which W3C-defined things are allowed in X.509 certificate requests.


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

No new registries.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-acme-device-attest-01. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the ACME Identifier Types registry in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

two new registrations will be made as follows:

Label: permanent-identifier
Reference: [ RFC-to-be ]

Label: hardware-module
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the ACME Validation Methods registry also in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

a single new registration will be made as follows:

Label: device-attest-01
Identifier Type: permanent-identifier
ACME: Y
Reference: [ RFC-to-be ]

https://www.iana.org/assignments/acme/

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the ACME Error Types registry also in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

a single new registration will be made as follows:

Type: badAttestationStatement
Description: The attestation statement is unacceptable (e.g. not signed by an attestation authority trusted by the CA)
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-02-12):

From: The IESG
To: IETF-Announce
CC: acme-chairs@ietf.org, acme@ietf.org, debcooley1@gmail.com, draft-ietf-acme-device-attest@ietf.org, mike@ounsworth.ca
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automated Certificate Management Environment (ACME) Device Attestation Extension) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Automated
Certificate Management Environment (ACME) Device Attestation
  Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-02-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies new identifiers and a challenge for the
  Automated Certificate Management Environment (ACME) protocol which
  allows validating the identity of a device using attestation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8809: Registries for Web Authentication (WebAuthn) (Informational - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

*This version is dated 8 December 2025.*
Document History
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

This document, as a whole, has been non-contentious since it is documenting a technology already in wide adoption. There has not been much debate, but mainly because I think its usefulness as an RFC is obvious.


2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

There has been spirited debate about how this document interacts with the RATS WG, draft-liu-acme-rats, and draft-ietf-acme-client; but the debate has been about what content should be in the other drafts; this document is a well-scoped, self-contained, and broadly-deployed technology, so nobody suggested changing it.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

The protocol described in this document is implemented in Android, among others.
https://developer.android.com/privacy-and-security/security-key-attestation
We know that several public and private CAs support or intend to support carrying this data over ACME once an RFC exists. I have heard through the grapevine that CA/B Forum is waiting for an RFC and then will adopt this.

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
It interacts with IETF RATS WG, and W3C WebAuthn, but it is merely providing a way to transport those things over ACME, so I do not believe it requires review from those experts.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

I don’t know. I don’t believe that any of this applies.


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

It does not contain a YANG module.


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

None, as far as I know.


Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

This document would benefit from an HTTP dir review.


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?
This document should be Proposed Standard.
I believe it is correctly tagged in Datatracker.


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.


To my knowledge, there is no IPR relating to the new ACME mechanism defined in this document; I have no idea if the same statement is true of the re-packaged W3C WebAuthn payload which is a mandatory-to-implement part of this document. Sven and Ganesh confirm as much. Brandon is unreachable.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.


14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

Since the content is specific to WebAuthn, the authors received a WGLC comment to add the word “WebAuthn” somehow to the in-document title.
I am not aware of any other violations of the content guidelines, but I also have not looked super carefully.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

All Normative references look reasonable to me to be Normative, except that maybe [RFC8809] could be moved to Informative?


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

None.


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.
[RFC8809] is Informational. This should be moved to Informative.
[RFC2985] is Information, but already in DownRef registry.
Everything else looks fine.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).
This document has a fairly complex IANA Considerations, but it seems reasonable to create these registries in order to track which W3C-defined things are allowed in X.509 certificate requests.


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

No new registries.

# Document Shepherd Write-Up for Group Documents

*This version is dated 8 December 2025.*
Document History
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

This document, as a whole, has been non-contentious since it is documenting a technology already in wide adoption. There has not been much debate, but mainly because I think its usefulness as an RFC is obvious.


2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

There has been spirited debate about how this document interacts with the RATS WG, draft-liu-acme-rats, and draft-ietf-acme-client; but the debate has been about what content should be in the other drafts; this document is a well-scoped, self-contained, and broadly-deployed technology, so nobody suggested changing it.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

The protocol described in this document is implemented in Android, among others.
https://developer.android.com/privacy-and-security/security-key-attestation
We know that several public and private CAs support or intend to support carrying this data over ACME once an RFC exists. I have heard through the grapevine that CA/B Forum is waiting for an RFC and then will adopt this.

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
It interacts with IETF RATS WG, and W3C WebAuthn, but it is merely providing a way to transport those things over ACME, so I do not believe it requires review from those experts.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

I don’t know. I don’t believe that any of this applies.


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

It does not contain a YANG module.


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

None, as far as I know.


Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

This document would benefit from an HTTP dir review.


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?
This document should be Proposed Standard.
I believe it is correctly tagged in Datatracker.


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.


To my knowledge, there is no IPR relating to the new ACME mechanism defined in this document; I have no idea if the same statement is true of the re-packaged W3C WebAuthn payload which is a mandatory-to-implement part of this document. Sven and Ganesh confirm as much. Brandon is unreachable.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.


14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

Since the content is specific to WebAuthn, the authors received a WGLC comment to add the word “WebAuthn” somehow to the in-document title.
I am not aware of any other violations of the content guidelines, but I also have not looked super carefully.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

All Normative references look reasonable to me to be Normative, except that maybe [RFC8809] could be moved to Informative?


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

None.


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.
[RFC8809] is Informational. This should be moved to Informative.
[RFC2985] is Information, but already in DownRef registry.
Everything else looks fine.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).
This document has a fairly complex IANA Considerations, but it seems reasonable to create these registries in order to track which W3C-defined things are allowed in X.509 certificate requests.


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

No new registries.