[Acme] Fwd: [saag] ACME @ IETF 126

[Nathanael Ritz <[e-mail]>]

Hi,

On Wed, 29 Jul 2026 at 01:05, Mike Ounsworth <[e-mail]>
wrote:

> <snip>
>
> New Business:
> draft-geng-acme-public-key -- there seemed to be positive reaction to a
> new pk-01 challenge that A) allows for an alternate to the ASN.1-based CSR
> in ACME, and B) allows for support a KEM keys which cannot sign a CSR.
> Chairs to start another CfA.
>
>
As an individual from the RATS WG arena, I want to mention my enthusiastic
support for the KEM PoP approach. I think LAKE also has a similar approach
by way of using KEM keys in the absence of a signature, and TLS probably
owns the prior art on this concept. However, it was Mike's review of
`draft-geng` that first drew my attention to the specific approach. So,
here is another word of early support.  In particular, I see potential
application with cached Attestation Results (AR) from a RATS perspective
where active PoP can be demonstrated using an affirmed KEM key pair. I
haven't looked quite yet, but I am curious if such an application might
also benefit draft-ietf-acme-rats?

Cheers,
Nathanael


--------------------------
From: Mike Ounsworth <[e-mail]>
Date: Wed, 29 Jul 2026 at 01:05
Subject: [saag] ACME @ IETF 126
To: <[e-mail]>


The following drafts are moving nicely, with some requiring minor chair
actions (WGLCs):

draft-ietf-acme-integrations,
draft-ietf-acme-device-attest,
draft-ietf-acme-authority-token-jwtclaimcon,
draft-ietf-acme-dns-account-label,
draft-ietf-acme-dns-persist,
draft-ietf-acme-profiles, draft-ietf-acme-rats

New Business:
draft-geng-acme-public-key -- there seemed to be positive reaction to a new
pk-01 challenge that A) allows for an alternate to the ASN.1-based CSR in
ACME, and B) allows for support a KEM keys which cannot sign a CSR. Chairs
to start another CfA.

Presentation on the ACME aspects of MTC / PLANTS. Decision to leave the
ACME sections within the PLANT doc, but have regular cross-wg updates.

draft-ar-acme-pqc-tlsjws -- long discussion on how to update the one
sentence in RFC8555 that makes ECDSA-P256 mandatory to implement.

Discussion on how to handle the situation where someone no longer has
access to their account key and should be able to re-do domain validation
and then set a new account key and revoke the old one.

Discussion around support for the SM2 ciphers within ACME.
_______________________________________________
saag mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]