+1 Ilari
--- Mike Ounsworth From: ilariliusva...@welho.com <ilariliusva...@welho.com> Sent: Monday, November 25, 2024 3:20 AM To: acme@ietf.org Subject: [EXTERNAL] [Acme] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge On Mon, Nov 25, 2024 at 03: 11: 21AM +0000, Xialiang(Frank, IP Security Standard) wrote: > Hi ACME experts, > We submitted and presented a new ACME paper at the IETF 121st > meeting -- https: //urldefense. com/v3/__https: //datatracker. ietf. org/doc/draft-geng-acme-public-key/__;!!FJ-Y8qCqXTj2!e7VZHMOPOgfxtQ55e_jHtvobP4eTa-WRojDITTA_tptr_IOxKVDN9Ty_8JvOfgntN9EqnYeZ9Xmbm9pR0ApsMWtdVb9-7w$. On Mon, Nov 25, 2024 at 03:11:21AM +0000, Xialiang(Frank, IP Security Standard) wrote: > Hi ACME experts, > We submitted and presented a new ACME paper at the IETF 121st > meeting -- > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-geng-acme-public-key/__;!!FJ-Y8qCqXTj2!e7VZHMOPOgfxtQ55e_jHtvobP4eTa-WRojDITTA_tptr_IOxKVDN9Ty_8JvOfgntN9EqnYeZ9Xmbm9pR0ApsMWtdVb9-7w$ > > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-geng-acme-public-key/__;!!FJ-Y8qCqXTj2!e7VZHMOPOgfxtQ55e_jHtvobP4eTa-WRojDITTA_tptr_IOxKVDN9Ty_8JvOfgntN9EqnYeZ9Xmbm9pR0ApsMWtdVb9-7w$> > . > > This draft is about ACME Extension for Public Key Challenges: > basically, we think the current identity validation mechanism of ACME > check the ACME applicant’s control over the requested identity）needs > to consider some necessary extension in some specific use case (The > ACME proxy or ACME applicant itself is taken over by the adversary and > perform the public key replacement attack, result in the replacement > of the public key in the final CSR message and gain the control of the > real applicant’s identity). So, we propose a new ACME challenge type – > ACME public key challenge (pk-01, 3 types of identifier can be applied > with: pk, selfsign-cert and csr), together with IDP and known public > key authentication protocol (i.e., WebAuthn, Opaque/AKE, non- > interactive zero-knowledge (NIZK) discrete logarithm equality (DLEQ) > proof…). Through this extension, the public key authenticity, > consistency and mapping to the identity are all well checked and > protected. The goal of ACME is to be automated (the A even stands for "automated"). Flows involving browser (figure 1) do not look automated. Secondly, proof of possession does not seem helpful countering public key replacement. The attacker controls the private half of the attack key, and can pass any proof of possesion for it. To actually prevent attacks like that, one would need authorization from domain for public keys. A long time ago I had an idea for using CAA records for such purpose. However, having an identifier type for public keys could be useful. One could combine public key identifiers with profiles and order auto- finalize to simplify the protocol (parsing CSRs is not pleasant). Or to add strong key proof-of-possession (but that would cause problems with high-security environments that do not allow private key import/export). -Ilari _______________________________________________ Acme mailing list -- acme@ietf.org <mailto:acme@ietf.org> To unsubscribe send an email to acme-le...@ietf.org <mailto:acme-le...@ietf.org>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
