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 <tjtn...@gmail.com> 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 <tjtn...@gmail.com>
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
