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> 작성함: >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> On Behalf Of Seo Suchan >Sent: Wednesday, August 16, 2023 8:41 AM >To: Tim Hollebeek <tim.holleb...@digicert.com>; Aaron Gable ><aa...@letsencrypt.org> >Cc: Russ Housley <hous...@vigilsec.com>; IETF ACME <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
