Hi RFC editor,
Thanks for your work on this document, much appreciated.
On Mon, Nov 25, 2024 at 01:30:19PM -0800, rfc-edi...@rfc-editor.org wrote:
> While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] Title
>
> a) Please note that abbreviations have been expanded in the title of this
> document per Section 3.6 of RFC 7322 ("RFC Style Guide"). Additionally, we
> have updated the title to use plural forms of "Signed Object" and "Trust
> Anchor Key". Please let us know of any objections.
>
> Original:
> RPKI Signed Object for Trust Anchor Key
>
> Current:
> Resource Public Key Infrastructure (RPKI) Signed Objects for Trust
> Anchor Keys (TAKs)
Looking at this again, the prior art here for documents defining new
RPKI signed objects is:
6482 A Profile for Route Origin Authorizations (ROAs). M. Lepinski, S.
Kent, D. Kong. February 2012. (Format: TXT, HTML) (Obsoleted by
RFC9582) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6482)
6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record.
R. Bush. February 2012. (Format: TXT, HTML) (Status: PROPOSED
STANDARD) (DOI: 10.17487/RFC6493)
9323 A Profile for RPKI Signed Checklists (RSCs). J. Snijders, T.
Harrison, B. Maddison. November 2022. (Format: HTML, TXT, PDF, XML)
(Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9323)
Suggested updated title:
A Profile for Resource Public Key Infrastructure (RPKI) Trust
Anchor Keys (TAKs)
> b) To match the updated title, may we update the short title as follows?
> This appears in the header of the PDF output.
>
> Original:
> RPKI signed object for TAL
>
> Perhaps:
> RPKI Signed Objects for TAKs
> -->
Based on the suggested title:
A Profile for RPKI TAKs
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->
security
cryptography
X.509
> 3) <!-- [rfced] To clarify this sentence, may we rephrase as follows and
> split it into two? If the suggestion below does not retain the original
> meaning, please feel free to suggest an alternative update.
>
> Original:
> This document defines an RPKI signed object for a Trust Anchor Key
> (TAK), that can be used by a TA to signal the location(s) of the
> accompanying
> CA certificate for the current public key to RPs, as well as the successor
> public key and the location(s) of its CA certificate.
>
> Perhaps:
> This document defines an RPKI signed object for a Trust Anchor Key
> (TAK) that can be used by a TA to signal the location(s) of the
> accompanying
> CA certificate for the current public key to RPs. The RPKI signed object
> can
> also signal the location(s) of the CA certificate for the successor public
> key.
> -->
The main use case for the TAK involves the successor key, and having
that in a separate sentence implies (IMHO) that it's a subsidiary
element of the specification. Suggested:
This document defines an RPKI signed object for a Trust Anchor Key
(TAK). A TAK object can be used by a TA to signal to RPs the
location(s) of the accompanying CA certificate for the current
public key, as well as the successor public key and the
location(s) of its CA certificate.
> 5) <!-- [rfced] To improve readability, may we simplify the text below as
> follows
> and split it into two separate sentences?
>
> Original:
> If, during the following validation runs up until the expiry of the
> acceptance timer, the RP has not observed any changes to the public keys
> and
> certificate URLs listed in the TAK object, then the RP will fetch the
> successor public key, update its local state with that public key and its
> associated certification location(s), and continue processing using that
> public key.
>
> Perhaps:
> During the following validation, if 1) the RP has not observed any
> changes to the public keys and certificate URLs listed in the TAK object
> and
> 2) the validation runs up until the expiration of the acceptance timer,
> the RP
> will fetch the successor public key. After the successor public key is
> fetched, the RP will update its local state with that public key and its
> associated certification location(s) and will continue processing using
> that
> public key.
> -->
The suggested text implies that there is a single validation run that
continues until the expiry of the acceptance timer, but in the usual
case there will be multiple validation runs, with each having to meet
the noted conditions. Suggested:
During the following validation runs up until the expiry of the
acceptance timer, the RP verifies that the public keys and the
certificate URLs listed in the TAK object remain unchanged. If
they remain unchanged as at that time, then the RP will fetch the
successor public key, update its local state with that public key
and its associated certification location(s), and continue
processing using that public key.
> 6) <!-- [rfced] Please review the artwork element in the XML file.
> Specifically,
> should it be tagged as sourcecode or another element?
> -->
Thanks, it should be 'sourcecode' instead:
<sourcecode type="asn.1">
id-ct-signedTAL OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 50 }
</sourcecode>
> 7) <!--[rfced] To clarify "with a view to the user", may we update this
> sentence
> as follows?
>
> Original:
> The RP MAY alert the user that these sets of certificateURIs do not
> match, with a view to the user manually updating the set of
> certificateURIs in their configuration.
>
> Perhaps:
> The RP MAY alert the user that these sets of certificateURIs do not
> match by showing a view of the user manually updating the set of
> certificateURIs in their configuration.
> -->
'with a view to' here is in the sense that the preceding action occurs
so that the user considers whether to manually update the set of
certificateURIs, rather than in the sense that some sort of user
interface view should be shown to the user. Suggested:
The RP MAY alert the user that these sets of certificateURIs do
not match. If this happens, the user may opt to manually update
the set of certificateURIs in their configuration.
> 8) <!-- [rfced] To improve readability and clarity, may we update the
> following
> sentence?
>
> Original:
> A non-normative guideline for naming this object is that the filename
> chosen for the TAK object in the publication repository be a value
> derived from the public key part of the entity's key pair, using the
> algorithm described for CRLs in section 2.2 of [RFC6481] for
> generation of filenames.
>
> Perhaps:
> A non-normative guideline for naming the TAK object is choosing a filename
> from the publication repository that is a value derived from the public key
> part of the entity's key pair using the algorithm described for CRLs in
> Section 2.2 of [RFC6481] for the generation of filenames.
>
> Or:
> Non-normative guidelines for naming this object are as follows: The
> filename is chosen using the algorithm described for CRLs in Section 2.2 of
> [RFC6481]. For the TAK object in the publication repository, the filename
> needs to be a value derived from the public-key part of the entity's key
> pair.
> -->
Suggested:
A non-normative guideline for naming this object is that the
filename be a value derived from the public key part of the
entity's key pair, using the algorithm described for CRLs in
section 2.2 of [RFC6481].
> 9) <!-- [rfced] To avoid using [RFC3779] as an adjective, may we rephrase the
> sentence below as follows?
>
> Original:
> As described in [RFC6487], the EE certificate used for this object
> must include an [RFC3779] extension.
>
> Perhaps:
> As described in [RFC6487], the EE certificate used for this object
> must include an extension from [RFC3779].
> -->
Suggested:
As described in [RFC6487], the EE certificate used for this object
must contain either the IP Address Delegation extension or the
Autonomous System Identifier Delegation extension [RFC3779], or
both.
> 10) <!-- [rfced] We are having trouble parsing the list below as is. For ease
> of
> the reader, may we rewrite the following unordered list as a paragraph?
>
> Original:
> If the successor public key passes verification, and the RP has seen
> that successor public key on the previous successful validation run
> for this TA:
>
> * if the relevant acceptance timer has not expired, the RP continues
> standard top-down validation using the current public key;
>
> * otherwise, the RP updates its current known public key details for
> this TA to be those of the successor public key, and then begins
> top-down validation again using the successor public key.
>
> Perhaps:
> If the successor public key passes verification and the RP has seen
> that successor public key on the previous successful validation runs for
> this
> TA, the RP continues standard top-down validation using the current public
> key
> if the relevant acceptance timer has not expired. Otherwise, the RP updates
> its current known public key details for this TA to be those of the
> successor
> public key and begins top-down validation again using the successor public
> key.
> -->
Thanks, the suggested text here is fine, save that 'validation runs'
should be 'validation run'.
> 11) <!-- [rfced] We have clarified the section reference in the following
> sentence. Please review to ensure the section number is correct.
>
> Original:
> A Relying Party may opt not to support the automatic transition of TA
> public key data, as defined in the previous section.
>
> Current:
> A Relying Party may opt to not support the automatic transition of TA
> public key data, as defined in Section 5.
> -->
This clarification is correct, thanks. (Just to avoid any doubt, the
section it refers to is 'Relying Party Use', which is section 5 in
-16, but section 4 in the current version of the document.)
> 12) <!-- [rfced] As "TAK" is expanded as "Trust Anchor Key", should instances
> of
> "TAKey" be updated to "TAK", or are "TAKey" and "TAK" different things?
> For example, will readers be confused since both appear in the sentence below?
>
> Original:
> A TAK object can also serve as a format for distribution of
> this data, though, because the TAKey data stored in the TAK object
> contains the same data that would appear in a TAL for the associated
> Trust Anchor.
> -->
"TAKey" and "TAK" are different things, so the existing text is fine.
> 13) <!-- [rfced] May we clarify what "that" refers to in this sentence?
>
> Original:
> This in turn
> means that the TA operator will be able to gain confidence in the
> correct functioning of the new public key before RPs are relying on
> that in their production RPKI operations.
>
> Perhaps:
> In turn, this
> means that the TA operator will be able to gain confidence in the
> correct functioning of the new public key before RPs are relying on
> the functioning in their production RPKI operations.
> -->
"That" refers to the new public key. Suggested:
In turn, this means that the TA operator will be able to gain
confidence in the correct functioning of the new public key before
RPs are relying on that public key in their production RPKI
operations.
> 14) <!-- [rfced] May we rephrase the following sentence to clarify "similar"?
>
> Original:
> If the unchanged successor public key is added back into the TA, such
> an RP will transition to using the new TA public key more quickly than
> other RPs, which may, in turn, make debugging and similar more complicated.
>
> Perhaps:
> If the unchanged successor public key is added back into the TA, such
> an RP will transition to using the new TA public key more quickly than
> other RPs, which may make debugging and similar processes more complicated.
> -->
This change is fine, thanks.
> 15) <!-- [rfced] References
>
> a) [X.690] references the 2002 version of ITU-T Recommendation X.690. This
> version has been superseded by a version released in February 2021. May we
> update this reference to the most current version?
>
> Current:
> [X.690] ITU-T, "Information technology - ASN.1 encoding rules:
> Specification of Basic Encoding Rules (BER), Canonical
> Encoding Rules (CER) and Distinguished Encoding Rules
> (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2002,
> 2002, <https://www.itu.int/rec/T-REC-X.690-200207-S/en>.
This change is fine, thanks.
> b) We note that the ASN.1 Module in Appendix A (under CONTENT-TYPE and
> SubjectPublicKeyInfo) contains references to RFCs 5911 and 5912, but these
> RFCs are not listed in the References section. Would you like to include
> them as Informative References?
> -->
Sounds good, thanks.
> 16) <!-- [rfced] This document has mixed usage of the expanded and abbreviated
> forms of the following terms. After they are expanded upon first use, may we
> replace all instances thereafter with the abbreviated form (per guidance from
> the Web Portion of the Style Guide at
> <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)?
>
> Relying Party (RP)
> Subject Information Access (SIA)
> Trust Anchor (TA)
> -->
Sounds good, thanks.
> 17) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed. Updates of this nature typically
> result in more precise language, which is helpful for readers. Note that
> our script did not flag any words in particular, but this should still be
> reviewed as a best practice.
> -->
I've reviewed the document per the above, and can't see any other
changes that are needed.
Some questions/suggestions about the edits that have been applied to
the document:
- In the abstract, the first instance of 'certificate' has changed
from singular to plural. I think the singular is preferable,
because a given TAL can be used to locate/validate only one CA
certificate. Could this change be reverted?
- In the first paragraph of the overview, 'In-band notification' has
been changed to 'An in-band notification'. The sentence is about
the concept of in-band notification in general, whereas the second
sentence makes it sound a little like it's about a specific
instance of such a notification. Could this change be reverted?
Alternatively, could it be changed to 'In-band notifications mean'?
- In the 'TAK Object Validation' section, the following:
The RP MUST NOT automatically update its configuration to use
these certificateURIs in the event of inconsistency, though,
because the migration of users to new certificateURIs should
happen by way of the successor public key process.
has been changed to:
However, the RP MUST NOT automatically update its configuration to
use these certificateURIs in the event of inconsistency because
the migration of users to new certificateURIs should happen by way
of the successor public key process.
Although the meaning is clear enough in context, the update could
be interpreted as meaning something like "the RP MUST NOT
automatically update its configuration to use these certificateURIs
in the event of inconsistency simply on account of the fact that
the migration of users to new certificateURIs should happen by way
of the successor public key process". Suggested:
However, the RP MUST NOT automatically update its configuration to
use these certificateURIs in the event of inconsistency. This is
because the migration of users to new certificateURIs should
happen by way of the successor public key process.
- In the 'Relying Party Use' section, there is a part beginning with
"If the TAK object includes a successor public key", where the
initial word in each of the subsequent list entries has changed,
e.g. from 'performing' to 'perform'. If 'by doing the following'
before the list is changed to 'by', can the list entries be
reverted as far as their initial words are concerned?
- In the 'Maintaining Multiple TA Key Pairs' section, the following:
(either the current public key, or the successor public key, once
the relevant acceptance timer has expired)
has been changed to:
(either the current public key or the successor public key once
the relevant acceptance timer has expired)
I'm not sure either formulation makes the intention clear, which is
that the successor public key is used once the relevant acceptance
timer has expired. Suggested:
An RP that can process TAK objects will only ever use one public
key for validation: either the current public key, or the
successor public key once the relevant acceptance timer has
expired. By contrast, an RP that cannot process TAK objects will
continue to use the public key details per its TAL (or equivalent
manual configuration) indefinitely.
- In the same section, the following:
If a TA uses a single remote publication server for its key pairs,
per [RFC8181],
has been changed to:
If a TA uses a single remote publication server for its key pairs
per [RFC8181],
which reads a little like 'per [RFC8181]' relates to 'key pairs',
rather than to the the publication server (not that the original
was completely clear in this respect either). Suggested:
If a TA uses a single remote publication server (per [RFC8181])
for its key pairs,
- In the 'Using TAK Objects to Distribute TAL Data' section, the
following:
When converting a TAK object, a Relying Party MUST include in the
TAL file any comments from the corresponding TAKey.
has been changed to:
When converting a TAK object, a Relying Party MUST include any
comments from the corresponding TAKey in the TAL file.
The meaning is clear enough in context, but it reads as though 'in
the TAL file' relates to 'the corresponding TAKey'. Although the
original formulation reads a little awkwardly, it's unambiguous in
this respect, so I think the original is preferable.
Alternatively:
If the TAKey that is being converted has comments, a Relying Party
MUST include those comments in the TAL file.
- In the 'Alternate Transition Models' section, the following:
Alternate models of TAL update exist
has been changed to:
Alternate models of TAL updates exist
Similarly to one of the earlier comments, the model is about the
concept of TAL update itself, rather than the individual TAL
updates that occur. Suggested:
Alternate models for TAL update exist
- In the same section, the following:
Additionally, these non-TA channels for distributing TAL data may
themselves rely on monitoring for TAK objects and then updating
the TAL data in their distributions or packages accordingly.
has been changed to:
Additionally, these non-TA channels for distributing TAL data may
themselves rely on monitoring for TAK objects and then update the
TAL data in their distributions or packages accordingly.
but the sense of the original is that the channel relies on both
"monitoring for TAK objects" and "updating the TAL data", rather
than relying on "monitoring for TAK objects" alone, which is how
the changed text reads to me. If the original doesn't work, then
suggested:
Additionally, these non-TA channels for distributing TAL data may
themselves monitor for TAK objects and then update the TAL data in
their distributions or packages accordingly.
- In the 'Acceptance Timers' section, the following:
A simple way of addressing this problem in a situation where the
TA operator doesn't want to reissue the SubjectPublicKeyInfo
content for the successor public key that was withdrawn is to
update the URL set for the successor public key, since RPs must
take that URL set into account for the purposes of initiating and
cancelling acceptance timers.
has been changed to:
A simple way of addressing this problem in a situation where the
TA operator doesn't want to reissue the SubjectPublicKeyInfo
content for the successor public key that was withdrawn is to
update the URL set for the successor public key since RPs must
take that URL set into account for the purposes of initiating and
cancelling acceptance timers.
which reads awkwardly to me. Suggested:
A simple way of addressing this problem in a situation where the
TA operator doesn't want to reissue the SubjectPublicKeyInfo
content for the successor public key that was withdrawn is to
update the URL set for the successor public key. Since RPs must
take that URL set into account for the purposes of initiating and
cancelling acceptance timers, an RP that observes a change to that
URL set will cancel any existing acceptance timer it has and
initiate a new acceptance timer in its place.
- In the 'TA Compromise' section, the following:
While it is possible for a malicious actor to use TAK objects to
cause RPs to transition from the current TA public key to a
successor TA public key, such action is predicated on the
malicious actor having compromised the current TA private key in
the first place, so TAK objects do not alter the security
considerations relevant to this scenario.
has been changed to:
While it is possible for a malicious actor to use TAK objects to
cause RPs to transition from the current TA public key to a
successor TA public key, such action is predicated on the
malicious actor having compromised the current TA private key in
the first place; thus, TAK objects do not alter the security
considerations relevant to this scenario.
The change highlights that the original text could have been
clearer. Suggested:
While it is possible for a malicious actor to use TAK objects to
cause RPs to transition from the current TA public key to a
successor TA public key, such action is predicated on the
malicious actor having compromised the current TA private key in
the first place. Since a malicious actor who has compromised the
current TA private key has complete control over the TA anyway,
TAK objects do not alter the security considerations relevant to
this scenario.
- In the 'Alternate Transition Models' section, the following:
Transition by way of an in-band process reliant on TAK objects is
not mandatory for TAs or RPs, though the fact that the TAK objects
are verifiable by way of the currently-trusted TA public key is a
benefit compared with existing out-of-band mechanisms for TA
public key distribution.
has been changed to:
Transition by way of an in-band process reliant on TAK objects is
not mandatory for TAs or RPs, though the fact that the TAK objects
are verifiable by way of the currently trusted TA public key is a
benefit compared to existing out-of-band mechanisms for TA public
key distribution.
('compared with' -> 'compared to'). I think 'with' is preferable
here, since this is about highlighting differences between the two
mechanisms, rather than similarities (per section 5.250 of CMOS
17th edition).
- In the same section, the following:
TAs are required to ensure so far as is possible that for the
purposes of RPKI validation, it makes no difference which public
key is used.
has been changed to:
TAs are required to ensure, so far as is possible, that there is
no difference which public key is used for the purposes of RPKI
validation.
This reads awkwardly to me. Suggested:
TAs are required to ensure, so far as is possible, that RPKI
validation outcomes are the same regardless of which of the two
keys is used.
- There are three instances where colons have been changed to
semicolons (in the sections 'Maintaining Multiple TA Key Pairs',
'Phase 3: Update TAL to point to B', and 'Relying Party Support'),
but the usage in the original seems to me to fall within the
guidance of section 6.61 of CMOS 17th edition ("to emphasize that
the second clause illustrates or amplifies the first"), so is it
possible to revert those?
-Tom
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
