[Acme] Re: 回复: Re: 回复: [EXTERNAL] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge

[Q Misell <[e-mail]>]

I don't see why EAB can't be used to link to an identity - perhaps you
could elaborate?
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.


On Mon, 2 Dec 2024 at 03:12, Xialiang(Frank, IP Security Standard)
<frank.xialiang=[e-mail]> wrote:

> No, my point is ACME EAB is only about account authenticity, but not about
> identity and certificate.
>
>
>
> *发件人:* Q Misell <q=[e-mail]>
> *发送时间:* 2024年11月29日 23:07
> *收件人:* Xialiang(Frank, IP Security Standard) <[e-mail]>
> *抄送:* Richard Barnes <[e-mail]>; Aaron Gable <[e-mail]>;
> Mike Ounsworth <[e-mail]>; IETF ACME <[e-mail]>;
> [e-mail]
> *主题:* Re: [Acme] 回复: Re: 回复: [EXTERNAL] Re: Introducting a new draft
> about adding a new ACME challenge type: public key challgenge
>
>
>
> ACME EAB actually has no restrictions on its use. It might be used to link
> to a financial account for billing purposes, or could be used to link to an
> identity account as you desire.
> ------------------------------
>
> Any statements contained in this email are personal to the author and are
> not necessarily the statements of the company unless specifically stated.
> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
> registered in Wales under № 12417574
> <https://find-and-update.company-information.service.gov.uk/company/12417574>,
> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
> <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867.
> EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
> 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
> maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
> Digital, is a company registered in Estonia under № 16755226. Estonian VAT
> №: EE102625532. Glauca Digital and the Glauca logo are registered
> trademarks in the UK, under № UK00003718474 and № UK00003718468,
> respectively.
>
>
>
>
>
> On Thu, 28 Nov 2024 at 03:31, Xialiang(Frank, IP Security Standard)
> <frank.xialiang=[e-mail]> wrote:
>
> Hi Q,
>
> Thanks for your pointing out the reference, I have read this section and
> found that it (external account binding) is another thing about account
> authenticity and performed in the ACME “Account Management” phase,
> different from what our draft proposed about public key authenticity and
> performed in the “Identifier Validation Challenges” phase.
>
>
>
> Hopefully my understanding is not wrong~~
>
>
>
> B.R.
>
> Frank
>
>
>
> *发件人:* Q Misell <q=[e-mail]>
> *发送时间:* 2024年11月27日 21:34
> *收件人:* Xialiang(Frank, IP Security Standard) <[e-mail]>
> *抄送:* Richard Barnes <[e-mail]>; Aaron Gable <[e-mail]>;
> Mike Ounsworth <[e-mail]>; IETF ACME <[e-mail]>;
> [e-mail]
> *主题:* Re: [Acme] 回复: Re: 回复: [EXTERNAL] Re: Introducting a new draft
> about adding a new ACME challenge type: public key challgenge
>
>
>
> Frank, External Account Binding refers to RFC8555 § 7.3.4.
> ------------------------------
>
> Any statements contained in this email are personal to the author and are
> not necessarily the statements of the company unless specifically stated.
> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
> registered in Wales under № 12417574
> <https://find-and-update.company-information.service.gov.uk/company/12417574>,
> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
> <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867.
> EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
> 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
> maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
> Digital, is a company registered in Estonia under № 16755226. Estonian
> VAT №: EE102625532. Glauca Digital and the Glauca logo are registered
> trademarks in the UK, under № UK00003718474 and № UK00003718468,
> respectively.
>
>
>
>
>
> On Wed, 27 Nov 2024 at 09:13, Xialiang(Frank, IP Security Standard)
> <frank.xialiang=[e-mail]> wrote:
>
> Hi Richard,
>
> Thanks for your comments, see inline:
>
>
>
> *发件人:* Richard Barnes <[e-mail]>
> *发送时间:* 2024年11月26日 23:09
> *收件人:* Aaron Gable <[e-mail]>
> *抄送:* Xialiang(Frank, IP Security Standard) <[e-mail]>;
> Mike Ounsworth <[e-mail]>; Q Misell <[e-mail]>;
> IETF ACME <[e-mail]>; [e-mail]
> *主题:* Re: [Acme] Re: 回复: [EXTERNAL] Re: Introducting a new draft about
> adding a new ACME challenge type: public key challgenge
>
>
>
> Looking at this thread and the document, I think there are two plausible
> objectives here:
>
>
>
> 1. Restricting issuance to clients that perform some secondary
> authentication (as the document seems to propose)
>
> 2. Removing the CSR from the protocol (as Aaron suggests)
>
>
>
> A "pubkey" identifier type is the wrong solution for both.
>
>
>
> Goal (1) can be solved today with external account binding.  Build an
> external thing that does whatever vetting you want on a client, then bind
> the vetted account to the ACME account.  If you wanted to make this a
> little more automated, you could do something like an OAuth or OpenID
> integration, but pulling the entire wild world of user authentication into
> ACME is the wrong answer.
>
> [Frank]: Can you clarify more about “external account binding” you mean
> here? I think our proposal is one of the binding, which is feasible, and
> more importantly, automated. If there any other external account binding
> methods have the same effect?
>
>
>
> Goal (2) is might not an unreasonable idea, but I would be concerned about
> (a) compatibility impacts with subjects, (b) compatibility impacts with CA
> back-end APIs, and (c) new cross-protocol risks usage of the certificate
> subject key pair (signing some JOSE thing as well as being used in TLS, vs.
> CSR+TLS, which has been done forever).  Even if we wanted to do this, then
> you don't need the whole machinery of ACME challenges.  You don't need an
> extensible set of ways to validate an ECDSA key, you need one, and probably
> not even one per algorithm -- you could just define a JWS structure that
> was the moral equivalent of a CSR and have the client attach it to an order.
>
> [Frank]: Concur with your concerns. The current ACME 3-phase design is
> good and provides enough compatibility.
>
>
>
> B.R.
>
> Frank
>
>
>
>
>
> On Tue, Nov 26, 2024 at 9:55 AM Aaron Gable <aaron=
> [e-mail]> wrote:
>
> Hi all,
>
>
>
> I agree that it would be beneficial for the ACME protocol to have a pubKey
> identifier type, and to have challenges which can be used to prove control
> over the corresponding private key. However, it seems that I believe this
> would be useful for entirely different reasons than the authors here, and I
> am currently unconvinced by the motivations presented here.
>
>
>
> I believe that a pubKey identifier type is useful for two reasons:
>
> 1) it allows the CSR to be removed from the finalize request, as it will
> no longer be carrying any information that is not already found in other
> parts of the ACME protocol; and
>
> 2) proof-of-possession allows the ACME server to respect keyCompromise
> revocation requests which are signed by the Subscriber key instead of only
> accepting those which are signed by the certificate key.
>
>
>
> It seems that this draft is arguing for the inclusion of a pubKey type and
> corresponding challenges from a security perspective: that an adversary
> might replace the CSR in the finalize request and thereby get issuance of a
> certificate containing a malicious key. I must admit I do not understand
> this threat model.
>
>
>
> If the adversary is simply a network adversary between the legitimate
> Client and Server, then they cannot replace the CSR: the finalize request
> is signed by the ACME client key and cannot be tampered with without
> invalidating that signature. If the adversary is on the ACME client host,
> and has access to the ACME client key, then the game is already lost --
> that adversary *is* the Subscriber for all intents and purposes, and has
> significant latitude: they can change the ACME client key to one the victim
> doesn't control, they can (generally, based on the architecture of most
> clients) complete HTTP-01 and DNS-01 challenges, and they can prove
> possession of any private key they like.
>
>
>
> So I think that this document needs to be overhauled in two ways:
>
> - more clearly motivating the threat model: what exactly is the security
> issue being solved, and why is it import that it be solved; and
>
> - more clearly motivating the solution space: how do proof-of-possession
> challenges mitigate the threat, and why are this particular set of proposed
> challenges the best way to do so.
>
>
>
> Aaron
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>