Hi all,
Overall this looks like a well laid out draft that addresses a genuine need.
However, I don't see any connection to ACME nor do I think it fits within
the ACME working group charter.
This is not to say the IETF is the wrong place for this work, merely that
it's better suited in a different
ate Management Environment (ACME) Extensions
> for ".onion" Special-Use Domain Names
>Author: Q Misell
>Name:draft-ietf-acme-onion-03.txt
>Pages: 20
>Dates: 2024-08-27
>
> Abstract:
>
>The document defines extensions to the Automated Cert
Hi Peter,
Many thanks for the speedy review! I'll merge in those editorial nits.
> what does it mean for a nonce to have a validity period?
This requirement is lifted from the CA/BF Baseline Requirements, basically
it means once a server has generated a nonce it must not accept a response
to a c
changes to 3.1.2 and 3.1.3 that identify the
> modifications? This text was added to address a comment during the last
> WGLC.
>
>
>
> *From: *Q Misell
> *Date: *Tuesday, August 13, 2024 at 8:59 AM
> *To: *Tim Hollebeek
> *Cc: *Carl Wallace , IETF ACME
> *Subject: *R
6. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.
On Tue, 13 Aug 2024 at 12:40, Q Misell wrote:
> Thanks Tim for the review, that's really helpful! I'll give the dra
non-experts would benefit from these improvements as well. I think it’s a
> great draft, it just assumes a lot of background and may be impenetrable
> for non-experts.
>
>
>
> -Tim
>
>
>
> *From:* Carl Wallace
> *Sent:* Monday, August 12, 2024 7:08 AM
> *To:* Q Misel
uld please respond indicating as such so we
can move this forward.
Many thanks,
Q Misell
--
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
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 bei
aft!
Thanks in advance,
Q Misell
--
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,
eded.
I'll work on making this clearer.
Thanks,
Q Misell
--
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
Hi all,
Just a quick reminder that there's less than a week left on the WGLC
for draft-ietf-acme-onion.
Cheers,
Q Misell
--
Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifi
Please add me as well.
--
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 9
Hi,
As discussed during the IETF meeting last week this is just a reminder for
anyone to speak up if they have better ideas for the in-band CAA
in draft-ietf-acme-onion.
If there's nothing by the end of the week I think this document can go to
WGLC.
Thanks,
Q M
embers can vote through the APIs provided by the smart contract. For
> revocation, maybe a simple majority, such as 51%, is enough to revoke a
> certificate.
>
>
> --
> *From:* My1
> *Sent:* Friday, 10 November 2023 7:02 PM
> *To:* Wang Haiguang
&g
Also happy with the notes for my talk.
--
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,
Caerdyd
> There are many different blockchains today and some of them quite cheap
in transaction fees. These blockchain with cheap transaction fees support
smart contract too. Beside that, we can also consider consortium
blockchains, which can have fewer nodes and the cost and transaction speed
could be mu
Whilst I agree that CAs could do with more transparency, ACME isn't the
place to work on that.
ACME is one of many methods to interact with a CA, most CAs don't even
offer it.
It is merely a protocol interface to a CA, the CA/BF actually defines how a
CA operates, and any transparency requirements
smart contracts are immutable. This is desirable in certain
situations, however there is past form for having to update ACME to
mitigate a security flaw. This would become near impossible with ACME as a
smart contract.
Thanks,
Q Misell
--
Any statements contained in this e
have the key to
> sign this on demand
> and it's kinda vague when acme server are running tor client and see caa
> in finalization object : it may process it or ignore it and even reject
> finalization because not implementing this extension as they think not
> needed
>
nt it to be nonce for
> that certificate finalization explicitly.
> 2023-10-17 오전 3:10에 Q Misell 이(가) 쓴 글:
>
> Hi all,
>
> In-band CAA is now implemented on the reference CA at
> https://acmeforonions.org and in the certbot-onion
> <https://pypi.org/project/certbot-onion/> plugi
E102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.
On Fri, 13 Oct 2023 at 17:19, Q Misell wrote:
> I've found some time to specify in-band CAA, a quick first draft is in the
> working draft[1
marks in the UK, under № UK3718474 and № UK3718468,
respectively.
On Tue, 10 Oct 2023 at 21:22, Q Misell wrote:
> Hi Silvio,
>
> Thanks for that info, that's quite helpful.
>
> I think the idea of allowing the client to just send the CAA lines signed
> by its key would work wel
spectively.
On Tue, 10 Oct 2023 at 20:14, rhatto wrote:
> On Thu, Sep 07, 2023 at 04:55:51PM +0100, Q Misell wrote:
> > I've had some discussion recently with the Tor project on implementation
> > hurdles for draft-ietf-acme-onion. One concern that has been raised by a
> f
Regardless of the inclusion of that paragraph in the BR I still think it
would be worthwhile to be able to limit a DNS based validation to not
issuing wildcards, should an admin so desire.
--
Any statements contained in this email are personal to the author and are
not
of profiles enumerated, whilst also restricting how complex the request
from the client can be.
A CA would, of course, be free to list profiles and define no flags if it
thinks that's the best approach for it.
Thoughts?
Q Misell
--
Any statements contained in this emai
Hi all,
I've had some discussion recently with the Tor project on implementation
hurdles for draft-ietf-acme-onion. One concern that has been raised by a
few is the need to run a Tor client to validate requests, even with
onion-csr-01, due to the inclusion of CAA in the draft.
One solution propos
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 r
> RFC5280 permits CAs to populate
AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber}
instead of AuthorityKeyIdentifier.keyIdentifier.
Do we instead use a structure containing the full AKI (as encoded in the
certificate) and the serial number? This would seem to me to allow uniq
> Maybe it would be best to state "Hey, the CA generated its own Issuer Key
IDs, it can be expected to recognize them too", and make the request simply
IssuerKeyID + Serial, in some simple concatenate+base64url format.
Issuer Key ID plus serial makes a lot of sense to me, and I think should be
the
> Issuer key hash: Is this not in the Authority Key ID extension? Or is
this extension not used?
If I'm understanding it correctly the AKI is what's needed.
--
Any statements contained in this email are personal to the author and are
not necessarily the statements of
iority.*
>
> 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
> *Sent:* Wednesday, July 12, 2023 19:32
>
if one of your 3
> records contains an error. You want to ignore that record only and use the
> valid ones.
>
>
>
> --
> *From:* Tim Hollebeek
> *Sent:* Wednesday, July 12, 2023 6:43:21 PM
> *To:* Paul van Brouwershaven ; Q
> Misell
> *Cc:*
eter is not specified the client MUST assume that
> discovery is enabled.*
>
>
> There is however a comment in the examples that this behavior might need
> to change if deemed necessary.
>
> Paul
>
>
> --
> *From:* Q Misell
> *Sent:* Wednesday, July 12, 2023
Hi all,
I happened to be poking around the certbot codebase today and decided to
try and implement this draft.
It turned out to be a much simpler task than I had expected, however I felt
the draft was a bit lacking in details for what the ACME client should
consider an error.
For example:
- I
Hi,
Reading the draft I think it is the author's intention (correct me if
wrong) that each customer of a hosting provider would have a new ACME
account created for them, and for the contact details on the ACME account
to be that of the customer, not the hosting provider.
I know it is common with
d the Glauca logo are registered trademarks
in the UK, under № UK3718474 and № UK3718468, respectively.
On Fri, 9 Jun 2023 at 09:55, Q Misell wrote:
> Hi Amir,
>
> TIL about HiCA. They do seem like a weird bunch!
>
> I note they only allow ACME.sh as an ACME client and forb
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 other
client in their EULA (
https://www1.hi.cn/en/docs/getting-started/acme.sh-installation). They also
have some interesting ideas about patents surrounding ACME (
https:/
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 sense to me
to read DNS-02 and DNS challenge type 2, not a upgraded edition of version
1.
--
Any statements contained in this email
an VAT №: 522-80-03080. Glauca Digital and the Glauca logo are
registered trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.
On Sun, 23 Apr 2023 at 22:12, Q Misell wrote:
> Hi Seo,
>
> Thanks for the feedback.
>
> I copy pasted the list of logs into my
mentations. could make a hidden service
> with caa-critical online?
>
> P.S didn't notice you already posted v 02 of this draft.
>
> 2023-04-21 오전 7:04에 Q Misell 이(가) 쓴 글:
> > Hi all,
> >
> > Thanks for all your feedback over my draft. I've incorporated your
Hi all,
Thanks for all your feedback over my draft. I've incorporated your comments
into a new draft, and published this.
I've also finished my reference implementation of the draft, more details
available at https://acmeforonions.org. I'd be delighted if you'd try it
out and let me know what you
bing is not
> necessary, but I don’t see any information regarding checking the CAA RRSet
> at the “onion” TLD itself. I don’t believe that doing such a check is
> technically feasible, but I think it would be good to clarify this, as
> checking the TLD is mandated by the CAA spec.
>
calling CA to sign the certificate
> 3. most acme CA moved to async order finalization, so it will move to
> processing if it wants or not.
>
> 2023-04-17 오전 12:58에 Q Misell 이(가) 쓴 글:
>
> Hi,
>
> Thanks for the comments. I'll fix the typos.
>
> With regar
ey (because it's onion v3 private
> key,) but CA/B does not allow signing ed25519 key in TLS certificate, you
> can't reuse CSR for both purpose.
>
>
> 2023-04-16 오전 1:22에 Q Misell 이(가) 쓴 글:
>
> Hi all,
>
> Hope you've all recovered from IETF116, it was lovely
rvice
An explicit non goal is to define validation methods not already approved
by the CA/BF, however if someone can make a compelling argument for an
entirely novel method I wouldn't be entirely opposed to it.
Looking forward to your feedback, and some indication that this would be
worth ad
45 matches
Mail list logo
