[Acme] Re: [iesg] Re: Mike Bishop's Discuss on draft-ietf-acme-device-attest-08: (with DISCUSS and COMMENT)

[Mike Bishop <[e-mail]>]

Yep, that looks reasonable. Thank you!
________________________________
From: Corey Bonnell <[e-mail]>
Sent: Wednesday, July 15, 2026 8:53 PM
To: Deb Cooley <[e-mail]>
Cc: Dev=40cbonnell Com <dev=[e-mail]>; Draft Ietf Acme Device Attest <[e-mail]>; Mike Bishop <[e-mail]>; The IESG <[e-mail]>; Acme Chairs <[e-mail]>; Acme <[e-mail]>; Mike <[e-mail]>
Subject: Re: [Acme] Re: [iesg] Re: Mike Bishop's Discuss on draft-ietf-acme-device-attest-08: (with DISCUSS and COMMENT)

Thanks, Deb. I created this PR to hopefully make the BCP 14 words clearer: https://github.com/ietf-wg-acme/draft-bweeks-acme-device-attest/pull/31/changes.

Absent any comments, I'll merge and push a new version to the Datatracker once it opens up.

Thanks,
Corey



Jul 15, 2026, 14:31 by [e-mail]:
Addressing only one point:

Section 3.2 and 4.2 quote RFC 8555 (CSR MUST) which is fine.   But what follows is the actual update.  Right now you have the MUST with rationale for why one might not, but that logically changes the MUST to a SHOULD, no?  (Mike suggests a 'MUST...unless...', but that is less clear, I think, but YMMV)

The update being made here softens the MUST to a SHOULD (I think), where the rationale you give shows when one might ignore the SHOULD.  After this draft is approved, that MUST turns into a SHOULD.

Does this make sense?

Deb



On Tue, Jul 7, 2026 at 1:11 PM <dev=[e-mail]<mailto:[e-mail]>> wrote:
Hi Mike,
Thank for your previous review as well as your insights on -08. Replies inline below:

> 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 "MUST ... unless..." to permit this new path.

The bottom of sections 3.2 and 4.2 explain the difference:

"[RFC8555<https://ietf-wg-acme.github.io/draft-bweeks-acme-device-attest/draft-ietf-acme-device-attest.html#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..."

I believe this makes the update explicit.

> 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).

We have explicit references to the RFC where the terminology is defined. Since these are normative references, we expect the reader to understand those RFCs before implementing this specification. Given this, copying the terminology into this document would be duplicative.

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

That's a good idea, we will add in the next version.

> 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.

They are similar, but cover different aspects. 6.1.2 alludes to using EAB/other OOB mechanisms for authentication whereas 6.1.3 alludes to the use of multiple challenge types.

> This is probably a SHOULD.

Several other reviewers opined that we should not be using BCP 14 words in section 7, as it is not appropriate to use such words when not describing interoperability.

> Please include links to the IANA registries.

Is this a common practice, and are these links durable? I've seen many RFCs published recently where the registry name is sufficient.

Thanks,
Corey



Jul 7, 2026, 10:12 by [e-mail]<mailto:[e-mail]>:
Mike Bishop has entered the following ballot position for
draft-ietf-acme-device-attest-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/



----------------------------------------------------------------------
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.


----------------------------------------------------------------------
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.
- --------
```



_______________________________________________
Acme mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>