Hi Jon!

Thanks for working on the revised draft.

> -----Original Message-----
> From: Peterson, Jon <[email protected]>
> Sent: Sunday, October 23, 2022 3:45 PM
> To: Roman Danyliw <[email protected]>; [email protected]
> Subject: Re: [Acme] Next steps on draft-ietf-acme-authority-token
> 
> 
> Thanks Roman,
> 
> I implemented most of these, but I'm confused by the request for a Description
> column for the ACME Authority Token Challenge Type registry: the -08 version
> of the specification included a Description column that in the registry in 
> 7.3. Is
> there something else we need to add?

I'm cutting the relevant feedback from the original thread:

==[ snip ]==
>     The text introduced into Section 7.3 of -08 has typos:
> 
>     OLD
>     ... and a Description of
>        "JSON Web Token (JTW) challenge type.
> 
>     NEW
>     ... and a Description of "JSON Web Token (JWT) challenge type."
==[ snip ]==

When new text was added to this section in -08, it introduced the typo noted 
above.  It's a simple editorial fix.

> I think the simplest way to solve the REST specification problem (a known
> problem) is simply to cut the word "REST" from that sentence, i.e. "MUST
> support an HTTPS interface for Authority Token acquisition as described
> below." The description of the interface below is RESTful, sure, but it tells 
> you
> what you're supposed to do with HTTP rather than just saying "use REST" or
> something.

Works for me.

Thanks,
Roman

> On 10/20/22, 8:54 PM, "Acme on behalf of Roman Danyliw" <acme-
> [email protected] on behalf of [email protected]> wrote:
> 
>     Hi!
> 
>     Thanks for the revised -08 document, and the WGLC to confirm the edits.  I
> reviewed the IESG ballot COMMENT and the following edits are still needed.
> 
>     (1) Francesca's ballot
> 
>     ==[ snip ]==
>     Additionally, I would suggest to add a Description column to the IANA ACME
> Authority Token Challenge Type Registry, containing some short description of
> what the types defined are.
>     ==[ snip]==
> 
>     The text introduced into Section 7.3 of -08 has typos:
> 
>     OLD
>     ... and a Description of
>        "JSON Web Token (JTW) challenge type.
> 
>     NEW
>     ... and a Description of "JSON Web Token (JWT) challenge type."
> 
> 
>     (2) Lars's ballot
> 
>     ==[ snip ]==
>     In Section 7.1, you might want to include a specific "Note to the RFC 
> Editor"
>     instructing them on how to handle "[RFCThis]".
>     ==[ snip ]==
> 
>     Please add such text.
> 
> 
>     (3) Murray's ballot
> 
>     ==[ snip ]==
>     I suggest that Section 7.1 should explicitly reference "the ACME 
> Validation
> Methods sub-registry of the Automated Certificate Management Environment
> (ACME) Protocol registry group" or something like that.  Also, I concur with
> Francesca's suggestion regarding this section.
>     ==[ snip ]==
> 
>     Please explicitly name the registry in which the action described in 
> Section
> 7.1 will be performed.
> 
>     OLD
>        ... and a Description of
>        "JSON Web Token (JTW) challenge type.
> 
>     NEW
>     ... and a Description of "JSON Web Token (JWT) challenge type."
> 
>     (4) Eric's ballot
> 
>     ==[ snip ]=
>     -- Section 8 --
>     The first § explicitly request TLS (what about QUIC BTW) and the last § 
> is less
> specific as it only requests "MUST use confidentiality". Is there any reason 
> for
> this slight difference ?
>     ==[ snip ]==
> 
>     There appears to be confusion here between the communication channel
> between the Token Authority/ACME server (must be TLS) and entities/Token
> Authority (must provide confidentiality).  To prevent confusion for future
> readers, I recommend a reminder:
> 
>     OLD
>     Any protocol used to
>        retrieve Authority Tokens from a Token Authority MUST use
>        confidentiality to prevent eavesdroppers from acquiring an Authority
>        Token.
> 
>     NEW
>     Any protocol used to retrieve Authority Tokens from a Token Authority MUST
> use confidentiality to prevent eavesdroppers from acquiring an Authority
>     Token.  The details of this protocol are out of scope of this document.
> 
>     (5) Rob's ballot
> 
>     ==[ snip ]==
>        MUST support an HTTPS REST interface
> 
>     Is REST well defined enough to be an RFC 2119 MUST?  Does this need a
> reference to what constitutes a REST interface that would be compliant with
> this specification?
>     ==[ snip ]==
> 
>     I'm checking in with the ART ADs for a recommended reference.
> 
>     Regards,
>     Roman
> 
>     _______________________________________________
>     Acme mailing list
>     [email protected]
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!
> N14HnBHF!9HLx6Fi8xcLkGAbs73_BI3NTDi0l0_ZDFpicsoy6gqy4r2BZzmGvY9Khg
> _50t1pSkcskoTgsZeYkNHGIduh5$
> 

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to