currently acme.castle.cloud interperated it as binary concatenate but
I'm not sure it's right reading of document. while each token parts
needs to be in base64url alphabet characters but it didn't explictly
said they are base64 encoding of something: but token-part nameing makes
one thing
Would it be illegal to server probe both scope and pass if there is intended
token?
On 2024년 3월 19일 오전 8시 3분 7초 GMT+09:00, Jacob Hoffman-Andrews
wrote:
>Thanks, authors, for the updates in
>https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00
>.
>
>Adding a "scope"
reading it again I'm no longer sure we can say account label isn't
security perpose: entire point of this challange is those
account-specific hostname CNAMEed to some delegated dns server for acme
perpose (like https://github.com/joohoi/acme-dns). and when clients are
using 3rd part DNS
it was "https://example.com/acme/acct/ExampleAccount; but looks like
autometic line change was in bad place
2024-03-16 오후 8:19에 Richard Körber 이(가) 쓴 글:
Hello!
In section 4 of draft-ietf-acme-scoped-dns-challenges-00, an example
is given about how to calculate the hash of the account
think that URL will need to be stable.
On Fri, Feb 2, 2024 at 2:36 AM Seo Suchan wrote:
for some ACME servers they have multiple allowed acme endpoint
domains,
and server doesn't know what domain name client used to access its
API
duce don't have full accounturl that used
for some ACME servers they have multiple allowed acme endpoint domains,
and server doesn't know what domain name client used to access its API
duce don't have full accounturl that used to craft challenge subdomain:
like boulder (what Let's encrypt uses) allows to accessed from mulitple
path
https://dl.acm.org/doi/10.1145/2736277.2741089
Think this is the attack rfc mentions
Anyway as we can't use certificate for trust for https in validation context
https does no better job than http
On 2024년 1월 15일 오후 9시 41분 41초 GMT+09:00, Rob Sayre 작성함:
>On Mon, Jan 15, 2024 at 3:42 AM Deb
Google bought the gTLD of .dev and .app and set HSTS on tld level.
On 2024년 1월 14일 오후 8시 1분 4초 GMT+09:00, Deb Cooley 작성함:
>I had this marked as 'hold for update' (vs. 'verified'). I can't tell from
>the discussion how you think we should be handling it.
>
>I'm also not sure why .dev domains are
CA ignores HSTS: they aren't browsers, likewise they ignore certificate
staudes of https page walie validating too.
2024-01-12 오후 12:02에 Rob Sayre 이(가) 쓴 글:
Hi,
Is this one valid?
https://www.rfc-editor.org/errata/eid6843
> the challenge must be initiated over HTTP, not HTTPS.
What if the
Think it should limit to authz with valid or pending state, and for same
account. Finalized auths are still exsit on server; and other accounts may have
auth for it
On 2024년 1월 3일 오후 8시 36분 37초 GMT+09:00, Deb Cooley 작성함:
>Happy New Year!
>
>I'm going through acme's errata. This one was
It's about line changes, errata added line change between type: and it's body
On 2024년 1월 3일 오후 9시 11분 18초 GMT+09:00, Deb Cooley 작성함:
>Yet another errata My old eyes don't see what the change is. All the
>brackets look lined up the same in both original and corrected. If someone
>can
While looks sensible I wonder if how many clients pulling on auth instead of
challanges:
Those client will pull without limit if this behavior applied to CA
For example this client do watch auths status instead of challenge itself.
ogo are registered trademarks in the UK, under № UK3718474
and № UK3718468, respectively.
On Tue, 17 Oct 2023 at 10:33, Seo Suchan wrote:
well if CA is willing to run tor In house they can read caa record
tor network (CA/B br forbids using external proxy to access tor
websit
226. Estonian VAT
>№: EE102625532. Glauca Digital and the Glauca logo are registered
>trademarks in the UK, under № UK3718474 and № UK3718468,
>respectively.
>
>
>On Tue, 17 Oct 2023 at 04:15, Seo Suchan wrote:
>
>>
>> not sure giving expiry by client side is me
not sure giving expiry by client side is meaningful: as we send this at
finalization step, and as something would be very wrong if one request
another certificate in 8 hours from last certificate so whatever value
client may put there will be expired by the time we request: in effect
it'd be
stonia under № 16755226. Estonian VAT №: EE102625532. Glauca
Digital and the Glauca logo are registered trademarks in the UK, under
№ UK3718474 and № UK3718468, respectively.
On Tue, 3 Oct 2023 at 20:04, Seo Suchan wrote:
Because CA/B baseline DNS Change auth have this paragr
Because CA/B baseline DNS Change auth have this paragraph, I think DNS
admin should consider any DNS record there to be valid for wildcard.
Note: Once the FQDN has been validated using this method, the CA MAY
also issue Certificates for
other FQDNs that end with all the Domain Labels of the
t;
>(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
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
>Sent: Tuesday, August 15,
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 이(가) 쓴 글:
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
so It would mean all of parameter definitions can be applied to
issuewild too, and if there is only they will be considered?
2023-07-13 오후 4:47에 Paul van Brouwershaven 이(가) 쓴 글:
3.1.1. recommend clarifying the extent to which case matters. How
should
"TRUE" or "True" be handled?
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
Acme on behalf of Seo Suchan
*Sent:* Friday, July 7, 2023 04:29
*To:* acme@ietf.org
*Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
draft-vanbrouwershaven-acme-auto-discovery-00.txt
a. ) CAs may want to put list of acme endpoints at well-known, for
example one each f
a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with
https://acme.sectigo.com/v2/EV
b. ) I think hosting provider wouldn't want to visit a random CA without
human intervention, not only due to potential Malicious one but an
for CAA mechanism for tor, I'm don't think acme working group is right
place to talk about it: as they effect non-acme CA that sign certificate
for onion, shouldn't it need to be handled on lamps subject (as there is
where CAA rfc was discussed)
2023-06-10 오전 1:55에 Aaron Gable 이(가) 쓴 글:
Hi
@mholt on github found they they are inject RCE onto acme.sh. be aware.
https://github.com/acmesh-official/acme.sh/issues/4659
2023-06-09 오후 4:55에 Q Misell 이(가) 쓴 글:
Hi Amir,
TIL about HiCA. They do seem like a weird bunch!
I note they only allow ACME.sh as an ACME client and forbid every
I kinda think TLS-SNI-02 was made as version 2 of TLS-SNI-01, but it
doesn't matter as they are no longer a thing
2023-05-13 오전 3:43에 Q Misell 이(가) 쓴 글:
I'm also in favour of calling it DNS-02. I highly doubt there will be
many (if any) versions of challenges beyond version 1. It makes more
google's solera 2018~2022 are no longer accept new record. solera ct log
is sharded by notafter day of incoming certificates, so only log able to
use currently be 2023 (assume 90 day certificate)
when I ran you client for onion-csr without having hosted onion hidden
service, server returned
t then two CSRs, one signed with the onion key to be
submitted as a challenge response, and one submitted to finalize the
order.
On Sun, 16 Apr 2023 at 22:08, Seo Suchan wrote:
I think this section implies CSR has to be signed by what
subjectPublickeyinfo be used for verify it:
rfc2986
(subjectPKInfo), whilst the entire
CertificationRequest can be signed with a different key entirely, and
this is what the CA/BF rules permit, and indeed what they were
designed to achieve and how HARICA implements this.
Thanks,
Q
On Sun, 16 Apr 2023 at 03:44, Seo Suchan wrote:
5.2 has
5.2 has few typos CAA when it should mean CA: (CAA can't read any
descriptor, it's a text)
For running CAA in general, I think appendix B of CA/B BR method b made
in a way that CA doesn't have to run Tor client at all. And it actually
allows signing a cert for not yet hosted onion domain,
IIRC it was dual purpose: state some randomish time to reduce load spike
at 12:00AM or mass renewal after mass revocation event, and order renew
when revocation is imminent.
I think it's pretty safe to say IFF ARI time changes from what it's set
just after certificate creation, you could
messaging both lamps and acme working group as while rfc8657 what I
propose will make outside scope of ACME WG:
while RFC8657 uses allows non-acme CAs use self-defined validation
method with ca-xxx prefix, as CAs are already have binding
classification from allowed validation methods, I think
as account key doesn't fly alone but with an acme client to use it, I
think attacker already knows any order it does by just looking at
clients log - even if it didn't get certificate private key because it's
processing external CSR from somewhere else or so.
2022-10-23 오전 9:38에 Matt Palmer
As this is already binding classification for TLS certificate industry,
It's natural to use this classifiaction for CAA records for set CAA
record of validation, but not sure this kind of one-liner document will fly:
"validationmethod lable br-N means it allows cerficiate validation
method
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
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
I noticed there is nothing that in RFC8823 client has no way to ensure
incomming acme-challange mail is for their challange. then it's trivial
to DoS a email challange: attacker just have to spem order certificates
for that email from same server then renewal is likely to happen, then
client
21. 11. 15. 02:35에 Benjamin Kaduk 이(가) 쓴 글:
With apologies for focusing on a different aspect than you are attempting
to focus on...
On Sun, Nov 07, 2021 at 12:00:20AM +0900, Seo Suchan wrote:
After RFC8823 I though it would be trivial to apply its process for TLS
certificate by verify email
After RFC8823 I though it would be trivial to apply its process for TLS
certificate by verify email of various authoized Email address (like
ad...@exemple.com or email set by Whois/CAA/TXT etc...) but there is a
problem: it's sending mail when server reply the authorization, even if
client has
I think it'd better to not limit challenge type to dns-01, but to any
challenge type that CA is be allowed to issue wildcard cert from it.
there may be add another challenge type (like using rfc8823's mail
challange to CAA iodef or whois mail?) or DNS challenge may needed to
amend to dns-02 in
42 matches
Mail list logo
