[Sidrops] Re: Éric Vyncke's No Objection on draft-ietf-sidrops-signed-tal-15: (with COMMENT)

[Tom Harrison <[e-mail]>]

Hi Éric,

Thanks for your review.  Except where noted inline, your suggestions
have been applied as-is.

On Wed, May 08, 2024 at 01:24:04PM -0700, Éric Vyncke via Datatracker wrote:
> And a normative text specifying that *all* fields must be present
> (my guess) and rejection (?) to be executed for invalid objects
> (missing parts). Section 3.3 does not say whether parts are
> mandatory or optional (even if the implementer could guess).

Section 3.2 notes that the TAK object is defined per the module in
appendix A, and the module clarifies these points.  Section 3.3
requires that the decoded content conform to the format defined in
section 3.2, and if that condition is not met, the RP MUST ignore the
TAK object and proceed as though it were not listed on the manifest,
so I think the existing text addresses the concern here.

> ## Section 3.2.1.2
> 
> Where is the "#" in `The leading "#" character is omitted.` coming from ?

The RFC 8630 trust anchor locator format that this is based on
includes a leading '#' character in comments (see
https://www.rfc-editor.org/rfc/rfc8630.html#section-2.2)  To make
this clearer, the text has been updated from:

    The leading "#" character is omitted.

to:

    The leading "#" character that is used to denote a comment in
    [RFC8630] is omitted here.

> ## Section 4
> 
> When can the `SHOULD` in the first paragraph be bypassed ?

On looking at this again, this text doesn't really make sense under
the current model, so it has been removed.  (For the transition
process to work, TAK objects have to be published under both the
current TA key and the successor TA key, so there's no option with
respect to the successor.  With the predecessor, either it was
involved in a previous transition to a successor key, in which case it
must have a TAK object underneath it, or it wasn't, in which case it
won't.  (For reference, the original text was added in revision 02,
where it made sense due to the difference in the model at that time,
and was then retained in adapted form even after the model changed
quite significantly.))

> ## Section 7.2
> 
> s/key/public key/ in `This key MUST now be used to create a new CA certificate
> for this key` ?

This has been updated from:

    The TA can now generate a new key pair for key 'B'.  This key MUST
    now be used to create a new CA certificate for this key, and to
    issue equivalent CA certificates for delegations to child CAs, as
    described in Section 6.

to:

    The TA can now generate a new key pair for key 'B'.  The private
    key of this key pair MUST now be used to create a new CA
    certificate for the associated public key, and to issue equivalent
    CA certificates for delegations to child CAs, as described in
    Section 6.

Hopefully that helps to make things clearer.

> ## Section 11.1
> 
> In `old publication URLs simply fail to resolve`, it is unclear whether
> 'resolve' means 'DNS resolve' or something else.

It's intended generically, in the sense that there could be various
reasons why retrieval via that URL fails.  This has been updated from:

    It may be better in these instances to have the old publication URLs
    simply fail to resolve, so that the RP reports an error to its
    operator and the operator seeds it with up-to-date TAL data
    immediately.

to:

    It may be better in these instances for the TA to send error
    responses when receiving requests for the old publication URLs, so
    that the RP reports an error to its operator and the operator seeds
    it with up-to-date TAL data immediately.

An updated version of the document is attached for reference (includes
updates from secdir review and other IESG review), as well as a diff
from the previous version.

-Tom