Subject: [Acme] Robert Wilton's No Objection on draft-ietf-acme-authority-token-07: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 29 Nov 2021 03:32:15 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-acme-authority-token-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this.  I don't know much about ACME.  Hence only some minor
comments/suggestions.

1.  Introduction

   It enables administrative entities to prove
   effective control over resources like domain names, and automates the
   process of generating and issuing certificates that attest control or
   ownership of those resources.

   In some cases, proving effective control over an identifier requires
   an attestation from a third party who has authority over the
   resource,

I note that you use "identifier" in the first part of the sentence and then
"resource" in the second, and wanted to check that these shouldn't both be
"resource".

4.  Authority Token Challenge tkauth-type Registration

                                      In addition to helping to manage
   replay, the "jti" provides a convenient way to reliably track with
   the same "atc" Authority Token is being used for multiple challenges
   over time within its set expiry.

I found this sentence hard to scan/understand.

        {
    "protected": base64url({
         "typ":"JWT",
     "alg":"ES256",
     "x5u":"https://authority.example.org/cert"
        }),
    "payload": base64url({
         "iss":"https://authority.example.org/authz",
     "exp":1300819380,
     "jti":"id6098364921",
     "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","fingerprint":
     "SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50:
     9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"}
        }),
     "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
        }

The alignment of the rows of this JSON looks somewhat strange.  Aligning the
fields may make it more readable.

5.  Acquiring a Token

   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?

Thanks,
Rob