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.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
