Awesome. Thanks for talking with Yaron Michael!
Cross-posting to ACME.
One quibble, “ACME uses CSRs.”; true; putting the attestation payload inside
the CSR, and the CSR inside ACME is one way to do it (IMO it’s an excellent way
to do it), but I also want to nod to Brandon’s draft-acme-
I'll note that I'm generally strongly in favor of introducing new ACME
identifier types. I'm not very familiar with the exact proposal being
discussed here, but I think that more reliance on identifiers presented at
newOrder time, and less reliance on attributes of the finalize-time CSR, is
the way
Hey Aron
(dropping RATS)
> allowing ACME Servers to ignore the CSR entirely if they so wished
Yeah, that is the direction that CSRs seem to be going for WebPKI – the CSR is
just a public key container with PoP, but we actually don’t really care about
PoP anymore.
I wouldn’t be ag
On Wed, Jul 24, 2024 at 01:05:45PM -0700, Aaron Gable wrote:
>
> For example, I hope to introduce a proposal for a "pubkey" identifier type,
> so that TLS ACME clients can submit their pubkey at newOrder time. This
> would remove the last field that the ACME CA truly relies on the CSR for,
> allow
Hi Brandon,
So, you are registering the challenge "device-attest-01", but your draft is
very specific to WebAuthn, and excludes any other attestation technology.
Request: could you either rename your draft to "webauthn-attest-01", or if
you're willing to broaden the scope of your draft, the
Aaron Gable wrote:
> For example, I hope to introduce a proposal for a "pubkey" identifier
> type, so that TLS ACME clients can submit their pubkey at newOrder
> time. This would remove the last field that the ACME CA truly relies on
> the CSR for, allowing ACME Servers to ignore
Hi, all
So far, we've only got slides from Aaron. And while it's be happy to hear him
talk for two hours, he insists that he needs far less than that.
Please send or propose your slides real soon.
Regards,
Tomofumi and Yoav
On Jul 21, 2024, 19:26, at 19:26, Yoav Nir wrote:
>Hi, all
>
>I see
