(changing the thread title as this is no longer about the algorithm negotiation draft)
Oh yeah, good point. The list in BRv2.0.0 s. 4.9.1.1 is quite clear: 3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise) 4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key (CRLReason #1, keyCompromise) 16. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise (CRLReason #1, keyCompromise) I don’t see anything in there saying “Key Compromise because the subscriber asked nicely”. I guess the next question is: should it even be valid to submit a /revoke-cert with reason: 1, signed by the account key (not the subject key)? Or do the BRs actually require us to do a PoP check on a reason: 1 revocation request? --- Mike Ounsworth From: Aaron Gable <aa...@letsencrypt.org> Sent: Wednesday, August 16, 2023 11:47 AM To: Mike Ounsworth <mike.ounswo...@entrust.com> Cc: Seo Suchan <tjtn...@gmail.com>; Tim Hollebeek <tim.holleb...@digicert.com>; Russ Housley <hous...@vigilsec.com>; IETF ACME <acme@ietf.org> Subject: Re: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME Yes, this is why the Baseline Requirements and Let's Encrypt have special requirements around revocations with reason keyCompromise (Section 4. 9. 12 Special Requirements RE Key Compromise). If a revocation request simply asserts key compromise Yes, this is why the Baseline Requirements and Let's Encrypt have special requirements around revocations with reason keyCompromise (Section 4.9.12 Special Requirements RE Key Compromise). If a revocation request simply asserts key compromise (i.e. the request is signed with the ACME Account key), then the cert in question is revoked with that reason but nothing else happens. If a revocation request *demonstrates* key compromise (i.e. the request is signed with the Certificate's private key), then the cert in question is revoked, all certs that share the same key are revoked, and no certs will be issued over that key in the future. Proof-of-Possession would allow those extra steps to be taken even in the first case: If a revocation request is signed by an ACME Account key *that has proved possession of the Certificate's private key*, then all certs that share the same key could be revoked and the key could be blocklisted against future issuance. Aaron On Wed, Aug 16, 2023 at 9:31 AM Mike Ounsworth <mike.ounswo...@entrust.com<mailto:mike.ounswo...@entrust.com>> wrote: Interesting. As Tim sorta suggested, that idea is going towards having “key validation challenges” which would give you a list of validated subject keys in your account in a similar way, but independent from, “domain validation challenges” that give you a list of validated domains in your account (which the CA may or may not persist). We would need different “key validation challenges” for signing keys vs KEM or DH keys. The core question is still whether PoP provides any meaningful value in WebPKI? Does anyone care if I can get a publicly-trusted cert for my domain and google.com<https://urldefense.com/v3/__http:/google.com__;!!FJ-Y8qCqXTj2!eG0sgKcS7uObmoJLaINk5x-VC2ipwlinCPY9lI4p8yPI_z8VzRbVpfvzIpVfNNEzje1ZNyGj5b2-M1nDBe8VM60$>’s public key? Assuming you don’t have the corresponding private key, can you actually do anything bad with that? I actually just thought of one: revoke it! If I can get a cert in my ACME account with google.com<https://urldefense.com/v3/__http:/google.com__;!!FJ-Y8qCqXTj2!eG0sgKcS7uObmoJLaINk5x-VC2ipwlinCPY9lI4p8yPI_z8VzRbVpfvzIpVfNNEzje1ZNyGj5b2-M1nDBe8VM60$>’s public key, then I revoke that cert with Reason: Key Compromise, then google will fail when they try to renew their cert. That’s a DoS attack against google’s keys. ACME revocation requests (7.6) can be signed by the account key, so there is no PoP check being done at revocation time. If we weaken the PoP check at enrollment time, then that attack probably becomes possible. --- Mike Ounsworth From: Seo Suchan <tjtn...@gmail.com<mailto:tjtn...@gmail.com>> Sent: Wednesday, August 16, 2023 9:06 AM To: Mike Ounsworth <mike.ounswo...@entrust.com<mailto:mike.ounswo...@entrust.com>>; Tim Hollebeek <tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>>; Aaron Gable <aa...@letsencrypt.org<mailto:aa...@letsencrypt.org>> Cc: Russ Housley <hous...@vigilsec.com<mailto:hous...@vigilsec.com>>; IETF ACME <acme@ietf.org<mailto:acme@ietf.org>> Subject: RE: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME more like sign acme account key as test with a new key, than it's registered to use as subject key for later requests On 2023년 8월 16일 오후 10시 49분 30초 GMT+09: 00, Mike Ounsworth <Mike. Ounsworth@ entrust. com> 작성함: Are you suggesting to sign more like sign acme account key as test with a new key, than it's registered to use as subject key for later requests On 2023년 8월 16일 오후 10시 49분 30초 GMT+09:00, Mike Ounsworth <mike.ounswo...@entrust.com<mailto:mike.ounswo...@entrust.com>> 작성함: Are you suggesting to sign the CSR with the ACME account key, instead of the subject key of the CSR? (also reminder that this thread starting with a discussion of KEM PoP which is closely related to ECDH PoP which is probably only relevant to ACME email flows). --- Mike Ounsworth From: Acme <acme-boun...@ietf.org<mailto:acme-boun...@ietf.org>> On Behalf Of Seo Suchan Sent: Wednesday, August 16, 2023 8:41 AM To: Tim Hollebeek <tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>>; Aaron Gable <aa...@letsencrypt.org<mailto:aa...@letsencrypt.org>> Cc: Russ Housley <hous...@vigilsec.com<mailto:hous...@vigilsec.com>>; IETF ACME <acme@ietf.org<mailto:acme@ietf.org>> Subject: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME PoP assumesion will be true at least for lifetime of a certificate itself, maybe we should consider PoP challenge as private key holder authorizing the Acme account to use its public key on certificate, and make expectations accordingly?On PoP assumesion will be true at least for lifetime of a certificate itself, maybe we should consider PoP challenge as private key holder authorizing the Acme account to use its public key on certificate, and make expectations accordingly? On 2023년 8월 16일 오후 10시 14분 53초 GMT+09:00, Tim Hollebeek <tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>> 작성함: As proof of possession is not a requirement, you can use and reuse whatever evidence you want, and still be in compliance. If I want to reuse the ham sandwich that I had at middle school lunch when I was 11 as proof that I control the private key associated with Let's Encrypt root certificate, that does not violate any of Baseline Requirements or any requirements in the ACME specs. It's a useless and false claim, but it’s still compliant. And since there are no PoP validation requirements that must be satisfied, we’re done with compliance! Which just illustrates once again why shooting for minimal compliance is a really bad idea. It allows all sorts of strange things. More speculatively, if I were to write policy in this area, I wouldn’t follow the DV reuse lifetimes, instead, I wouldn’t allow reuse at all. It’s an online interactive authorization step, so I don’t particularly see a use case for non-fresh proofs, unless I’m missing something. If you are going to do PoP, might as well verify that the key is under control of the applicant right now, and not someone who might or might not be the person you are currently talking to, and at some time in the past (this is part of the reason why I don’t think CSR-based PoPs provide much value in most situations. The replay risk is just too high). -Tim From: Aaron Gable <aa...@letsencrypt.org<mailto:aa...@letsencrypt.org>> Sent: Tuesday, August 15, 2023 2:16 PM To: Seo Suchan <tjtn...@gmail.com<mailto:tjtn...@gmail.com>> Cc: Tim Hollebeek <tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>>; Russ Housley <hous...@vigilsec.com<mailto:hous...@vigilsec.com>>; IETF ACME <acme@ietf.org<mailto:acme@ietf.org>> Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME The caching of authorization documentation is controlled by the PKI policy (for the WebPKI, the CA/BF Baseline Requirements), not by the ACME spec. The BRs say that documentation relating to Domain Control Validation (aka ACME Authorizations) must be obtained no more than 398 days prior to issuing the Certificate. Let's Encrypt shortens that to 30 days in its CP/CPS; I believe some other ACME CAs do the same. On the one hand, I don't think those requirements would apply to private key proof-of-possession authorizations. On the other hand, I don't think there would be any compelling reason for a CA to cache keypair PoP authzs for any shorter nor for any longer than DCV authzs. So I suspect that in practice they would be treated similarly, yes. Aaron On Mon, Aug 14, 2023 at 8:20 PM Seo Suchan <tjtn...@gmail.com<mailto:tjtn...@gmail.com>> wrote: If we make keypair as identifier, would it's authorization be valid and cached for 30 days like other auths? for kem keys perspective it doesn't know what it's agree for, so it's in effect authorizing ACME account for post that key onto certificate. 2023-08-12 오전 2:47에 Aaron Gable 이(가) 쓴 글: Oh that's fun, I like that idea. Making it explicit: Introduce a new identifier type "keypair-KEM". When included in a newOrder request, an identifier of that type would have a value that is the full KEM public key. The Server would then create an Authorization for that identifier, and the Challenge object(s) for that Authorization would contain a ciphertext encrypted to that public key. The Client would then POST to the Challenge URL with a body containing the plaintext (very similar to the non-empty Challenge POST body from draft-ietf-acme-onion-00's onion-csr-01 validation method). Very similar flows could be adopted for other keypair types as well. The only additional requirement I see is that, especially for those other keypairs, the CA would have to verify that the public key in the CSR matches the public key provided in the Order. Aaron On Fri, Aug 11, 2023 at 10:26 AM Tim Hollebeek <tim.hollebeek=40digicert....@dmarc.ietf.org<mailto:40digicert....@dmarc.ietf.org>> wrote: I was thinking (a) happens in (1), and (c) happens in (3), but I haven't done enough (or any) analysis to see if that can be made to work. The other possibility is to treat PoP as another identifier that must be validated in (2), which might be cleaner. Dunno. Treating it as a validation step instead of a finalization step feels more correct anyway. "The use of ACME for other identifiers will require further specification in order to describe how these identifiers are encoded in the protocol and what types of validation challenges the server might require." This might be one of those times. -Tim > -----Original Message----- > From: Russ Housley <hous...@vigilsec.com<mailto:hous...@vigilsec.com>> > Sent: Friday, August 11, 2023 1:20 PM > To: Tim Hollebeek > <tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>> > Cc: IETF ACME <acme@ietf.org<mailto:acme@ietf.org>> > Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME > > Tim: > > I understand the large organization problem. With KEM PoP, you need these > things in order: > > a) subject provides the KEM public key > > b) server forms a ciphertext using the provided KEM public key and sends it > to the subject > > c) the subject recovers the plaintext using the KEM private key and send > it to > the server > > These do not fit cleanly into the ACME order finalization process, which is > just > one round trip. > > Russ > > > > On Aug 11, 2023, at 1:10 PM, Tim Hollebeek > > <tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>> > wrote: > > > > Returning it as part of the protocol makes more sense to me than trying to > stuff it into DNS. One could imagine including it as part of some sort of > extension in the CSR that optionally proves possession (if desired), for > example. > > > > One of the challenges we often have with issuance protocols is that the part > of the organization that controls the keys and is setting up servers is often > different from the part of organization that can change DNS, and they can't > always coordinate their work for reasons that should be familiar to anyone > with the misfortune of ever working for a large company. > > > > -Tim > > > >> -----Original Message----- > >> From: Acme <acme-boun...@ietf.org<mailto:acme-boun...@ietf.org>> On Behalf > >> Of Russ Housley > >> Sent: Friday, August 11, 2023 12:57 PM > >> To: IETF ACME <acme@ietf.org<mailto:acme@ietf.org>> > >> Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME > >> > >> Thinking about KEM PoP in the context of ACME. The subject must > >> provide the KEM subject public key as part of the certificate > >> request. A new challenge could be defined (for example, dns-kem-00) > >> where the token is a KEM ciphertext, and the subject needs to put the > >> corresponding plaintext in to DNS. This proves possession of the KEM > >> private key as well as administrative control over the domain. > >> > >> This does not totally match the flow in RFC 8555, which is: > >> > >> 1. Submit an order for a certificate to be issued > >> > >> 2. Prove control of any identifiers requested in the certificate > >> > >> 3. Finalize the order by submitting a CSR > >> > >> 4. Await issuance and download the issued certificate > >> > >> The KEM public key would need to be provided in step 1. I guess it > >> is not a big deal for the KEM public key to be repeated in step 3, as > >> long as the ACME server checked for a match. > >> > >> Russ > >> > >> _______________________________________________ > >> Acme mailing list > >> Acme@ietf.org<mailto:Acme@ietf.org> > >> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!d1lWdVKS0mpqUyJYeAfOyj-HVxy1zG9k4KfsUaVlIh3N5Mq3V7iTmqFitqQadIz4BafsFL_vohGUAkQ97JDo$> _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!d1lWdVKS0mpqUyJYeAfOyj-HVxy1zG9k4KfsUaVlIh3N5Mq3V7iTmqFitqQadIz4BafsFL_vohGUAkQ97JDo$> _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!d1lWdVKS0mpqUyJYeAfOyj-HVxy1zG9k4KfsUaVlIh3N5Mq3V7iTmqFitqQadIz4BafsFL_vohGUAkQ97JDo$> Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
