[Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"?
Q said: > Personally I'm in favour of a CMW attestation being device-attest-02. Yeah, I think the outcome of this thread is that that’s the right direction. Now we need a hero to start that draft. Carl said: > That’s fine, but it opens the potential for the same types to be registered > under different wrappers. It’s not the end of the world. IMO that’s the lesser of evils here, by a wide margin, compared to forcing ACME clients to have to un-wrap evidence statements from one wrapper format into another, or nesting wrapper formats which is just yuck. --- Mike Ounsworth From: Carl Wallace Sent: Tuesday, July 30, 2024 11:55 AM To: Q Misell Cc: Mike Ounsworth ; Thomas Fossati ; acme@ietf.org; draft-acme-device-att...@ietf.org Subject: [EXTERNAL] Re: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? That’s fine, but it opens the potential for the same types to be registered under different wrappers. It’s not the end of the world. From: Q Misell Date: Tuesday, July 30, 2024 at 2: 59 AM To: Carl Wallace That’s fine, but it opens the potential for the same types to be registered under different wrappers. It’s not the end of the world. From: Q Misell mailto:q...@as207960.net> > Date: Tuesday, July 30, 2024 at 2:59 AM To: Carl Wallace mailto:c...@redhoundsoftware.com> > Cc: Mike Ounsworth mailto:mike.ounswo...@entrust.com> >, Thomas Fossati mailto:thomas.foss...@linaro.org> >, "acme@ietf.org <mailto:acme@ietf.org> " mailto:acme@ietf.org> >, "draft-acme-device-att...@ietf.org <mailto:draft-acme-device-att...@ietf.org> " mailto:draft-acme-device-att...@ietf.org> > Subject: Re: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? Given "device-attest-01" is already shipped in some client implementations I don't think we should change the name. I also don't think we should try and make this more generic and add more wrapper layers, type IDs are free, we can just invent more. Personally I'm in favour of a CMW attestation being device-attest-02. We haven't really settled on what the 'version' number in types means, but I think setting the precedent this way is probably correct. _ 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://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!eLqtpd5eDGyTsNpSh6qMXG6gYxkxB8mvl46EefjU6mcD7KjwxQ-tVpiQ7TnnhE79Q2HoCH_u5X-XmjtPLIkvl0PF$> , LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!eLqtpd5eDGyTsNpSh6qMXG6gYxkxB8mvl46EefjU6mcD7KjwxQ-tVpiQ7TnnhE79Q2HoCH_u5X-XmjtPLDPoA4Wg$> . 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 № UK3718474 and № UK3718468, respectively. On Fri, 26 Jul 2024 at 12:09, Carl Wallace mailto:c...@redhoundsoftware.com> > wrote: Inline… From: Mike Ounsworth mailto:mike.ounswo...@entrust.com> > Date: Thursday, July 25, 2024 at 3:40 PM To: Carl Wallace mailto:c...@redhoundsoftware.com> >, Thomas Fossati mailto:thomas.foss...@linaro.org> > Cc: "acme@ietf.org <mailto:acme@ietf.org> " mailto:acme@ietf.org> >, "draft-acme-device-att...@ietf.org <mailto:draft-acme-device-att...@ietf.org> " mailto:draft-acme-device-att...@ietf.org> > Subject: RE: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? Carl, You’d propose to put inside CMW, inside WebAuthn, inside the device-attest-01 defined in Brandon’s draft? Is that done? I see the registry you’re referring to of registered Webauthn sub-formats: https://www.iana.org/assignments/webauthn/webauthn.xhtml <https://urldefense.com/v3/__https:/www.iana.org/assignments/webauthn/webauthn.xhtml__;!!FJ-Y8qCqXTj2!eLqtpd5eDGyTsNpSh6qMXG6gYxkxB8mvl46EefjU6mcD7KjwxQ-tVpiQ7TnnhE79Q2HoCH_u5X-XmjtPLOBBArAl$> but I don’t see CMW. [CW] Well, right. That would need to be added, which is why I referenced the registration steps. None of the items in your list are “done” eit
[Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"?
Carl, You’d propose to put inside CMW, inside WebAuthn, inside the device-attest-01 defined in Brandon’s draft? Is that done? I see the registry you’re referring to of registered Webauthn sub-formats: https://www.iana.org/assignments/webauthn/webauthn.xhtml but I don’t see CMW. Is that the intended usage of CMW; to be a sub-format of WebAuthn? --- Mike Ounsworth From: Carl Wallace Sent: Thursday, July 25, 2024 2:32 PM To: Mike Ounsworth ; Thomas Fossati Cc: acme@ietf.org; draft-acme-device-att...@ietf.org Subject: [EXTERNAL] Re: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? Inline… From: Mike Ounsworth mailto:mike.ounswo...@entrust.com> > Date: Thursday, July 25, 2024 at 11:30 AM To: Carl Wallace mailto:c...@redhoundsoftware.com> >, Thomas Fossati mailto:thomas.foss...@linaro.org> > Cc: "acme@ietf.org <mailto:acme@ietf.org> " mailto:acme@ietf.org> >, "draft-acme-device-att...@ietf.org <mailto:draft-acme-device-att...@ietf.org> " mailto:draft-acme-device-att...@ietf.org> > Subject: RE: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? Carl, Thomas, I think we’re gonna see three situations: 1) ACME attestation evidence comes wrapped inside WebAuthn. 2) ACME attestation evidence comes wrapped inside CMW. 3) ACME attestation evidence comes in some other format – either not wrapped, or in some other wrapper format. [CW] My point was that those situations could be represented as attestation statement formats within WebAuthn (though since my note below I recalled that this draft does not leverage the existing registry but creates its own). I don’t think we want to end up with a scenario like what happened with cert request protocols in PKIX 20+ years ago and wind up with multiple competing mechanisms to support attestations. Case #1 is covered by Brandon’s draft (but I would like to see it suitably renamed). For cases 2 & 3, since CMW is an IETF spec, it’s reasonable for ACME to make an opinionated choice that you can’t put bare attestation payloads, they have to be either WebAuthn, or wrapped in CMW. That does put the responsibility on the ACME client Regardless, somebody probably needs to start a draft parallel to Brandon’s that tells how to carry CMW in ACME so that we can start having these discussions – let’s not slow down Brandon’s draft by trying to add CMW to it because I understand that it has real-world deployments waiting for it. [CW] Leveraging WebAuthn extensibility mechanisms ought not to impact Brandon’s draft. I think the steps to define how to carry a CMW in ACME are those described in 7.4. That might be a good exercise to conduct before discarding that as a way forward. --- Mike Ounsworth From: Carl Wallace mailto:c...@redhoundsoftware.com> > Sent: Thursday, July 25, 2024 8:19 AM To: Thomas Fossati mailto:thomas.foss...@linaro.org> >; Mike Ounsworth mailto:mike.ounswo...@entrust.com> > Cc: acme@ietf.org <mailto:acme@ietf.org> ; draft-acme-device-att...@ietf.org <mailto:draft-acme-device-att...@ietf.org> Subject: [EXTERNAL] Re: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? Why is the extensibility mechanism in webauthn not sufficient? There's even a registry already set up for those already: https: //urldefense. com/v3/__https: //www. rfc-editor. org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$. Why is the extensibility mechanism in webauthn not sufficient? There's even a registry already set up for those already: https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$ <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$> . On 7/25/24, 9:13 AM, "Thomas Fossati" mailto:thomas.foss...@linaro.org%20%3cmailto:thomas.foss...@linaro.org> <mailto:thomas.foss...@linaro.org>> wrote: Hi Mike, Brandon, On Wed, 24 Jul 2024 at 23:10, Mike Ounsworth mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org%20%3cmailto:40entrust@dmarc.ietf.org> <mailto:40entrust@dmarc.ietf.org>> wrote: > > Hi Brandon, > > So, you are registering the challenge “device-attest-01”, but your draft is > very specific to WebAuthn, and excludes any other attestation technology. > > Request: could you either rename your draft to “webauthn-attest-01” I support this. > or i
[Acme] Re: [EXTERNAL] Re: Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"?
> The identifier version suffix seems plausibly useful here. Could the future > ACME CMW document register "device-attest-02" instead of repurposing > "device-attest-01"? I could see that working. --- Mike Ounsworth -Original Message- From: Brandon Weeks Sent: Thursday, July 25, 2024 11:37 AM To: Thomas Fossati Cc: Mike Ounsworth ; Carl Wallace ; acme@ietf.org; draft-acme-device-att...@ietf.org Subject: [EXTERNAL] Re: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? While the final draft could certainly register "webauthn-attest-01" instead, I seriously doubt reclaiming "device-attest-01" for more generic use is possible at this point. Just as an one example, three major versions of iOS and two major versions of macOS at a minimum will ship that use the validation method identifier from the current draft. So ACME server implementations that support Apple devices will have to assume the payload is WebAuthn for years to come. The identifier version suffix seems plausibly useful here. Could the future ACME CMW document register "device-attest-02" instead of repurposing "device-attest-01"? On Thu, Jul 25, 2024 at 11:49 AM Thomas Fossati wrote: > > On Thu, 25 Jul 2024 at 17:30, Mike Ounsworth > wrote: > > Regardless, somebody probably needs to start a draft parallel to Brandon’s > > that tells how to carry CMW in ACME so that we can start having these > > discussions > > Happy to help with that. > > > [...] let’s not slow down Brandon’s draft by trying to add CMW to it > > because I understand that it has real-world deployments waiting for it. > > In violent agreement. smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
[Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"?
Carl, Thomas,
I think we’re gonna see three situations:
1) ACME attestation evidence comes wrapped inside WebAuthn.
2) ACME attestation evidence comes wrapped inside CMW.
3) ACME attestation evidence comes in some other format – either not wrapped,
or in some other wrapper format.
Case #1 is covered by Brandon’s draft (but I would like to see it suitably
renamed).
For cases 2 & 3, since CMW is an IETF spec, it’s reasonable for ACME to make an
opinionated choice that you can’t put bare attestation payloads, they have to
be either WebAuthn, or wrapped in CMW. That does put the responsibility on the
ACME client
Regardless, somebody probably needs to start a draft parallel to Brandon’s that
tells how to carry CMW in ACME so that we can start having these discussions –
let’s not slow down Brandon’s draft by trying to add CMW to it because I
understand that it has real-world deployments waiting for it.
---
Mike Ounsworth
From: Carl Wallace
Sent: Thursday, July 25, 2024 8:19 AM
To: Thomas Fossati ; Mike Ounsworth
Cc: acme@ietf.org; draft-acme-device-att...@ietf.org
Subject: [EXTERNAL] Re: [Acme] Re: Can we rename
"draft-bweeks-acme-device-attest" to "webauthn-attest"?
Why is the extensibility mechanism in webauthn not sufficient? There's even a
registry already set up for those already: https: //urldefense. com/v3/__https:
//www. rfc-editor.
org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$.
Why is the extensibility mechanism in webauthn not sufficient? There's even a
registry already set up for those already:
https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$
<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$>
.
On 7/25/24, 9:13 AM, "Thomas Fossati" mailto:thomas.foss...@linaro.org%20%3cmailto:thomas.foss...@linaro.org>
<mailto:thomas.foss...@linaro.org>> wrote:
Hi Mike, Brandon,
On Wed, 24 Jul 2024 at 23:10, Mike Ounsworth
mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org%20%3cmailto:40entrust@dmarc.ietf.org>
<mailto:40entrust@dmarc.ietf.org>> wrote:
>
> Hi Brandon,
>
> So, you are registering the challenge “device-attest-01”, but your draft is
> very specific to WebAuthn, and excludes any other attestation technology.
>
> Request: could you either rename your draft to “webauthn-attest-01”
I support this.
> or if you’re willing to broaden the scope of your draft, then I think the
> obvious way would be to add a “type” field to POST /acme/chall :
>
> "payload": base64url({“type”: “webauthn”,
> "attObj": base64url(/* WebAuthn attestation object */),
>
> … then continue your WebAuthn draft as you are.
>
> At least then it would be extensible to accept other attestation evidence
> formats in the future – we’d have to debate whether we need a new registry
> for those “type” values; or whether there already exists a suitable registry
> that we could piggy-back on.
Re: Extensibility. Note that CMW [1] has been designed precisely to
support situations like this, i.e., where the RATS "relying party" (in
this case, the ACME server) need not know the details about the
specific attestation evidence format and blindly forwards it to the
attestation verifier to get a yes/no answer. An OID (id-pe-cmw) has
been registered for the purpose in the relevant SMI registry [2].
cheers, t
[1]
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$>
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$>
>
[2]
https://urldefense.com/v3/__https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml*smi-numbers-1.3.6.1.5.5.7.1__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXtoZTdvJ$
<https://urldefense.com/v3/__https:/www.iana
[Acme] Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"?
Hi Brandon,
So, you are registering the challenge "device-attest-01", but your draft is
very specific to WebAuthn, and excludes any other attestation technology.
Request: could you either rename your draft to "webauthn-attest-01", or if
you're willing to broaden the scope of your draft, then I think the obvious
way would be to add a "type" field to POST /acme/chall :
"payload": base64url({"type": "webauthn",
"attObj": base64url(/* WebAuthn attestation object */),
. then continue your WebAuthn draft as you are.
At least then it would be extensible to accept other attestation evidence
formats in the future - we'd have to debate whether we need a new registry
for those "type" values; or whether there already exists a suitable registry
that we could piggy-back on.
- - -
Mike Ounsworth
Software Security Architect
(pronouns: he/him)
smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
[Acme] Re: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft,
Hey Aron (dropping RATS) > allowing ACME Servers to ignore the CSR entirely if they so wished Yeah, that is the direction that CSRs seem to be going for WebPKI – the CSR is just a public key container with PoP, but we actually don’t really care about PoP anymore. I wouldn’t be against registering a generic “device-attest” challenge type so that there’s a way to do this outside of the CSR. Unfortunately Brandon has grabbed “device-attest-01” to specifically mean “webauthn”. Actually I’ll post a comment on Brandon’s draft that it should be renamed to “webauthn-attest-01”. New email thread incoming. --- Mike Ounsworth From: Aaron Gable Sent: Wednesday, July 24, 2024 3:06 PM To: Mike Ounsworth Cc: Michael Richardson ; r...@ietf.org; acme@ietf.org Subject: Re: [Acme] Re: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft, I'll note that I'm generally strongly in favor of introducing new ACME identifier types. I'm not very familiar with the exact proposal being discussed here, but I think that more reliance on identifiers presented at newOrder time, I'll note that I'm generally strongly in favor of introducing new ACME identifier types. I'm not very familiar with the exact proposal being discussed here, but I think that more reliance on identifiers presented at newOrder time, and less reliance on attributes of the finalize-time CSR, is the way forward. For example, I hope to introduce a proposal for a "pubkey" identifier type, so that TLS ACME clients can submit their pubkey at newOrder time. This would remove the last field that the ACME CA truly relies on the CSR for, allowing ACME Servers to ignore the CSR entirely if they so wished. It also has the added benefit of letting clients prove that they control the corresponding private key (by fulfilling an ACME Challenge for the pubkey identifier, e.g. by conducting a TLS handshake with that key), which the current CSR transmission mechanism does not do. I think that more initiatives can and should take this approach, and adding new identifier types is generally a good thing. Aaron On Wed, Jul 24, 2024 at 12:56 PM Mike Ounsworth mailto:40entrust@dmarc.ietf.org> > wrote: Awesome. Thanks for talking with Yaron Michael! Cross-posting to ACME. One quibble, “ACME uses CSRs.”; true; putting the attestation payload inside the CSR, and the CSR inside ACME is one way to do it (IMO it’s an excellent way to do it), but I also want to nod to Brandon’s draft-acme-device-attest which defines a new ACME challenge type “device-attest-01”, but that is unfortunately narrowly-defined to WebAuthn, so is not useful to P11 type devices that don’t feel like cramming themselves into a WebAuthn-shaped box. So we’re proposing that our solutions (draft-ounsworth-rats-pkix-evidence, draft-ietf-lamps-csr-attestation) describe the most general and flexible way of conveying evidence to a CA. pkix-evidence(draft-ounsworth-rats-pkix-evidence), inside of a CSR (draft-ietf-lamps-csr-attestation) inside of any CSR-carrying protocol (ACME, EST, CMC, usb-stick-out-of-airgapped-datacentre, email to your IT guy, CTRL+V to CA webpage, or any other protocol for transporting CSRs. Not to mention the whole suite of Microsoft proprietary cert enrollment protocols: WNES, WSTEP, and friends, which I believe also carry CSRs, so could benefit from this for free. I joke a bit, but in all seriousness, part of the answer to “Why not ACME?” is that especially for Enterprise and People PKIs, “USB stick, email, and CTRL+V” still represents a large bulk of how certs get issued. Of course our draft is not limited to certificate request usecases; it becomes another general attestation evidence payload format that could be used in attested-tls, attested-ike, attested-routers, whatever. --- Mike Ounsworth From: Michael Richardson mailto:m...@sandelman.ca> > Sent: Wednesday, July 24, 2024 2:26 PM To: Mike Ounsworth mailto:mike.ounswo...@entrust.com> > Cc: r...@ietf.org <mailto:r...@ietf.org> Subject: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft, Mike Ounsworth wrote: > The comments yesterday from Yaron of "Why not use ACME?", and from the > chairs "Does this belong in LAMPS", makes me think that we have not > explained the Mike Ounsworth mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org> > wrote: > The comments yesterday from Yaron of "Why not use ACME?", and from the > chairs "Does this belong in LAMPS", makes me think that we have not > explained the purpose of the draft very well. I spoke to Yaron afterward: and the key piece of information that was missing from the discussion are: a) ACME uses CSRs. b) the Evidence has to be within the CSR signature. c) the Evidence is *not* about th
[Acme] Re: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft,
Awesome. Thanks for talking with Yaron Michael! Cross-posting to ACME. One quibble, “ACME uses CSRs.”; true; putting the attestation payload inside the CSR, and the CSR inside ACME is one way to do it (IMO it’s an excellent way to do it), but I also want to nod to Brandon’s draft-acme-device-attest which defines a new ACME challenge type “device-attest-01”, but that is unfortunately narrowly-defined to WebAuthn, so is not useful to P11 type devices that don’t feel like cramming themselves into a WebAuthn-shaped box. So we’re proposing that our solutions (draft-ounsworth-rats-pkix-evidence, draft-ietf-lamps-csr-attestation) describe the most general and flexible way of conveying evidence to a CA. pkix-evidence(draft-ounsworth-rats-pkix-evidence), inside of a CSR (draft-ietf-lamps-csr-attestation) inside of any CSR-carrying protocol (ACME, EST, CMC, usb-stick-out-of-airgapped-datacentre, email to your IT guy, CTRL+V to CA webpage, or any other protocol for transporting CSRs. Not to mention the whole suite of Microsoft proprietary cert enrollment protocols: WNES, WSTEP, and friends, which I believe also carry CSRs, so could benefit from this for free. I joke a bit, but in all seriousness, part of the answer to “Why not ACME?” is that especially for Enterprise and People PKIs, “USB stick, email, and CTRL+V” still represents a large bulk of how certs get issued. Of course our draft is not limited to certificate request usecases; it becomes another general attestation evidence payload format that could be used in attested-tls, attested-ike, attested-routers, whatever. --- Mike Ounsworth From: Michael Richardson Sent: Wednesday, July 24, 2024 2:26 PM To: Mike Ounsworth Cc: r...@ietf.org Subject: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft, Mike Ounsworth wrote: > The comments yesterday from Yaron of "Why not use ACME?", and from the > chairs "Does this belong in LAMPS", makes me think that we have not > explained the Mike Ounsworth mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org> > wrote: > The comments yesterday from Yaron of "Why not use ACME?", and from the > chairs "Does this belong in LAMPS", makes me think that we have not > explained the purpose of the draft very well. I spoke to Yaron afterward: and the key piece of information that was missing from the discussion are: a) ACME uses CSRs. b) the Evidence has to be within the CSR signature. c) the Evidence is *not* about the posture of the system that will be using the key/certificate, but rather about the storage of the private key. > Table of contents of this email: > - Problem statement > - Why EAT doesn't work well for HSMs > - What this draft does > - New claims smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
Re: [Acme] [EXTERNAL] Re: acme-device-attest expired
<mailto:bweeks=40google@dmarc.ietf.org> @Brandon Weeks – I wonder if
acme-device-attest-01 could be broadened so that “attObj” is allowed to contain
evidence other than WebAuthn – ie make WebAuthn an example rather than
normative? I would suggest listing “EvidenceBundles” from
draft-ietf-lamps-csr-attestation, and RATS ConceptualMessageWrapper from
draft-ietf-rats-msg-wrap as other valid examples.
---
Mike Ounsworth
From: Mike Ounsworth
Sent: Friday, February 23, 2024 11:48 AM
To: Brandon Weeks ; Prachi Jain
Cc: Mike Malone ; Deb Cooley ; Thomas
Fossati ; acme@ietf.org;
draft-acme-device-attest.auth...@ietf.org
Subject: RE: [Acme] [EXTERNAL] Re: acme-device-attest expired
Here’s my 5-minute side-by-side of the two drafts.
draft-ietf-lamps-csr-attestation:
- whatever evidence blob your device can produce, stick it as an OCTET STRING
(or whatever other ASN.1 type) inside a new CSR attribute called id-aa-evidence.
- Any cert chains required to validate the evidence blob also go inside
id-aa-evidence.
- It’s the CA’s job to find a verifier that can parse whatever evidence data
you gave it.
- Was written under the full generality of the RATS Architecture.
draft-acme-device-attest:
- Defines new SANs for use in CSRs: “permanent-identifier” and
“hardware-module”.
- Defines a new ACME Challenge “device-attest-01”
- Expects the returned Evidence data to be in WebAuthn format.
"payload": base64url({
"attObj": base64url(/* WebAuthn attestation object */)
- Was written specifically for Android, Chrome, and TPM attestations in
WebAuthn format.
My first impression is that we should continue with both in parallel and not
try to combine them.
lamps-csr-attest is more general in that it applies to things that are not
WebAuthn, and will work anywhere that accepts CSRs.
acme-attest allows the client to send a cert req, and then the CA to decide
whether or not to challenge for an attestation. It also has invested
implementors.
---
Mike Ounsworth
From: Brandon Weeks mailto:bweeks=40google@dmarc.ietf.org> >
Sent: Thursday, February 22, 2024 4:25 PM
To: Prachi Jain mailto:prachi.jain1...@gmail.com> >
Cc: Mike Malone mailto:m...@smallstep.com> >; Mike
Ounsworth mailto:mike.ounswo...@entrust.com> >;
Deb Cooley mailto:debcool...@gmail.com> >; Thomas
Fossati mailto:tho.i...@gmail.com> >; acme@ietf.org
<mailto:acme@ietf.org> ; draft-acme-device-attest.auth...@ietf.org
<mailto:draft-acme-device-attest.auth...@ietf.org>
Subject: Re: [Acme] [EXTERNAL] Re: acme-device-attest expired
Apologies for letting the draft expire. I've recently switched roles within
Google and have been busy ramping up. My new team is responsible for Android
Key Attestation[0], one of the attestation schemes included in the draft, which
hopefully
Apologies for letting the draft expire. I've recently switched roles
within Google and have been busy ramping up. My new team is
responsible for Android Key Attestation[0], one of the attestation
schemes included in the draft, which hopefully allows me to build a
production implementation of the draft.
I've incorporated one change from Thomas and updated the draft to version 2[1].
There hasn’t been much feedback on the draft during the ACME sessions
or on the mailing list, especially from implementers, so I’m really
excited to see all of the interest on this thread. I’d be more than
happy to incorporate any feedback received and present at IETF 120. If
reviewing the draft in a meeting would be helpful, please reach out to
me directly and I’d be happy to schedule time.
Thanks,
Brandon
[0]
https://urldefense.com/v3/__https://developer.android.com/privacy-and-security/security-key-attestation__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem9PC1YNe$
<https://urldefense.com/v3/__https:/developer.android.com/privacy-and-security/security-key-attestation__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem9PC1YNe$>
[1]
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-acme-device-attest/02/__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem6-cnbGh$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-acme-device-attest/02/__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem6-cnbGh$>
On Thu, Feb 22, 2024 at 1:53 PM Prachi Jain mailto:prachi.jain1...@gmail.com> > wrote:
>
> I plan to do a POC using this draft and potentially implement it based on the
> results. Thus very motivated to get this past the finish line.
>
> @Mike Ounsworth, I haven't read draft-ietf-lamps-csr-attestation yet
Re: [Acme] [EXTERNAL] Re: acme-device-attest expired
Here’s my 5-minute side-by-side of the two drafts.
draft-ietf-lamps-csr-attestation:
- whatever evidence blob your device can produce, stick it as an OCTET STRING
(or whatever other ASN.1 type) inside a new CSR attribute called id-aa-evidence.
- Any cert chains required to validate the evidence blob also go inside
id-aa-evidence.
- It’s the CA’s job to find a verifier that can parse whatever evidence data
you gave it.
- Was written under the full generality of the RATS Architecture.
draft-acme-device-attest:
- Defines new SANs for use in CSRs: “permanent-identifier” and
“hardware-module”.
- Defines a new ACME Challenge “device-attest-01”
- Expects the returned Evidence data to be in WebAuthn format.
"payload": base64url({
"attObj": base64url(/* WebAuthn attestation object */)
- Was written specifically for Android, Chrome, and TPM attestations in
WebAuthn format.
My first impression is that we should continue with both in parallel and not
try to combine them.
lamps-csr-attest is more general in that it applies to things that are not
WebAuthn, and will work anywhere that accepts CSRs.
acme-attest allows the client to send a cert req, and then the CA to decide
whether or not to challenge for an attestation. It also has invested
implementors.
---
Mike Ounsworth
From: Brandon Weeks
Sent: Thursday, February 22, 2024 4:25 PM
To: Prachi Jain
Cc: Mike Malone ; Mike Ounsworth
; Deb Cooley ; Thomas Fossati
; acme@ietf.org; draft-acme-device-attest.auth...@ietf.org
Subject: Re: [Acme] [EXTERNAL] Re: acme-device-attest expired
Apologies for letting the draft expire. I've recently switched roles within
Google and have been busy ramping up. My new team is responsible for Android
Key Attestation[0], one of the attestation schemes included in the draft, which
hopefully
Apologies for letting the draft expire. I've recently switched roles
within Google and have been busy ramping up. My new team is
responsible for Android Key Attestation[0], one of the attestation
schemes included in the draft, which hopefully allows me to build a
production implementation of the draft.
I've incorporated one change from Thomas and updated the draft to version 2[1].
There hasn’t been much feedback on the draft during the ACME sessions
or on the mailing list, especially from implementers, so I’m really
excited to see all of the interest on this thread. I’d be more than
happy to incorporate any feedback received and present at IETF 120. If
reviewing the draft in a meeting would be helpful, please reach out to
me directly and I’d be happy to schedule time.
Thanks,
Brandon
[0]
https://urldefense.com/v3/__https://developer.android.com/privacy-and-security/security-key-attestation__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem9PC1YNe$
<https://urldefense.com/v3/__https:/developer.android.com/privacy-and-security/security-key-attestation__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem9PC1YNe$>
[1]
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-acme-device-attest/02/__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem6-cnbGh$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-acme-device-attest/02/__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem6-cnbGh$>
On Thu, Feb 22, 2024 at 1:53 PM Prachi Jain mailto:prachi.jain1...@gmail.com> > wrote:
>
> I plan to do a POC using this draft and potentially implement it based on the
> results. Thus very motivated to get this past the finish line.
>
> @Mike Ounsworth, I haven't read draft-ietf-lamps-csr-attestation yet so I am
> going to give it a read and come back with my thoughts.
>
> On Thu, Feb 22, 2024 at 3:00 PM Mike Malone <mailto:m...@smallstep.com> > wrote:
>>
>> It's worth noting that Apple has already implemented this draft on macOS,
>> iOS, iPadOS, and tvOS[1]. We've implemented the server side at Smallstep and
>> can confirm that there is adoption. That shouldn't stop the evolution of
>> this draft, of course, but could help inform it. Adoption is promising and
>> it would be unfortunate to see this die at draft.
>>
>> We don't have any experienced IETF authors here -- not sure what that
>> entails -- but we are very interested in the outcome here and would be happy
>> to help however we can. To start, I've shared this with a few contacts that
>> I know will also be interested.
>>
>> Mike
>>
>> [1]
>> https://urldefense.com/v3/__https://support.apple.com/lt-lt/guide/deployment/dep28afb
Re: [Acme] [EXTERNAL] Re: acme-device-attest expired
At the risk of adding another draft to my plate, I am the lead author on draft-ietf-lamps-csr-attestation, so I suppose it is reasonable for me to volunteer to work on this one also. I wonder if the design of acme-device-attest should change in light of the existence of draft-ietf-lamps-csr-attestation? But I admit to not having read acme-device-attest in a while :/ --- Mike Ounsworth From: Acme On Behalf Of Prachi Jain Sent: Thursday, February 22, 2024 6:03 AM To: Deb Cooley Cc: Thomas Fossati ; acme@ietf.org; draft-acme-device-attest.auth...@ietf.org Subject: [EXTERNAL] Re: [Acme] acme-device-attest expired Thank you for the update, Deb. I am more than willing to work as an author on this draft and help out :) On Thu, Feb 22, 2024 at 5: 28 AM Deb Cooley wrote: I know Brandon has been busy, but I don't know his plans Thank you for the update, Deb. I am more than willing to work as an author on this draft and help out :) On Thu, Feb 22, 2024 at 5:28 AM Deb Cooley mailto:debcool...@gmail.com> > wrote: I know Brandon has been busy, but I don't know his plans for this draft. Maybe his use case has changed? I've cc'd him on this message. Note: acme is a 'working group', to get a draft through the process people have to be willing to work on the draft (vice merely following). Also drafts can certainly have multiple authors, perhaps an offer of helping as an author might work. Deb On Tue, Feb 20, 2024 at 11:01 AM Prachi Jain mailto:prachi.jain1...@gmail.com> > wrote: Hello, I have been closely following this document as well and would like to know the status of the same. Thanks, Prachi On Sun, Feb 18, 2024 at 1:57 AM Thomas Fossati mailto:tho.i...@gmail.com> > wrote: Hi, all, The acme-device-attest draft is expired. Just checking: what are the plans? cheers, thanks! ___ 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!ZpiFHiNqjoIYpSwf-NWcpF4npfhv0fs0h1DfNQ82nrL17Uiy4d4RIWH4gGVLXQyjT68S1PkaY3m248MMkAE2Gdu_c1MH60I$> ___ 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!ZpiFHiNqjoIYpSwf-NWcpF4npfhv0fs0h1DfNQ82nrL17Uiy4d4RIWH4gGVLXQyjT68S1PkaY3m248MMkAE2Gdu_c1MH60I$> smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Starting a design team for draft-vanbrouwershaven-acme-auto-discovery
Hey ACME! We are following up on the discussion related to draft-vanbrouwershaven-acme-auto-discovery. Before doing a call-for-adoption, Deb asked us to form a design team to resolve the open design questions. Anyone who is interested in participating in this design group, please reply to this email, or to Paul or I directly. Agenda for first design team meeting: 1. Security Considerations review of the current draft; particularly when the ACME account initiating the request is owned by a cloud service provider and is shared across multiple subscribers. Would a DV-based mechanism to authorize that the ACME account has control over the domain be sufficient to meet the security goals of this auto-discovery draft? See: https://github.com/vanbroup/acme-auto-discovery/issues/18 2. Review of open github issues. See https://github.com/vanbroup/acme-auto-discovery/issues Mike Ounsworth mike.ounswo...@entrust.com <mailto:mike.ounswo...@entrust.com> Paul van Brouwershaven paul.vanbrouwersha...@entrust.com <mailto:paul.vanbrouwersha...@entrust.com> - - - Mike Ounsworth Software Security Architect (pronouns: he/him) smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] [EXTERNAL] ACME minutes for IETF 118
Thanks; the notes for my talk look good. --- Mike Ounsworth From: Acme On Behalf Of Deb Cooley Sent: Thursday, November 9, 2023 9:41 AM To: IETF ACME Cc: Subject: [EXTERNAL] [Acme] ACME minutes for IETF 118 These are posted here: https: //datatracker. ietf. org/doc/minutes-118-acme-202311081200/ If you have comments/proposed changes, please reply here, or to the chairs. Deb Cooley These are posted here: https://datatracker.ietf.org/doc/minutes-118-acme-202311081200/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/minutes-118-acme-202311081200/__;!!FJ-Y8qCqXTj2!e36seXneDCndlk4M0HidEG2BToUR3kpZB2t8Vy719siAQg77JxWj_3UNrrGmMkPaPD_Ts9kMP7SqEzgBF7_Kkddi$> If you have comments/proposed changes, please reply here, or to the chairs. Deb Cooley 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
Re: [Acme] [EXTERNAL] agenda items for IETF 118 and important dates
Hi Deb, We have just pushed draft-vanbrouwershaven-acme-auto-discovery-02: we have just pushed a -02 [1]. Since 117 there have been some great offline discussions making progress on the technical issues, so we can give a short presentation to update the community. The main technical issue we’re working through is “account disambiguation”; consider a large enterprise subscriber that has multiple departments which are all authorized to issue for *.company.com, but let’s say that only DepartmentA is authorized to issue S/MIME, and only DepartmentB is authorized to issue EV. The acme-auto-discovery mechanism will result in an issuance request from the ACME protocol account controlled by the cloud provider, so we need a robust way to tie that back to the pre-existing substcriber Org/Department account in the CA. This is turning out to be tricky, but we’ll be happy to present progress at 118. [1]: https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/ --- Mike Ounsworth From: Acme On Behalf Of Deb Cooley Sent: Monday, October 9, 2023 9:22 AM To: IETF ACME Cc: acme-...@ietf.org; Subject: [EXTERNAL] [Acme] agenda items for IETF 118 and important dates All, The preliminary agenda has acme scheduled to meet on Wednesday from 1300-1400 (Prague time). The agenda will be final on Friday (13 Oct). If you would like to present during that time slot, please contact the chairs ( acme-chairs@ ietf. org All, The preliminary agenda has acme scheduled to meet on Wednesday from 1300-1400 (Prague time). The agenda will be final on Friday (13 Oct). If you would like to present during that time slot, please contact the chairs ( acme-cha...@ietf.org <mailto:acme-cha...@ietf.org> ). Also the Internet Draft submission cut-off is 23 Oct 2023 midnight (UTC), so if you want your draft updated prior to the workshop, now is the time. Obviously new work falls into this timeline as well. A couple of notes: 1. draft-ietf-acme-dtnnodeid-11 - the chairs will coordinate w/ the AD. mea culpa. 2. draft-vanbrouwershaven-acme-auto-discovery-01 - we would like to see this draft updated before the call for adoption. Deb (and Yoav) acme chairs 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
Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
At 117, I spoke with Phillip Hallam-Baker (the IANA Designated Expert for the CAA registry) and he’s ok with creating whatever registries for whatever parameters we need to make this work. --- Mike Ounsworth From: Q Misell Sent: Tuesday, August 22, 2023 10:12 AM To: Paul van Brouwershaven Cc: Fraser Tweedale ; Richard Barnes ; Mike Ounsworth ; acme@ietf.org Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt I think another RFC defining the existence of this registry would be the best approach. Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 I think another RFC defining the existence of this registry would be the best approach. 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://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCAgWB5sva$>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCApQFJXKj$>. 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 № UK3718474 and № UK3718468, respectively. On Fri, 18 Aug 2023 at 17:13, Paul van Brouwershaven mailto:40entrust@dmarc.ietf.org>> wrote: Hi Fraser, I have not replied to this part of your message: > Regarding registration of CAA attributes (IANA considerations): they need to > be registered in the "Certification Authority Restriction Properties" > registry: > https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties<https://urldefense.com/v3/__https:/www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml*caa-properties__;Iw!!FJ-Y8qCqXTj2!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCAgEezh8x$> In the draft we are defining a parameter and not a property, I don't think there is a registry for parameters as these can be CA specific. However, I think it could be valuable to define a registry as we know have multiple documents (such as RFC 8657) defining parameters, but I'm not sure how we would initiate that. Paul 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<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCAv69t6Kl$> ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] [EXTERNAL] Re: ACME PoP on revocation requests
Oh interesting. Thanks for explaining! So a CA could satisfy the CA/B BRs by only accepting /revoke-cert reqs signed by the subject key, but the Mozilla Root Store Policy requires you to also support them signed by the ACME account key, and have different processing logic. Interesting. Thanks for the discussion! --- Mike Ounsworth From: Aaron Gable Sent: Wednesday, August 16, 2023 3:04 PM To: Mike Ounsworth Cc: Tim Hollebeek ; Seo Suchan ; Russ Housley ; IETF ACME Subject: [EXTERNAL] Re: ACME PoP on revocation requests The Mozilla Root Store Policy requires[1] that certificates be revoked with reason keyCompromise if "the certificate subscriber requests that the CA operator revoke the certificate for this reason". However, those requirements are The Mozilla Root Store Policy requires[1] that certificates be revoked with reason keyCompromise if "the certificate subscriber requests that the CA operator revoke the certificate for this reason". However, those requirements are also clear that doing so does not constitute *demonstrating* key compromise, and therefore none of the other key compromise steps (revoking certs that share the same key, blocklisting the key to prevent future issuance) need to be taken unless the subscriber has also proven possession of the key: "The scope of revocation depends on whether the certificate subscriber has proven possession of the private key of the certificate". [1]: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#611-end-entity-tls-certificate-crlrevocation-reasons<https://urldefense.com/v3/__https:/www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/*611-end-entity-tls-certificate-crlrevocation-reasons__;Iw!!FJ-Y8qCqXTj2!eX6Zyv8AcDki2Y6L00kBFs7KXQdQKwq4l23lfVuaHIRgAkki8_bQd_ZGvo2ZyXNVj0enFHS2tIdEFixqFQpZnVU$> Aaron On Wed, Aug 16, 2023 at 11:03 AM Mike Ounsworth mailto:mike.ounswo...@entrust.com>> wrote: I guess revocation tickets / nonces / commitment values are meant to address that problem. --- Mike Ounsworth From: Tim Hollebeek mailto:tim.holleb...@digicert.com>> Sent: Wednesday, August 16, 2023 12:59 PM To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; Aaron Gable mailto:aa...@letsencrypt.org>> Cc: Seo Suchan mailto:tjtn...@gmail.com>>; Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME mailto:acme@ietf.org>> Subject: [EXTERNAL] RE: ACME PoP on revocation requests As an aside, I’ll also note that an embarrassingly large number of people zero out compromised keys immediately upon finding out they are compromised (presumably to prevent them from continuing to be used), but then find themselves in a pickle As an aside, I’ll also note that an embarrassingly large number of people zero out compromised keys immediately upon finding out they are compromised (presumably to prevent them from continuing to be used), but then find themselves in a pickle when asked to prove they have/had the key. If you find yourself in that situation, please archive the compromised keys. You might need them. -Tim From: Mike Ounsworth mailto:mike.ounswo...@entrust.com>> Sent: Wednesday, August 16, 2023 1:01 PM To: Aaron Gable mailto:aa...@letsencrypt.org>> Cc: Seo Suchan mailto:tjtn...@gmail.com>>; Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME mailto:acme@ietf.org>> Subject: RE: ACME PoP on revocation requests (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 mailto:aa...@letsencrypt.org>> Sent: Wednesday, August 16, 2023 11:47 AM To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>> Cc: Seo Suchan mailto:tjtn...@gmail.com>>; Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME mailto:acme@ietf.org>> Subject: Re: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME
Re: [Acme] ACME PoP on revocation requests
I guess revocation tickets / nonces / commitment values are meant to address that problem. --- Mike Ounsworth From: Tim Hollebeek Sent: Wednesday, August 16, 2023 12:59 PM To: Mike Ounsworth ; Aaron Gable Cc: Seo Suchan ; Russ Housley ; IETF ACME Subject: [EXTERNAL] RE: ACME PoP on revocation requests As an aside, I’ll also note that an embarrassingly large number of people zero out compromised keys immediately upon finding out they are compromised (presumably to prevent them from continuing to be used), but then find themselves in a pickle As an aside, I’ll also note that an embarrassingly large number of people zero out compromised keys immediately upon finding out they are compromised (presumably to prevent them from continuing to be used), but then find themselves in a pickle when asked to prove they have/had the key. If you find yourself in that situation, please archive the compromised keys. You might need them. -Tim From: Mike Ounsworth mailto:mike.ounswo...@entrust.com>> Sent: Wednesday, August 16, 2023 1:01 PM To: Aaron Gable mailto:aa...@letsencrypt.org>> Cc: Seo Suchan mailto:tjtn...@gmail.com>>; Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME mailto:acme@ietf.org>> Subject: RE: ACME PoP on revocation requests (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 mailto:aa...@letsencrypt.org>> Sent: Wednesday, August 16, 2023 11:47 AM To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>> Cc: Seo Suchan mailto:tjtn...@gmail.com>>; Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME mailto: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 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?
Re: [Acme] ACME PoP on revocation requests
(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 Sent: Wednesday, August 16, 2023 11:47 AM To: Mike Ounsworth Cc: Seo Suchan ; Tim Hollebeek ; Russ Housley ; IETF ACME 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 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 mailto:tjtn...@gmail.com>> Sent: Wednesday, August 16, 2023 9:06 AM To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Aaron Gable mailto:aa...@letsencrypt.org>> Cc: Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME 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 작성함: 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 mailto:mike.ounswo...@entrust.com>> 작성함: Are you suggesting to sign
Re: [Acme] [EXTERNAL] Re: Internet-Draft: PQC Algorithm negotiation in ACME
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’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’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 Sent: Wednesday, August 16, 2023 9:06 AM To: Mike Ounsworth ; Tim Hollebeek ; Aaron Gable Cc: Russ Housley ; IETF ACME 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 작성함: 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 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 mailto:acme-boun...@ietf.org>> On Behalf Of Seo Suchan Sent: Wednesday, August 16, 2023 8:41 AM To: Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Aaron Gable mailto:aa...@letsencrypt.org>> Cc: Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME 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 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 mailto:aa...@letsencrypt.org>> Sent: Tuesday, August 15, 2023 2:16 PM To: Seo Suchan mailto:tjtn...@gmail.com>> Cc: Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME 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 Base
Re: [Acme] [EXTERNAL] Re: Internet-Draft: PQC Algorithm negotiation in ACME
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 On Behalf Of Seo Suchan Sent: Wednesday, August 16, 2023 8:41 AM To: Tim Hollebeek ; Aaron Gable Cc: Russ Housley ; IETF ACME 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 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 mailto:aa...@letsencrypt.org>> Sent: Tuesday, August 15, 2023 2:16 PM To: Seo Suchan mailto:tjtn...@gmail.com>> Cc: Tim Hollebeek mailto:tim.holleb...@digicert.com>>; Russ Housley mailto:hous...@vigilsec.com>>; IETF ACME 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 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 mailto:40digicert@dmarc.ietf.org>> wrote:
Re: [Acme] [EXTERNAL] Re: Internet-Draft: PQC Algorithm negotiation in ACME
Well that’s true, but public CAs do sell S/MIME certs to the public; consider for example the whole thing about issuing S/MIME certs over ACME. --- Mike Ounsworth From: Russ Housley Sent: Thursday, August 10, 2023 3:49 PM To: Mike Ounsworth Cc: Tim Hollebeek ; Aaron Gable ; Seo Suchan ; Alexandre Augusto ; IETF ACME ; Lucas Pandolfo Perin ; Ricardo Custódio ; victor.va...@grad.ufsc.br Subject: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME Mike: Enterprises that do face-to-face enrollment and issue a token that contains a signature certificate and a key management certificate do not need a PoP protocol for the key management private key. Russ On Aug 8, 2023, at 6: 38 PM, Mike Mike: Enterprises that do face-to-face enrollment and issue a token that contains a signature certificate and a key management certificate do not need a PoP protocol for the key management private key. Russ On Aug 8, 2023, at 6:38 PM, Mike Ounsworth mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org>> wrote: This draft raises an interesting side-question: do we actually need ACME for KEM certs? If so, for which use-cases? The flippant answer is “We never needed to support ECDH PoP, so why do we need to support KEM PoP?”. I think for TLS certs, ACME needs to support KEM certs if-and-only-if draft-celi-wiggers-tls-authkem gets adopted by the TLS WG. For S/MIME we clearly need to support KEM certs, which I assume would fall under RFC8823 which says “just do a CSR for your encryption-only key” – although I notice that 8823 does not tell me how I’m supposed to sign my “encryption-only CSR”. I would bet $50, or a beverage of your choice in Prague, that there exist almost no S/MIME clients or CAs that support ECDH certs, so in practice we just cheat and sign the CSR with the RSA encryption key. If that’s true that S/MIME just entirely skipped over ECDH as a technology, then we may actually have a novel problem to solve here in the form of “How do you do a CSR for a key that can’t sign?”. --- Mike Ounsworth Software Security Architect, Entrust From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of Tim Hollebeek Sent: Tuesday, August 8, 2023 1:54 PM To: Aaron Gable mailto:aaron=40letsencrypt@dmarc.ietf.org>>; Seo Suchan mailto:tjtn...@gmail.com>> Cc: Alexandre Augusto mailto:alexandre.a.gi...@gmail.com>>; acme@ietf.org<mailto:acme@ietf.org>; Lucas Pandolfo Perin mailto:lucas.pe...@tii.ae>>; Ricardo Custódio mailto:ricardo.custo...@ufsc.br>>; victor.va...@grad.ufsc.br<mailto:victor.va...@grad.ufsc.br> Subject: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME I agree that generic support for profile selection and migration between protocols is superior. PQC isn’t actually particularly special or relevant to ACME, and we should avoid putting PQC-specific stuff into protocols that don’t need it, because I agree that generic support for profile selection and migration between protocols is superior. PQC isn’t actually particularly special or relevant to ACME, and we should avoid putting PQC-specific stuff into protocols that don’t need it, because we’ll be maintaining some of these protocols far into the future, when we might be more worried about the transition to Imperial Galactic Standard Certificates instead of PQC. -Tim From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of Aaron Gable Sent: Tuesday, August 8, 2023 12:44 PM To: Seo Suchan mailto:tjtn...@gmail.com>> Cc: Alexandre Augusto mailto:alexandre.a.gi...@gmail.com>>; acme@ietf.org<mailto:acme@ietf.org>; Lucas Pandolfo Perin mailto:lucas.pe...@tii.ae>>; Ricardo Custódio mailto:ricardo.custo...@ufsc.br>>; victor.va...@grad.ufsc.br<mailto:victor.va...@grad.ufsc.br> Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME I concur with what the others have said here. My overarching concern is that this draft seems too PQC-specific: the general capabilities it describes are useful outside the context of PQC, and the general ideas herein should be standardized in a more flexible manner. The issue of confirmation of control of the private key is a non-issue that does not need to be addressed by this document. The ACME protocol as it stands (not to mention most other non-standardized issuance protocols) does not prove that the Applicant controls the private key corresponding to the public key they request to have in their certificate. Presentation of a signed CSR does not prove control of the corresponding private key, as CSRs are public information and anyone can present any CSR they find lying around the web. I think it's a good idea for the ACME protocol to have a mechanism to prove control of the cert private key, probably by having the CSR contain an additional high-entropy field which is provided by the CA in the new-order response. But this is
Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME
This draft raises an interesting side-question: do we actually need ACME for KEM certs? If so, for which use-cases? The flippant answer is “We never needed to support ECDH PoP, so why do we need to support KEM PoP?”. I think for TLS certs, ACME needs to support KEM certs if-and-only-if draft-celi-wiggers-tls-authkem gets adopted by the TLS WG. For S/MIME we clearly need to support KEM certs, which I assume would fall under RFC8823 which says “just do a CSR for your encryption-only key” – although I notice that 8823 does not tell me how I’m supposed to sign my “encryption-only CSR”. I would bet $50, or a beverage of your choice in Prague, that there exist almost no S/MIME clients or CAs that support ECDH certs, so in practice we just cheat and sign the CSR with the RSA encryption key. If that’s true that S/MIME just entirely skipped over ECDH as a technology, then we may actually have a novel problem to solve here in the form of “How do you do a CSR for a key that can’t sign?”. --- Mike Ounsworth Software Security Architect, Entrust From: Acme On Behalf Of Tim Hollebeek Sent: Tuesday, August 8, 2023 1:54 PM To: Aaron Gable ; Seo Suchan Cc: Alexandre Augusto ; acme@ietf.org; Lucas Pandolfo Perin ; Ricardo Custódio ; victor.va...@grad.ufsc.br Subject: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME I agree that generic support for profile selection and migration between protocols is superior. PQC isn’t actually particularly special or relevant to ACME, and we should avoid putting PQC-specific stuff into protocols that don’t need it, because I agree that generic support for profile selection and migration between protocols is superior. PQC isn’t actually particularly special or relevant to ACME, and we should avoid putting PQC-specific stuff into protocols that don’t need it, because we’ll be maintaining some of these protocols far into the future, when we might be more worried about the transition to Imperial Galactic Standard Certificates instead of PQC. -Tim From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of Aaron Gable Sent: Tuesday, August 8, 2023 12:44 PM To: Seo Suchan mailto:tjtn...@gmail.com>> Cc: Alexandre Augusto mailto:alexandre.a.gi...@gmail.com>>; acme@ietf.org<mailto:acme@ietf.org>; Lucas Pandolfo Perin mailto:lucas.pe...@tii.ae>>; Ricardo Custódio mailto:ricardo.custo...@ufsc.br>>; victor.va...@grad.ufsc.br<mailto:victor.va...@grad.ufsc.br> Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME I concur with what the others have said here. My overarching concern is that this draft seems too PQC-specific: the general capabilities it describes are useful outside the context of PQC, and the general ideas herein should be standardized in a more flexible manner. The issue of confirmation of control of the private key is a non-issue that does not need to be addressed by this document. The ACME protocol as it stands (not to mention most other non-standardized issuance protocols) does not prove that the Applicant controls the private key corresponding to the public key they request to have in their certificate. Presentation of a signed CSR does not prove control of the corresponding private key, as CSRs are public information and anyone can present any CSR they find lying around the web. I think it's a good idea for the ACME protocol to have a mechanism to prove control of the cert private key, probably by having the CSR contain an additional high-entropy field which is provided by the CA in the new-order response. But this is generalizable to all certs, not just KEM certs. Similarly, this idea of algorithm negotiation feels far too specific. What ACME needs is not PQC algorithm selection, but generic profile selection. A CA should be able to advertise various profiles (e.g. signature algorithms, EKUs, validity periods, etc) in the Directory object, and the client should be able to select a profile via one or more fields in the new-order request. Again, I think an approach like this covers the use-cases supposed by this draft, but generalizes much wider than just PQC algorithm selection. Aaron On Sun, Aug 6, 2023 at 6:39 AM Seo Suchan mailto:tjtn...@gmail.com>> wrote: thoughs in no particular order: 1. I don't think section 3's 1RTT mode works. CA already signed the certificate if it can give out encrypted version of it, then client can get certificate from CT log. 2. is there a reason to include just PQC algos on list of supported algorithm endpoint? I think there is no reason to not include classical algorithms there, as those have parameters CA may refuse (rsa keysize, ecdsa curves) 3. LE doesn't consider CSR as proof of possession of private key (so you need sign revoke request with certs privkey to use reason key compromise), and TLS CA/B BR doesn't actually require to check it. 2023-08-06 오후 8:00에 Alexandre
Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
Thanks Deb. I’ll be presenting. The discussion on-list was pretty comprehensive; I can give a blitz overview in 10 mins or less. --- Mike Ounsworth From: Acme On Behalf Of Deb Cooley Sent: Thursday, July 20, 2023 5:38 AM To: Mike Ounsworth ; IETF ACME Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt Apologies for missing this ask. Indeed I can add you to the agenda. Who is briefing and how long do you think you need? Deb On Tue, Jul 18, 2023 at 7:54 PM Mike Ounsworth mailto:40entrust@dmarc.ietf.org>> wrote: @chairs since the agenda doesn't look particularly full, and we asked before the cutoff, could we get this on the agenda please? --- Mike Ounsworth -Original Message- From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of Mike Ounsworth Sent: Thursday, July 6, 2023 9:54 AM To: acme@ietf.org<mailto:acme@ietf.org> Cc: Paul van Brouwershaven mailto:paul.vanbrouwersha...@entrust.com>> Subject: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt Hi ACME! This is new business that we would like to add to the agenda for 117. Thanks, --- Mike Ounsworth & Paul van Brouwershaven -Original Message- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> mailto:internet-dra...@ietf.org>> Sent: Thursday, July 6, 2023 9:39 AM To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; Paul van Brouwershaven mailto:paul.vanbrouwersha...@entrust.com>> Subject: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. __ A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt has been successfully submitted by Paul van Brouwershaven and posted to the IETF repository. Name: draft-vanbrouwershaven-acme-auto-discovery Revision: 00 Title: Auto-discovery mechanism for ACME client configuration Document date: 2023-07-06 Group: Individual Submission Pages: 16 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3yeoTcrC$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3yeoTcrC$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39B9nSJz$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39B9nSJz$> Html: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3-CaBB-W$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3-CaBB-W$> Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH37daXF_h$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH37daXF_h$> Abstract: A significant impediment to the widespread adoption of the Automated Certificate Management Environment (ACME) [RFC8555] is that ACME clients need to be pre-configured with the URL of the ACME server to be used. This often leaves domain owners at the mercy of their hosting provider as to which Certification Authorities (CAs) can be used. This specification provides a mechanism to bootstrap ACME client configuration from a domain's DNS CAA Resource Record [RFC8659], thus giving control of which CA(s) to use back to the domain owner. Specifically, this document specifies two new extensions to the DNS CAA Resource Record: the "discovery" and "priority" parameters. Additionally, it registers the
Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
Personally, I like the way “no priority” is currently handled in 3.1.2: “In the case that this parameter is not specified, the entry will be considered to have a lower priority than all entries which specify any priority.” Thinking out loud here: @Tim Hollebeek<mailto:tim.hollebeek=40digicert@dmarc.ietf.org> how do you feel about treating multiple entries of the same priority as random-round-robin? The justification is that it enables load-balancing. But it’s also a source of complexity and I’m curious if it feels “necessary” to you. It could instead be left to the discretion of the implementer of the ACME client and we could say “for example selected randomly, or in the order they appear in the DNS record”. --- Mike Ounsworth From: Acme On Behalf Of Tim Hollebeek Sent: Wednesday, July 12, 2023 3:03 PM To: Seo Suchan ; acme@ietf.org Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt The problem with inverting things like that is that the highest priority is important, and so identifying a value that corresponds to the highest priority (like 1) is very useful. Having an explicit value for the lowest priority is very low priority. If you use zero for the lowest priority, then the highest priority value is a very inconvenient number (MAXINT or similar). I agree with Rich Salz: priorities are positive integers, and 1 is the highest. That’s a pretty standard way of expressing priorities. Anything beyond that is an unnecessary complication. -Tim From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of Seo Suchan Sent: Wednesday, July 12, 2023 3:29 PM To: acme@ietf.org<mailto:acme@ietf.org> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt I think make priority descending order removes such headache: default is 0 and so it has lowest priority than any other integer, make no reason to treat 0 exceptionally. 2023-07-13 오전 3:34에 Paul van Brouwershaven 이(가) 쓴 글: I have to agree that 0 is not a positive integer and reverted the prior change: > In the case that this parameter is not specified or contains the value "0", > the entry will be considered to have a lower priority than all entries which > specify any priority. So, setting "0" would invalidate the parameter, causing the ACME client to ignore the CAA record all together. Does this also make sense to you Q? From: Tim Hollebeek <mailto:tim.hollebeek=40digicert@dmarc.ietf.org> Sent: Wednesday, July 12, 2023 19:32 To: Paul van Brouwershaven <mailto:paul.vanbrouwersha...@entrust.com>; Q Misell <mailto:q...@as207960.net> Cc: acme@ietf.org<mailto:acme@ietf.org> <mailto:acme@ietf.org> Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt If priority is defined as a positive integer (which makes sense to me), then zero is an error, yes. If it’s desirable to have a “no priority” value, then zero might be a reasonable choice for such a value. But it’s hard to reason about whether “no priority” is higher or lower than items that do have priorities, so I think “no priority” adds additional complexity that should not be added unnecessarily. I think it’s simpler to stick to a single, ordered list of priority numbers, and ordinal numbers (a.k.a positive integers) are the best way to express that. -Tim From: Paul van Brouwershaven <mailto:Paul.vanBrouwershaven=40entrust@dmarc.ietf.org> Sent: Wednesday, July 12, 2023 1:01 PM To: Tim Hollebeek <mailto:tim.holleb...@digicert.com>; Q Misell <mailto:q...@as207960.net> Cc: acme@ietf.org<mailto:acme@ietf.org> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt > Anyone who argues that zero is a positive integer should be referred to the > standard math textbook of positive. Zero is a non-negative integer, but I’m > not aware of any definition of “positive” that makes it a positive integer. Do you argue that "0" should be threatened as an error instead of equal to no priority? From: Tim Hollebeek mailto:tim.hollebeek=40digicert@dmarc.ietf.org>> Sent: Wednesday, July 12, 2023 6:43:21 PM To: Paul van Brouwershaven mailto:paul.vanbrouwersha...@entrust.com>>; Q Misell mailto:q...@as207960.net>> Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>> Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt Anyone who argues that zero is a positive integer should be referred to the standard math textbook of positive. Zero is a non-negative integer, but I’m not aware of any definition of “positive” that makes it a p
[Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
@chairs since the agenda doesn't look particularly full, and we asked before the cutoff, could we get this on the agenda please? --- Mike Ounsworth -Original Message- From: Acme On Behalf Of Mike Ounsworth Sent: Thursday, July 6, 2023 9:54 AM To: acme@ietf.org Cc: Paul van Brouwershaven Subject: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt Hi ACME! This is new business that we would like to add to the agenda for 117. Thanks, --- Mike Ounsworth & Paul van Brouwershaven -Original Message- From: internet-dra...@ietf.org Sent: Thursday, July 6, 2023 9:39 AM To: Mike Ounsworth ; Paul van Brouwershaven Subject: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. __ A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt has been successfully submitted by Paul van Brouwershaven and posted to the IETF repository. Name: draft-vanbrouwershaven-acme-auto-discovery Revision: 00 Title: Auto-discovery mechanism for ACME client configuration Document date: 2023-07-06 Group: Individual Submission Pages: 16 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3yeoTcrC$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39B9nSJz$ Html: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3-CaBB-W$ Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH37daXF_h$ Abstract: A significant impediment to the widespread adoption of the Automated Certificate Management Environment (ACME) [RFC8555] is that ACME clients need to be pre-configured with the URL of the ACME server to be used. This often leaves domain owners at the mercy of their hosting provider as to which Certification Authorities (CAs) can be used. This specification provides a mechanism to bootstrap ACME client configuration from a domain's DNS CAA Resource Record [RFC8659], thus giving control of which CA(s) to use back to the domain owner. Specifically, this document specifies two new extensions to the DNS CAA Resource Record: the "discovery" and "priority" parameters. Additionally, it registers the URI "/.well-known/acme" at which all compliant ACME servers will host their ACME directory object. By retrieving instructions for the ACME client from the authorized CA(s), this mechanism allows for the domain owner to configure multiple CAs in either load-balanced or fallback prioritizations which improves user preferences and increases diversity in certificate issuers. The IETF Secretariat 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39SGJXVL$ ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
Thanks for the comments Fraser. Guilty as charged -- we were not thinking about private enterprise environments when we wrote it; we were thinking about publicly-reachable servers on public clouds getting certs from public CAs. In that context, the quote from the abstract "at the mercy of their hosting provider as to which Certification Authorities (CAs) can be used" is less about the ACME server being reachable in a network sense, and more about public hosting providers -- quite reasonably -- not wanting to maintain a dropdown menu of every ACME server on the internet. Typically if you want to use a CA other than the single one that your hosting provider knows how to ACME to, then your only option is to manually upload a PEM file. Yuck. The other assumption here is that this draft is really for domain owners who care enough about where their certs come from to have a "favourite CA" because people who don't care will be happy to use whatever default ACME server. That said, it's interesting to think about how this could apply to your enterprise problem of "find me /some/ ACME server that I can reach/use in this network zone". Assuming a private network with multiple DNS zones, you could configure your private DNS to slap on a constant CAA record across a DNS zone, and that gives you your "give me an ACME server, any one will do", right? Out of curiosity, what happened to draft-tweedale-acme-discovery? Did it just not have enough momentum to proceed? Searching on the ACME list archive did not turn up very much discussion. --- Mike Ounsworth -Original Message- From: Fraser Tweedale Sent: Thursday, July 6, 2023 7:40 PM To: Paul van Brouwershaven Cc: Richard Barnes ; Mike Ounsworth ; acme@ietf.org Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt On Fri, Jul 07, 2023 at 10:06:15AM +1000, Fraser Tweedale wrote: > - The main problem solved in my draft was: "in this /network > environment/, what ACME servers can/should I use?" The CAA-based > proposal answers a different question: "for this /domain/, what > ACME server should I use?" But (a) why would a domain owner need > to control this, and (b) it doesn't actually solve the problem > stated in the abstract: > > > This often leaves domain owners at the mercy of their hosting > > provider as to which Certification Authorities (CAs) can be used. > > The hosting provider can still control which ACME servers can be > reached, regardless of the preferences expressed via CAA records. > With respect to (a) - never mind. I thought about it some more and the answer is obvious. Where a CA authorization (i.e. restriction) exists in the form of a CAA record, it is useful to be able to direct a client to the authorized issuer(s) for the affected domain(s). I see that your draft solves a real problem. But it does not help much in enterprise environments, where the question is often "find me /some/ ACME server that I can reach/use, or which the administrators prefer". Two different problems, two complementary approaches. Thanks, Fraser 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
[Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
Hi ACME! This is new business that we would like to add to the agenda for 117. Thanks, --- Mike Ounsworth & Paul van Brouwershaven -Original Message- From: internet-dra...@ietf.org Sent: Thursday, July 6, 2023 9:39 AM To: Mike Ounsworth ; Paul van Brouwershaven Subject: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. __ A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt has been successfully submitted by Paul van Brouwershaven and posted to the IETF repository. Name: draft-vanbrouwershaven-acme-auto-discovery Revision: 00 Title: Auto-discovery mechanism for ACME client configuration Document date: 2023-07-06 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt Status: https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/ Html: https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery Abstract: A significant impediment to the widespread adoption of the Automated Certificate Management Environment (ACME) [RFC8555] is that ACME clients need to be pre-configured with the URL of the ACME server to be used. This often leaves domain owners at the mercy of their hosting provider as to which Certification Authorities (CAs) can be used. This specification provides a mechanism to bootstrap ACME client configuration from a domain's DNS CAA Resource Record [RFC8659], thus giving control of which CA(s) to use back to the domain owner. Specifically, this document specifies two new extensions to the DNS CAA Resource Record: the "discovery" and "priority" parameters. Additionally, it registers the URI "/.well-known/acme" at which all compliant ACME servers will host their ACME directory object. By retrieving instructions for the ACME client from the authorized CA(s), this mechanism allows for the domain owner to configure multiple CAs in either load-balanced or fallback prioritizations which improves user preferences and increases diversity in certificate issuers. The IETF Secretariat 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
Re: [Acme] [EXTERNAL] Re: Call for adoption of draft-misell-acme-onion-02
(with my personal hat on) I don’t claim to be a great expert on Tor. That said, if this draft is the straightforward ACME extension to implement CA/B F BR 1.8.6 Appdx B, then I support adoption. That discussion of why a CA would or would not implement this draft begs the next question: are there CA operators with an intent to implement this draft? Basically, is there running code? --- Mike Ounsworth From: Acme On Behalf Of Aaron Gable Sent: Friday, June 9, 2023 11:56 AM To: Deb Cooley Cc: IETF ACME Subject: [EXTERNAL] Re: [Acme] Call for adoption of draft-misell-acme-onion-02 WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Hi all, I support the draft for adoption. Specifically, I think it's a good thing to standardize the onion-csr-01 challenge type. I have two classes of comments that I look forward to discussing in-depth after adoption: 1) Obviously it's valuable for this draft to standardize a method that is already accepted by the CA/BF. But in the long term there's no need to use a CSR as the transport mechanism for a random token, a public key, and a signature -- moving away from x509 for this would be nice in the long term. Probably out-of-scope for this document, but worth discussing. 2) The primary benefit of the onion-csr-01 method is that it allows the CA to perform domain control validation without operating a Tor client. However, this benefit is obviated entirely by the need to operate a Tor client to check for CAA in the hidden service descriptor. It seems likely that there are CAs which have avoided implementing HTTP-01 and TLS-ALPN-01 for .onion due to the need to operate a Tor client; these same CAs may have been willing to implement ONION-CSR-01, but now will not due to the CAA mechanism. Thanks, Aaron On Sun, Jun 4, 2023 at 4:07 AM Deb Cooley mailto:debcool...@gmail.com>> wrote: This will be a two week call for adoption ending on 16 June. Please speak up either for or against adopting this draft. Thanks, Deb ___ 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!dFBmfm1apJ4-UmjFogFCu_Ia3l0BmVVqTZUsaZ_Av0j5LuahOtReLBZjOnb_RkMDev1a1-269Xq8UzPIUIfJ2ugpvMFCJ1Pbilvr$> Any email and files/attachments transmitted with it are confidential and 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
Re: [Acme] [EXTERNAL] Re: note takers
I’m also happy to take notes. --- Mike Ounsworth From: Acme On Behalf Of Aaron Gable Sent: Wednesday, March 29, 2023 8:33 AM To: Deb Cooley Cc: Amir Omidi ; IETF ACME ; acme-cha...@ietf.org Subject: [EXTERNAL] Re: [Acme] note takers WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. I've done it before; I'm happy to fill in during Amir's talk. On Tue, Mar 28, 2023 at 4:30 PM Deb Cooley mailto:debcool...@gmail.com>> wrote: Thank you for volunteering. Usually we can get a second person to fill in during your talk (hint, we need another volunteer). Deb On Tue, Mar 28, 2023 at 5:00 PM Amir Omidi mailto:a...@aaomidi.com>> wrote: I can participate in taking notes assuming we have the audio transcripts I can use to fill any gaps later (note I’ve not done note taking at IETF before). I will need coverage during the short period I’ll be talking. However Antonis is going to do the majority of the presentation so it should only be a few minutes. On Tue, Mar 28, 2023 at 14:47 Deb Cooley mailto:debcool...@gmail.com>> wrote: We are looking for volunteers to take notes for Thursday's meeting. It isn't a hard job... but we can't meet w/out someone doing that job. Thanks in advance, Deb (and Yoav) ___ 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!diHAgThRX_Iq3MRJ7RUXEIyr_kCpsgU_s3iUhEAUGSVZGTsh_ohRtIwd7ps_NUc7xZpzIBgCIv1SOg7yzllciTaczukCBp_OCpx9$> -- Amir Omidi (he/them) ___ 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!diHAgThRX_Iq3MRJ7RUXEIyr_kCpsgU_s3iUhEAUGSVZGTsh_ohRtIwd7ps_NUc7xZpzIBgCIv1SOg7yzllciTaczukCBp_OCpx9$> Any email and files/attachments transmitted with it are confidential and 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
Re: [Acme] [EXTERNAL] New ACME Challenge Proposal
Seems like a good extension. > In the rare event of a collision, a new ACME account can be generated. Should that be mentioned in the Security Considerations section? I'm thinking that you could add to the end of your existing S.C. something like "Certification Authorities (CAs) MAY, during ACME account creation, check that the DNS-ACCOUNT-01 prefix is unique in their database ..." Could you expand on this? > This ability is especially useful in the case of wildcard certificates, for > which no other ACME challenge allows issuance today. Why is this method more amenable to wildcards than existing ones? What are the policy implications of this, ex. at the CA/B F level? --- Mike Ounsworth -Original Message- From: Acme On Behalf Of Antonios Chariton Sent: September 8, 2022 12:08 PM To: IETF ACME ; aaom...@google.com Subject: [EXTERNAL] [Acme] New ACME Challenge Proposal WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. __ Hello everyone, This email serves to propose a new ACME challenge to this working group called DNS-ACCOUNT-01, which is available here: https://urldefense.com/v3/__https://daknob.github.io/draft-todo-chariton-dns-account-01/__;!!FJ-Y8qCqXTj2!Z52HhpPiq1S1WtA1bV_pO2FNJFp5suwJIqrjiAsDYnSQ5qiXTfKsNsIAxY1wau6cCelAm9lNha4tlUcp9hEtNEdc$ and here: https://urldefense.com/v3/__https://daknob.github.io/draft-todo-chariton-dns-account-01/draft.txt__;!!FJ-Y8qCqXTj2!Z52HhpPiq1S1WtA1bV_pO2FNJFp5suwJIqrjiAsDYnSQ5qiXTfKsNsIAxY1wau6cCelAm9lNha4tlUcp9vqzsJve$ (as a TXT). We have already solicited community feedback publicly in Mozilla's Dev Security Policy (MDSP) Mailing List, here: https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ICnTV94XyfM__;!!FJ-Y8qCqXTj2!Z52HhpPiq1S1WtA1bV_pO2FNJFp5suwJIqrjiAsDYnSQ5qiXTfKsNsIAxY1wau6cCelAm9lNha4tlUcp9pQl4Hsy$ . DNS-ACCOUNT-01 extends (but does not replace) the DNS-01 challenge in the following way: the DNS label under which the TXT record is created to respond to the challenge is account dependent. This allows a Subscriber to use multiple and separate subdomains to solve ACME challenges for the same domain. In DNS-01, the ACME server checks for DNS records under _acme-challenge. In DNS-ACCOUNT-01, the server will check for DNS records under _acme-challenge_accountUniqueValue, e.g. _acme-challenge_ujmmovf2vn55tgye. The last part is constructed from base32-encoding a part of the SHA-256 hash of the ACME Account URL. This allows each ACME account to use a separate label for the TXT record. We believe that BR Method 3.2.2.4.7 can be used with the proposed challenge for proof of domain control in the Web PKI. The current limitation of the DNS-01 challenge is that since CNAME records are unique per zone, a user would be unable to point the _acme-challenge label to more than one destination, so the following scenario is not supported: _acme-challenge.example.com. IN CNAME automated-dns-01.example.org. _acme-challenge.example.com. IN CNAME automated-dns-02.example.net. If every ACME account has a unique label, then you can easily achieve this: _acme-challenge_ujmmovf2vn55tgye.example.com. IN CNAME automated-dns-01.example.org. _acme-challenge_vfp2fz4sfemzl4vh.example.com. IN CNAME automated-dns-02.example.net. With this new challenge we can allow a domain owner to delegate domain control validation to separate DNS records, that can, in turn, prove domain control and request certificates. We found this to be useful in several scenarios such as the following: Hybrid Deployment Environments Some services may be running in a hybrid environment and require multiple instances to have access to (wildcard) certificates for the same domain name. As they will be using different ACME accounts, a different DNS record can be set up for each environment, without causing issues. Multi-Regional Deployments There are providers that have an infrastructure running in multiple regions and do not want to introduce dependencies across regions. They want to have the ability to issue certificates for the same domain as other regions, without relying on any particular one, to achieve resiliency, etc. Load Balancing Allowing each TLS-terminating endpoint to get its own certificate, without having to share and move private keys around, or adding common API keys for DNS, can be beneficial. Zero-Downtime Migrations If some infrastructure has to be migrated from one system to another, and it has to be done gradually, but the eventual change is a cut-off point, when the DNS records finally change, there is a need for the ability to allow both the old and the new infrastructure to obtain the same certificates, at the same time. This ability is especially useful in the case of wildcard certifica
