Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

[Seo Suchan <[e-mail]>]

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=[e-mail]> 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 <[e-mail]>
>     > Sent: Friday, August 11, 2023 1:20 PM
>     > To: Tim Hollebeek <[e-mail]>
>     > Cc: IETF ACME <[e-mail]>
>     > 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
>     <[e-mail]>
>     > 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 <[e-mail]> On Behalf Of Russ Housley
>     > >> Sent: Friday, August 11, 2023 12:57 PM
>     > >> To: IETF ACME <[e-mail]>
>     > >> 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
>     > >> [e-mail]
>     > >> https://www.ietf.org/mailman/listinfo/acme
>
>     _______________________________________________
>     Acme mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/acme
>
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme