Skip to main content

RPKI Signed Object for Trust Anchor Key


Warren Kumari

No Objection

Erik Kline
Jim Guichard
Zaheduzzaman Sarker

Note: This ballot was opened for revision 15 and is now closed.

Warren Kumari
Deb Cooley
No Objection
Comment (2024-05-14 for -15) Sent
Thanks to Linda Dunbar for her valuable secdir review.

Nits, or just observations:

General:  This is just me, no action required (I am a PKI person, so I am pedantic on occasion).  I find the use of 'key' vice 'public key' to be a bit confusing.  There should be a distinction between 'private keys' and 'public keys' and the generic us of 'key' doesn't do that (in fact, I think most people think of 'key' as synonymous with 'private key').  I gather from reading this draft and poking around at the RPKI RFCs that the use of 'Key' is common terminology, so it would be confusing to change that now.  If there was ever an opportunity to clarify, it would be nice (maybe in the intro, para 2?).

Section 2, para 3:  This is confusing?  "... will first validate the TAK object, if present. ... If the TAK object lists only a current key....continues processing as it would in the absence of a TAK object.... if the TAK object includes a successor key... continues processing as it would in the absence of a TAK object."  Does processing of the TAK object happen elsewhere?  While other processing occurs?  If there is a TAK object, then why do you need the phrase 'continues processing as it would in the absence of a TAK object'?  

Section 7:  Thanks for this.  It wasn't clear to me just how many TAK objects would have to exist to move from a current to successor key.   This section helps clarify.
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment (2024-05-08 for -15) Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-sidrops-signed-tal-15

Please find documenting the handling of ballots.

All of the COMMENTS that follow are non-blocking.

## Well written draft nice to read providing sufficient context and information why decisions have been made
## addresses a true problem seen by the Resource Public Key Infrastructure (RPKI)

##classified as [minor] and [major]

121	   band way of notifying RPs of updates to a TAL.  In-band notification
122	   means that TAs can be more confident of RPs being aware of key roll
123	   operations.

a TA to be confident sounds as anthropomorphism. What does being more 
confident mean to a TA?

128	   its TA CA certificate.  This allows RPs to be notified automatically
129	   of such changes, and enables TAs to stage a successor key so that
130	   planned key rolls can be performed without risking the invalidation
131	   of the RPKI tree under the TA.  We call this object the Trust Anchor
132	   Key (TAK) object.

unsure if best terminology is key rolls or key rollovers?

144	   absence of a TAK object.  If, during the following validation runs up
145	   until the expiry of the acceptance timer, the RP has not observed any
146	   changes to the keys and certificate URLs listed in the TAK object,
147	   then the RP will fetch the successor key, update its local state with
148	   that key and its associated certification location(s), and continue
149	   processing using that key.

are there any timers that are implied during this process in which fetching 
a key should be successfull? WHat if not successful? any event logging or 
other tracking/notifications?

638	   turn, make debugging and similar more complicated.  A simple way of
639	   addressing this problem in a situation where the TA doesn't want to
640	   reissue the SubjectPublicKeyInfo content for the successor key that
641	   was withdrawn is to update the URL set for the successor key, since
642	   RPs must take that URL set into account for the purposes of
643	   initiating and cancelling acceptance timers.

I do not believe that "TA doesn't want to reissue" is correct. A TA can not 
truely 'want' anything. It is not human. It may be configured to reissue 
the SubjectPublicKeyInfo content though. Maybe the word 'prefer' is 
more correct and less anthropomorph
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-05-15 for -15) Sent
Thanks for the document. I have a few comments, which I hope may be helpful.

### Section, octothorpe, equivalence

   This field is equivalent to the comment section defined in section
   2.2 of [RFC8630].  Each comment is human-readable informational UTF-8
   text [RFC3629], conforming to the restrictions defined in Section 2
   of [RFC5198].  The leading "#" character is omitted.

What does the final sentence, about the omission of the octothorpe character, mean? Do you mean that the comment section varies from the referenced definition in RFC 8630, in that the octothorpe is not required? Do you mean something different? Maybe rephrase this to make it less ambiguous. 

Also, when you write “is equivalent to”, do you mean semantically equivalent? Do you mean syntactically identical? The same question applies to section

### Section successor

   This field contains the TA key to be used in place of the current
   key, after expiry of the relevant acceptance timer.

Shouldn’t this be “if applicable“, as in Section 7.2 implies it's optional, “It also issues a TAK object under key 'B', with key 'B' as the current key for that object, key 'A' as the predecessor key, **and no successor key**.” (emphasis added) What's more, it’s marked “optional” in the ASN.1. 

### Section 6

This section includes language such as “... ensure that they will reflect the same content at all times.” The clause “at all times” appears to offer a strong consistency guarantee, forbidding even vanishingly short windows of inconsistency during the staging of new content. Is it the authors' intent that even low-probability race conditions should be precluded? Is it the case that existing implementations already take whatever steps are necessary to prevent these?

(In light of the “multiple publication servers“ paragraph, I suspect the answer is "no".)
Murray Kucherawy
No Objection
Comment (2024-05-15 for -15) Sent
For the SHOULD in Section 4, what if I don't?
Paul Wouters
No Objection
Comment (2024-05-15 for -15) Sent
I am not an rPKI expert, so this might be a dumb question. If Key A generates its CA, and then lets its CA expire, or the expiration time is smaller than the acceptance window, is there a way to recover from this? The rules seem to say a new Key B cannot be created because it wouldn't be accepted ?
Roman Danyliw
No Objection
Comment (2024-05-15 for -15) Not sent
** Section 12.3.  Editorial.  There is a typo in the official name of the registry: s/Repository Name Scheme/Repository Name Schemes/
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2024-05-08 for -15) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-sidrops-signed-tal-15

Thank you for the work put into this document.

Please find below osome non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Russ for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status and uses the old template.

I hope that this review helps to improve the document,



# COMMENTS (non-blocking)

## Section 3.1

The wording `This document requests an OID for the TAK object as follows` is perfect in the IANA considerations section but not in the normative part. Suggest "This document specifies an OID..."

## Section 3.2.1 & 3.2.2

The reader will benefit of using a bullet list rather than tiny sub-sub-sections with a lead text.

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

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

## Section 4

When can the `SHOULD` in the first paragraph be bypassed ?

Should there also be a media type associated to `The filename extension of ".tak" MUST be used to denote the object as a TAK.`? It takes section 12.5 to discover the IANA request while it is an integral part of the specification IMHO, i.e., it should appear in this section 4.

## Section 7.2

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

## Section 11.1

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