Re: [Acme] AD review of draft-ietf-acme-authority-token-05

["Peterson, Jon" <[e-mail]>]

Hi Roman,

Thanks for the thorough review, and sorry for the delay...

We've posted a new version of the draft, which tries to put a dent in some of your concerns.

    > > >
    > > >     ** What is the intended status of this document? The document
    > > > says Informational; the datatracker and the shepherd's report says
    > > > Proposed Standard.  TnAuthlist is PS.  These four places need to be
    > consistent.

We've moved this to PS.

    > > >     ** Are there implementations of this document?  The rough
    > > > history in ACME seems to have been PS should have implementation
    > experience.
    > > > Is the link to STIR decisive here (to make it PS)?

We hope this will get some use with STIR deployments, yes.

    > > >     ** ID-Nits reported the following issues with references being
    > > > listed but not
    > > > used:
 
We divided references into normative and informative, and nuked ones that seemed particularly superfluous (including say acme-telephone).

For the most part, the new version incorporates your proposed changes to the text throughout (and hopefully it's a little better editorially). There are only a few cases where this warrants a bit more comment:

    > > >
    > > >     ** The tkauth-type="atc" type doesn't seem to describe all of
    > > > the required information described by Section 3.1 - 3.3 and Section
    > > > 9 (Security
    > > > Considerations) as being needed for a token format.  Specifically:
...
    > > > Perhaps this section is spelling out
    > > > requirements for both of those collectively?  If so, this should be
    > > > explicitly stated (perhaps in the intro to Section 3, reminded in
    > > > Sections 4 and
    > > 9).

We've taken the tack you suggest above of clarifying that this requirements need to be satisfied by a combination of authority-token and its tkauth subtypes.

    > > >
    > > >     ** Section 3.  The text notes that authority tokens can be used
    > > > for ACME challenges, but this document doesn't add a new challenge
    > > > type to the "ACME Validation Methods" registry.  Section 6 provides
    > > > an example using token- tnauthlist which seems to suggest a
    > > > type="tkauth-01", but that isn't specified in
    > > > draft-ietf-acme-token-tnauthlist
    > > or this document.

That's fixed, and hopefully overall the IANA considerations are a bit cleaner.
    > > >
    > > >     ** Section 3.1.  Per "... future specifications must indicate
    > > > how a token conveys to the CA the name(s) ...", is there a reason
    > > > this isn't a normative MUST?

As a matter of specmanship, I try to use normative language to constrain what implementations do, not what future specifications do. I understand opinion is divided on the subject.

    > > >     ** Section 3.2.  Per "an Authority Token could attest to all of
    > > > the resources that the client is eligible to receive certificates
    > > > for", couldn't this leaks information to a CA, if that single CA is
    > > > not
    > > responsible for all of the scopes?

Added a little text about that.

    > > >
    > > >     ** Section 4.  What would be the circumstance where the x5u/iss
    > > > would not equal the token-authority?

I don't know if we have an existing case where it does, but it is at least conceivable. If you feel super strong about it, we can cut it.

    > > >
    > > >     ** Section 4.  Should the values of tktype be constrained to the
    > > > IANA "ACME Identifier Types" registry?

This is another one where I don't have a super strong feeling... it would certainly be helpful if it were, but it doesn't seem like it's worth normative language to that effect.

    > > >
    > > >     ** Section 4.  The example in this section is missing the full
    > > > payload/protected /signature structure to show the actual binding
    > > > provided by the server

We added that, but we're basically punting examples to tnauthlist in this version of the draft otherwise.

    > > >
    > > >     ** Section 5.  This token acquisition protocol seems underspecified:
    > > >     -- How does the client authenticate/do authorization with the
    > > > HTTPS
    > > server?

I think the precise security used by a web service is not in the scope of this as such... if you feel we need to flesh that out substantially, let us know.

    > > >
    > > >     -- Is there any semantics to the resource locator to make for an
    > > > interoperable/discoverable URI?

I don't think that's particularly necessary, but if you feel otherwise, let us know.

    > > >
    > > >     -- Does the client get to request a scope?

Yes, I hope that's clear.

    > > >
    > > >     ** Section 5.1.  It might be useful to show a full server
    > > > response example given a particular client request

Again, punting the examples to the tnauthlist draft, since basically a concrete example requires all the stuff defined in tnauthlist anyway, to your point here:

    > > >
    > > >     -- How is error handling managed with the HTTP error code?  The
    > > > TnAuthlist draft actually specifies this behavior more that this
    > > > base
    > > document.
    > > >
    > > >     -- Section 5.  Shouldn't a successful response from a Token
    > > > Authority return a body of type "application/jwt" if an "authority
    > > > token" is being returned per Section 4?

tnauthlist has it as we do here; just keeping alignment with that.

    > > >
    > > >     ** Section 8.  This text registers "atc" as an ACME identifier.
    > > > When and how is that used?  I thought that identifier profiles
    > > > specified an identifier and that the atc what the challenge/verification type.

This was a point of misalignment with tnauthlist; we've rectified that by deleting this "atc" ACME identifier.

    > > >
    > > >     ** Section 8.  Is there a reason that the "atc" claim from
    > > > Section
    > > > 4 not being registered in the "JSON Web Token Claims" registry?

Added.

    > > >
    > > >     ** Section 8.  Per the registry of "token types", there don't
    > > > seem to be enough details here:

We tried to clean this up as well.

Again, thanks for the review, and let us know what we should still be fixing in here.

Jon Peterson
Neustar, Inc.