Re: [Acme] Fwd: New Version Notification for draft-suchan-acme-onion-00.txt
I don't think we can change challange name while being competiable with CABF reqs: they already point to RFC8555 section 8.3 and RFC8723 for allowed challanges. any other name will not be comply with that. we can invent new http based challange based 4.3.3.2.18, but it will have to use different location: .well-known/pki-validation http-01 and tls-alpn-01 is not allowed to used to wildcard certificate, and Appendix B doesn't override that, so csr crafting challange is only way to process wildcard request. and it's out of bound challange that doesn't need run Tor daemon on CA infrasturcture. I chooes to create add seperate onion identifier on based on old steff comments on Letsencrypt boulder issue: https://github.com/letsencrypt/boulder/issues/4620#issuecomment-567637792 2022-05-11 오후 9:36에 Richard Barnes 이(가) 쓴 글: Yep, this is the right way to suggest a new draft! Thanks for writing this up. One high-level comment on a quick skim: I don't think you need the new identifier type. Since .onion is a "legit" TLD [RFC7686], onion names are part of the DNS namespace. It's OK for CAs to have different policies for different domain names. Obviously the CABF requirements would require a CA to validate .onion names differently, but that's up to the CA's internal logic to choose different challenges. Note that they already need such logic, since a client can already send in a .onion name, and the CA shouldn't validate it like a normal name. In general, it would be good to understand what extra work is really needed here. As you point out, http-01 and tls-alpn-01 work for onion names; is the new challenge type better in some way? On Tue, May 10, 2022 at 10:18 PM Seo Suchan wrote: I'm new to rfc draft thing: is this right way to suggest a new draft? in appendix I made some questions. copyting them here: should this be about onion address, or all kind of alternative DNS systems? should identifier type and challenge type include or strip -v3 tag from its name? if we include that how about this doc name itself? http-01 and tls-alpn-01 over tor will work as well for like onion address V2 or V12, but csr challenge may not. but it's reasonable to ask same identifier type should give same set of challenges. should the as rigid as complying this will make comply CA/B Baseline requirement? while type onion domain name just full onion v3 name itself with example subdomain will exceed rfc line limit. but using ... doesn't right in context of domain name. any alternative to express truncated FQDN? would "example.onion" work while it wouldn't be valid onion name? forwarded message title: New Version Notification for draft-suchan-acme-onion-00.txt date: Tue, 10 May 2022 19:04:01 -0700 sender: internet-dra...@ietf.org to: Seo Suchan A new version of I-D, draft-suchan-acme-onion-00.txt has been successfully submitted by Seo Suchan and posted to the IETF repository. Name: draft-suchan-acme-onion Revision: 00 Title: Automated Certificate Management Environment (ACME) Onion Identifier Validation Extension Document date: 2022-05-10 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-suchan-acme-onion-00.txt Status: https://datatracker.ietf.org/doc/draft-suchan-acme-onion/ Htmlized: https://datatracker.ietf.org/doc/html/draft-suchan-acme-onion Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for Tor Project's onion V3 addresses. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-suchan-acme-onion-00.txt
Yep, this is the right way to suggest a new draft! Thanks for writing this up. One high-level comment on a quick skim: I don't think you need the new identifier type. Since .onion is a "legit" TLD [RFC7686], onion names are part of the DNS namespace. It's OK for CAs to have different policies for different domain names. Obviously the CABF requirements would require a CA to validate .onion names differently, but that's up to the CA's internal logic to choose different challenges. Note that they already need such logic, since a client can already send in a .onion name, and the CA shouldn't validate it like a normal name. In general, it would be good to understand what extra work is really needed here. As you point out, http-01 and tls-alpn-01 work for onion names; is the new challenge type better in some way? On Tue, May 10, 2022 at 10:18 PM Seo Suchan wrote: > > I'm new to rfc draft thing: is this right way to suggest a new draft? > > in appendix I made some questions. copyting them here: > > should this be about onion address, or all kind of alternative DNS systems? > should identifier type and challenge type include or strip -v3 tag from > its name? if we include that how about this doc name itself? http-01 and > tls-alpn-01 over tor will work as well for like onion address V2 or V12, > but csr challenge may not. but it's reasonable to ask same identifier > type should give same set of challenges. > should the as rigid as complying this will make comply CA/B Baseline > requirement? > while type onion domain name just full onion v3 name itself with example > subdomain will exceed rfc line limit. but using ... doesn't right in > context of domain name. any alternative to express truncated FQDN? would > "example.onion" work while it wouldn't be valid onion name? > > forwarded message > title: New Version Notification for draft-suchan-acme-onion-00.txt > date: Tue, 10 May 2022 19:04:01 -0700 > sender: internet-dra...@ietf.org > to: Seo Suchan > > > > > A new version of I-D, draft-suchan-acme-onion-00.txt > has been successfully submitted by Seo Suchan and posted to the > IETF repository. > > Name: draft-suchan-acme-onion > Revision: 00 > Title: Automated Certificate Management Environment (ACME) Onion > Identifier Validation Extension > Document date: 2022-05-10 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/archive/id/draft-suchan-acme-onion-00.txt > Status: https://datatracker.ietf.org/doc/draft-suchan-acme-onion/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-suchan-acme-onion > > > Abstract: > This document specifies identifiers and challenges required to enable > the Automated Certificate Management Environment (ACME) to issue > certificates for Tor Project's onion V3 addresses. > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Fwd: New Version Notification for draft-suchan-acme-onion-00.txt
I'm new to rfc draft thing: is this right way to suggest a new draft? in appendix I made some questions. copyting them here: should this be about onion address, or all kind of alternative DNS systems? should identifier type and challenge type include or strip -v3 tag from its name? if we include that how about this doc name itself? http-01 and tls-alpn-01 over tor will work as well for like onion address V2 or V12, but csr challenge may not. but it's reasonable to ask same identifier type should give same set of challenges. should the as rigid as complying this will make comply CA/B Baseline requirement? while type onion domain name just full onion v3 name itself with example subdomain will exceed rfc line limit. but using ... doesn't right in context of domain name. any alternative to express truncated FQDN? would "example.onion" work while it wouldn't be valid onion name? forwarded message title: New Version Notification for draft-suchan-acme-onion-00.txt date: Tue, 10 May 2022 19:04:01 -0700 sender: internet-dra...@ietf.org to: Seo Suchan A new version of I-D, draft-suchan-acme-onion-00.txt has been successfully submitted by Seo Suchan and posted to the IETF repository. Name: draft-suchan-acme-onion Revision: 00 Title: Automated Certificate Management Environment (ACME) Onion Identifier Validation Extension Document date: 2022-05-10 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-suchan-acme-onion-00.txt Status: https://datatracker.ietf.org/doc/draft-suchan-acme-onion/ Htmlized: https://datatracker.ietf.org/doc/html/draft-suchan-acme-onion Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for Tor Project's onion V3 addresses. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
