Hi, all,
The acme-device-attest draft is expired.
Just checking: what are the plans?
cheers, thanks!
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Carsten is obviously right.
I had missed the parenthetical in § 3.8.3.1. of RFC8610:
>[…] (Note that this also means that there is one level of
>string escaping before the XSD escaping rules are applied.)
Thanks for spotting it!
Cheers, t
On 06/02/2023, 23:46, "Carsten Bormann"
I have read the draft and I think it brings a very valuable feature into the
ACME ecosystem. It’s also a perfect fit in at least two of our projects, and
I’d be happy to integrate it in our protocol flows.
The only concern I have with the current proposal is its reliance on WebAuthn’s
as the
Hi Brandon,
I’ve just read your draft and I find it very interesting.
One clarifying question: Is the mechanism you describe limited to certifying
keys that are hosted in HW? Or could it also cover the case of an ephemeral /
short-term keypair that resides in a TEE?
Three short notes:
*
Hi Ben,
Thank you again for your comments; Yaron has just pushed -09 which
should address most of them -- see below for the detail.
(I am merging this together with your Ballot email to have all the
discussion in one place.)
On 10/06/2021, 08:00, "Benjamin Kaduk" wrote:
> I think we are in
(Apologies for top-posting.)
Due to an unintended char swap we managed to reference an ICN RFC.
The error has been fixed in the working copy.
On 10/05/2021, 19:07, "Acme on behalf of Thomas Fossati" wrote:
> Hi all,
>
> We have just published version -08 of the ACME
Hi all,
We have just published version -08 of the ACME delegation draft [0].
We think it addresses the feedback we received from the IESG (all the
DISCUSS positions as well as the vast majority of the COMMENTs), plus
Carsten's review over the CDDL and JSON-schema bits, plus Richard's IANA
Expert
Hi Ben,
Thanks a lot for your in-depth review.
We think we have addressed all your comments, but please check [1] and
its attached PRs for confirmation.
The only points we didn't address are listed below, along with the
reasons why we decided to avoid changing the existing text.
On 08/04/2021,
On 26/03/2021, 11:30, "Yaron Sheffer" wrote:
> [...] thank you Russ!
+1
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the
Hi Russ,
On 25/03/2021, 20:15, "Russ Housley" wrote:
> Thomas:
>
> As I said in GitHub, I think the Abstract could be more clear. There
> are two key points. First, the certificate contains the identifier that
> is delegated. Second, that the third party has control of the private
> key, and
Hi Russ,
On 25/03/2021, 19:28, "Russ Housley" wrote:
>
> You will see my comments in those issues.
Thanks very much!
We have prepared https://github.com/yaronf/I-D/pull/167/files
Could you please review it and see if fixes your remaining concerns?
Cheers, t
> Russ
>
> > On Mar 25, 2021, at
Hi Suresh, thanks for your review!
On 25/03/2021, 19:10, "Suresh Krishnan via Datatracker"
wrote:
>
> Reviewer: Suresh Krishnan
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being
Hi Russ,
Thanks very much for your clear and thorough review!
Your comments are now tracked in the following tickets:
On 14/03/2021, 22:02, "Russ Housley via Datatracker" wrote:
> Abstract: It says: "... party access to a certificate associated with
> said identifier." This is odd wording,
Hi Roman,
On 08/03/2021, 12:50, "Roman Danyliw" wrote:
> Thanks for adding the new CDDL schema and clean-up to the JSON schema.
> This resolves all of my feedback from AD review. I will advance the
> document to IETF LC.
Thank you!
> One question I have in the -06 to -07 changes is why the
Hi Roman, thank you very much for the great comments.
There is now a GitHub issue for each review item:
https://github.com/yaronf/I-D/issues?q=label%3A%22AD+review%22+label%3A%22ACME+STAR+Delegation%22
We will get back to you as soon as we are done with the edits, or
if there's anything that
Hearing no dissent, we are going to move forward with the plan below.
Thanks
On 20/04/2020, 14:26, "Thomas Fossati" wrote:
> Hi, all,
>
> While working on the STAR delegation protocol we realised that the
> "STAR" in "ACME STAR Delegation" is not a s
Hi, all,
While working on the STAR delegation protocol we realised that the
"STAR" in "ACME STAR Delegation" is not a strict precondition to build a
delegation mechanism, and that we could quite easily relax the
assumption and have a more general ACME-based delegation that can work
with both STAR
Hi Éric,
Apologies for the late reply.
On 03/10/2019, 15:21, "Éric Vyncke via Datatracker" wrote:
> Thank you for the work put into this document. While I am balloting
> "no objection", I support Alexey's DISCUSS.
>
> I am also wondering what is the impact of the increased rate of
> request to
Hi Ben,
On 05/10/2019, 02:07, "Benjamin Kaduk" wrote:
> On Thu, Oct 03, 2019 at 05:33:49PM +, Thomas Fossati wrote: I'm
> trying to think about the risk that a future use case for
> "allow-certificate-get" might want slightly different semantics for
> when it
Hi Ben,
Upon further review, I agree with your assessment on the first part of
your DISCUSS, which is a relief.
I'm addressing your COMMENTs [1] and the second part of your DISCUSS
[2] that are for the most part straightforward. I have a few things
I'd like to discuss further though. See
Hi Ben,
First of all thank you very much for this excellent review.
On your DISCUSS points:
On 02/10/2019, 19:06, "Benjamin Kaduk via Datatracker" wrote:
> RFC 8555 (and the IANA registry) list the 'status' field of the order
> object as not configurable, yet we propose to configure it (in
>
Hi Adam,
Thank you very much for your review.
On 02/10/2019, 02:22, "Adam Roach via Datatracker" wrote:
> §3.3:
>
> > o Intermediaries MAY insert or delete the value, but MUST ensure
> > that if present, the header value equals the corresponding
> > value within the credential.
>
>
Hi Warren,
Thanks for the review.
On 01/10/2019, 17:02, "Warren Kumari via Datatracker" wrote:
> Please review and address the comments in
> https://datatracker.ietf.org/doc/review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21/
> -- they are useful (and thanks to Mehmet for the review)
Hi Alexey,
> I was talking about rules for adding new values to these 2
> subregistries. E.g. “Expert Review”, “Specification Required”,
> “IETF Review”, etc.
Ah, thanks for the clarification!
I don't see a reason why this new registries should be treated
differently from all other ACME
Hi Alexey,
Thank you very much for your comments.
On 29/09/2019, 17:29, "Alexey Melnikov via Datatracker"
wrote:
> I have one small issue that I would like to discuss before recommending
> approval of this document:
>
> Section 6.4 and 6.6 don’t seem to specify IANA registration procedure for
On 17/09/2019, 16:02, "Acme on behalf of internet-dra...@ietf.org"
wrote:
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-star/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-star-09
>
On 13/09/2019, 13:41, "Thomas Fossati" wrote:
> It seems to me that this might still be possible modulo
> recurrent-certificate-adjust (rcp) being upper bounded by
> recurrent-cert-validity (rcv), i.e., slightly changing the calculations
> in 3.5 like this:
>
> no
Thanks Richard for raising this and Ryan for taking the time to explain.
On 11/09/2019, 17:52, "Ryan Sleevi" wrote:
> I'm not Richard, but with respect to publicly trusted certificates,
> issuing a certificate with a notBefore set prior to that certificate
> was issued is seen as, minimally,
On 11/09/2019, 18:40, "Salz, Rich" wrote:
> > the protocol is still correct/consistent. But, let's be bold as
> > it's probably worth taking the risk :-)
>
> We can ask that the IESG/IETF do a simultaneous re-review period of
> something like two weeks.
Sounds good, thank you.
IMPORTANT
Hi Rich, Richard,
(Merging both your emails into one reply.)
On 09/09/2019, 23:57, "Salz, Rich" wrote:
> I don't care about the STAR acronym not bring known by those who don't
> know :) but I think Richard's comments – most of which are, really,
> wordsmithing nits of message-field names –
Hi Richard,
Thank you for the detailed review. As you note yourself, this is quite
late in the document life-cycle (the draft completed IETF LC over a
month ago), which is unfortunate, given that every one of your comments
is an actual protocol change. As far as we understand, none of them can
be
ego Lopez
> Oscar Gonzalez de Dios
> Antonio Agustin Pastor Perales
> Thomas Fossati
> Filename: draft-ietf-acme-star-08.txt
> Pages : 26
> Date: 2019-08-28
Hi Roman,
Thank you very much for the review.
> I conducted as second AD review of draft-ietf-acme-star per the AD
> hand-off. I have the following feedback:
>
> ** (From the first AD review) Per the issue of PS vs. Experimental
> status - I reviewed Section 5, Shepherd Write-up and the ML
ors : Yaron Sheffer
> Diego Lopez
> Oscar Gonzalez de Dios
> Antonio Agustin Pastor Perales
> Thomas Fossati
> Filename: draft-ietf-acme-star-05.txt
>
The 10/06/2018 17:27, Richard Barnes wrote:
> I'm not hard set against this change, I just don't see much benefit.
>
> Allowing GETs for certificate URLs is so low-risk that we weren't going to
> access-control it at all until a couple weeks ago. Now it's so high-risk
> that we need to REQUIRE
35 matches
Mail list logo
