Hi Jacob,
What use case did you have in mind for including the expiration date
in the RDATA? We didn't choose to initially include it as we believed
the instructions for when a validation record could be removed were clear
with ACME. ACME challenge tokens are only used once and have the expiry of
Accidentally sent this as a private reply earlier.
First, I don't want the BR process to drive the IETF process. I've been
mostly avoiding really thinking about the BRs with this draft. Especially
since participation here feels a lot simpler and democratic than it does at
CA/B.
Regarding my
Ilari, you've posted some useful extrapolations on how domain scopes could
work. I'm proposing to get rid of domain scopes. :D To get us on the same
page, would you mind posting some of the specific use cases you're
envisioning where domain scopes would be used in an ACME environment? My
existing
On Wed, Mar 20, 2024 at 5:57 PM Amir Omidi wrote:
> I feel like splitting this challenge into three (and potentially more, as
> extra scopes may or may not be added into the future) might be a little too
> noisy.
>
Combined with my other proposals, we only wind up with two total challenge
On Wed, Mar 20, 2024 at 08:57:11PM -0400, Amir Omidi wrote:
> I do think that this draft can do a better job describing the scope. I
> think we should make it more explicit for the client to understand which
> one will be used. I feel like splitting this challenge into three (and
> potentially
Internet-Draft draft-ietf-acme-dtnnodeid-13.txt is now available. It is a work
item of the Automated Certificate Management Environment (ACME) WG of the
IETF.
Title: Automated Certificate Management Environment (ACME) Delay-Tolerant
Networking (DTN) Node ID Validation Extension
Author:
