These are all minor so I didn’t send them to i...@ietf.org. Also, once we
settle on whether these are okay, I can submit a PR if you’d like (or not if
that’ll be faster).
0) abstract
r/certificate authorities/certification authorities
and then you can:
r/certification authority (CA)/CA
1) s
A couple of comments:
0) abstract: r/exposed to an attacker/exposed to an unauthorized user
It’s not just attackers, you could unwittingly disclose your key and still need
to revoke it.
1) abstract and s1.2: in abstract: r/short-
term and automatically renewed (STAR) certificates/short-
t
Couple of comments:
0) s2: Use the update text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only
at 21:48, Richard Barnes wrote:
>
> Without looking at them in context that seem pretty reasonable. Happy to
> review a PR.
>
> On Wed, Aug 8, 2018, 21:03 Sean Turner wrote:
> These are all minor so I didn’t send them to i...@ietf.org. Also, once we
> settle on wheth
> On Sep 19, 2018, at 14:40, Richard Barnes wrote:
>
> 1. Forbid explanatory text
> 2. Require the "strict” format
Totally reasonable change.
spt
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Sorry about getting to this
> On Jun 8, 2021, at 16:15, Michael Richardson wrote:
>
> Signed PGP part
>
> Owen Friel \(ofriel\) wrote:
>deb> Again architecture: If the EST Server sits in front of a large
>deb> organization, then domain validation is more interesting, and the
>deb
Hi!
I had a read of these two I-Ds. Comments follow:
# -authority-token
tl;dr: editorial and nits
0) s8: I-D Nits complains about "Authority Tokens SHOULD not”. So s/SHOULD
not/SHOULD NOT
1) s9.1: I-D Nits complains about dancing references to RFCs 3986 and 4648. I
guess you could work them
Hi! Some comments:
tl;dr: Let the experiment begin!
# General
I thought this document is well written and easy to follow.
# Nits
1) s1: s/certificate authorities/Certification Authorities (CAs)
2) s2: I think maybe you can drop the IANA-SMI reference here:
… identified by id-on-bundleEID of
Hi! Glad the WG adopted this and am very supportive of this whole get a new
certificate before it expires (and don’t crush the CA while you do it)!
Just one thing I am trying to square away: second para of s5 motivates the
POST-as-GET to unauthenticated GET by saying the info isn’t confidential.
s the
> secondary only because I want to treat RFC 9174 as an informative reference.
> It certainly informs the use case of this validation method but they
> shouldn't be seen as directly coupled; only through the PKIX OIDs on which
> they both depend.
>
> On Wed, Sep 7,
I read it and support adoption.
spt
> On Nov 15, 2022, at 13:01, Deb Cooley wrote:
>
> This will be a three week call for adoption ending on 6 Dec. (because of
> holidays in the US). Please speak up either for or against adopting this
> draft.
>
> Thanks,
> Deb and Yoav.
>
> __
Congrats Tomofumi!
spt
> On Mar 7, 2024, at 16:48, Roman Danyliw wrote:
>
> Hi WG!
>
> As Deb (Cooley) will be the new, incoming SEC AD at the Brisbane meeting,
> there is a vacancy left in the co-chair team of ACME. It is my pleasure to
> announced that Tomofumi Okubo will be stepping in a
Reviewer: Sean Turner
Review result: Ready with Issues
Hi! 2nd ARTART review so I am not sure I am yet attuned to all the ART hot
buttons. Drawing on the times I have been through the ARTART process as an I-D
author ;)
ADs NOTE: I picked "Ready with Issues" because, while my comments
13 matches
Mail list logo
