Re: [Acme] Fwd: New Version Notification for draft-suchan-acme-onion-00.txt

[Seo Suchan <[e-mail]>]

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 <[e-mail]> 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: [e-mail]
>     to:     Seo Suchan <[e-mail]>
>
>
>
>
>     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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/acme
>