[T2TRG] Last polish review of draft-irtf-t2trg-taxonomy-manufacturer-anchors

[Sini Ruohomaa <[e-mail]>]

Hello, T2TRG, 

Apologies, I realized I seem to not have ever successfully received the
replies back in 2022, I finally saw them now in the web archive but
have written the review below prima vista on just the current document
version, as I only emerge from the barrel I live in usually on rare
occasions such as this. ;)

Thank you for this draft. It provides a concrete informational
exploration of initial device identity certificates as witnessed in
their natural habitats, and an excellent public reference for comparing
different approaches taken. I am additionally always happy to see RFC
7168 and mnemonic produce in good use, and close proximity to origin
manufacturing seems particularly appropriate. :)

I have very minor comments that I compensate for by a large number,
while regretting the late timing of the feedback. Most of the below is
typographic notes for your consideration, coming from non-native
speakers with at least level 3 grammatical special interests.

Onwards!

In the context of the introduction, if so desired, one might also
mention our personal telecom equipment favourites, the 3GPP-specified
Vendor Credentials. The design pattern is similar to IDevID; TS 33.310
can be referred to for more information.

It is slightly confusing to a literal mind to see in 1.1 a list of
hyphenated terms, many of which are not in fact hyphenated.

Enclosing "The TAM is a piece of software (...)" in parenthesis in 2.1
seems unnecessary.

In 3, I disagree with "authorizations implicitly attached" when
discussing the nature of trust anchors, due to the access control
meanings attached to the word "authorization". Generally in access
control, the presence of a signed certificate should definitely not
imply authorization, but authenticity and to some degree origin, and
confusion about this leads to security mishaps. Authorization should be
attached to a specific identity represented by the certificate, not the
presence of one; this way authorization can be added and revoked
without modification of the certificate. Or in other words, trust
anchors carry trust about what/who a public key is representing, but I
can locally still decide what I do with that information (in
software): is Alice getting in or not with her certificate depends on
policy, but the certificate allows us to tell her apart from Eve and
Melissa. I try to use the term 'trust' in this context over
authorization to avoid this conceptual collision, but 'authenticity
protection' or some more technical term could also be considered. The
term is mentioned also in the list item 2 in section 3.

In the sixth paragraph of section 3, a "on" may be missing after
"based".

In list item 4 in section 3, there may be a 'd' missing from "associate
private key".

A period may be missing after [leakedmsikey] and at the end of section
3.2. An extra space may be present in 3.4 "web sites". 

In 3.1, it may be considered to point out explicitly that extremely
controlled modification to a key the attacker controls is generally the
desired target (integrity vs. availability attack), lest the reader
wonder about replacing the close-proximity gamma ray attack with a
sharp tap with a hammer and a nail to similarly render a device
unbootable. 

In 3.8, an 'and' may be missing in the last sentence after 'operator'.

In 4.1, it is proposed that IDevID could be used to decrypt software
updates. I cannot recommend this approach, as using the same RSA key
both for decryption and signatures is generally considered a security
issue - among other things because the usage pattern of signing and
decrypting is different (you sign what you generate or trust yourself,
but decrypt external information you usually do not trust, and as the
decryption operation is using the same trapdoor function as signatures,
you "sign whatever you decrypt" to extensively simplify). Additionally,
NIST has deployed new quantum resistant key agreement algorithms in KEM
form only, which means that dual-use keys are in practice a thing of
the past. I would definitely recommend to provision a separate key for
decryption purposes.

In section 4.1.1, a comma may be missing after 'However' in the third
paragraph, and an extra space may be present in "can not" in the
seventh paragraph (this repeats also elsewhere in the document). In the
last paragraph, "manufacturers'" may be intended as "manufacturer's". A
comma may be missing after "a light bulb" and "airplanes".

In 4.1.2, "Certification Signing Request" is maybe intended as the more
commonly used "Certificate Signing Request" (RFC 2986 speaks of PKCS#10
as certification request, and for example RFC 9646 of Certificate
Signing Request, CSR).

In section 4.1.3, "256-bits" seems to have inadvertently captured one
of the hyphens left over by the hyphenated terminology section and
should maybe release it. 

In the third paragraph of the same section, "then is" maybe should be
"is then".
 
It is worth noting that the component manufacturer has their own
manufacturing line and likely needs to plant the seed into their
component there, so it will in that sense be exposed to a physical
factory (paragraph 7 in 4.1.3), just a different one, so while this is
explained in the further paragraphs the statement is locally confusing
here. The comparison to a carrot as a biennial plant is very apt.

It would seem that once the private key management is delegated to the
component manufacturer, it would also make sense to outsource
certificate issuance and its complexities to them. If the device
manufacturer only receives the public key of the chip in a signed
certificate embedded with relevant metadata to identify which key is
which, they can extract the public key (or get an associated ready
self-signed CSR together with the certificate) to issue their own
certificates and never need to deal with the seed and private key
security. (It is possible that this is even the intended message all
along, but in the paragraphs 9-11 it seems that we are talking about
the second year of the carrot, not the first. Related, it should be
noted that both actors are in fact manufacturers so '(the)
manufacturer' alone in those paragraphs is ambiguous.) 

One reason to not do this and risk compromise of private key material
in transit is when the seed can be used as ground input to generate a
number of different keys, not all of which the silicon provider can or
needs to invent beforehand. This provides several angles of
cryptographic agility but also does add the security headaches of
having to ship around symmetric secret key material across
organizations. It may be worth mentioning out loud that the PRNG
generated key pair does release us from the pre-installed key
strictness as the key that is generated can be chosen more flexibly.

In 4.1.4, is the reason that using a discrete TPM turns a squash into
an avocado that our security boundary for the purposes of this model
changes from the device (on-whole-device, using secure element) to the
TPM (on-TPM, using itself, as opposed to on-whole-device, using TPM)?

In 4.1.5, list item 1, "suppliere" maybe has an excess 'e'. In the
fourth paragraph, "But," is maybe intended as "However,". In the second
last paragraph, "Not that" is maybe intended as "Note that". The
exclamation marks in paragraphs 1 and 5 are surprising and maybe not
needed.

The addendum about a inventory specific to for each client maybe
applies also to the carrot seed shipping model, unless the intention is
to say that the inventory must be long-lived for CA operation purposes,
while the carrot model seeds can be deleted as the responsibility is on
the second-year manufacturer.

In section 5, "doing enrolment" (or enrollment) is maybe best expressed
as "performing enrolment" or simply directly "mechanisms of enrolment".

In case of multi-level certification authorities in paragraph 3, would
not the operating rules be clarified in the certification policy (CP)
and certification practices statements (CPS) of the CAs (RFC 3647)?
Assuming, of course, that the CAs follow the RFC.

In the 7th paragraph in section 5, possibly "public/private key pair"
should be in plural since the identities are, although this is not
technically necessary as attackers, bless their heart, are not required
to maintain appropriate opsec posture.

In the 8th paragraph, "which it is not authorized to do so" should
probably end "to sign". CRLs could be explicitly mentioned here as a
local technical recovery mechanism, while high-visibility process
failures such as the one cited at Comodo seriously undermine the trust
in any public CA. (CRLs only come up as a new item two paragraphs later
as a part of a validation authority failure pattern.)

Section 5.2 third paragraph has a surprise capitalization of
"Ceremony".

In the last paragraph of 5.3, which mostly speaks of CAs, steps to the
side about signing code releases, which are typically not signed as a
certificate but by an end entity key that has a certificate. It may be
best to keep CA signing of certificates and code signing conceptually
separate. 

In the same paragraph, the mitigation of a "compromise between
situations" is maybe technically not a mitigation of a compromise but
e.g. "To address the conflicting needs, some levels of the PKI may be
kept offline, and some levels online." This division is mentioned at
the end of 5.1 as well.

In section 5.3 "deals with attacks" is maybe a bit ambiguous since 5.2
is about protection levels, not defenses as such; a more "direct"
though wordier expression might be "The protections discussed in the
previous section aim to thwart attacks". 

In the same paragraph, a comma may be missing after "undetected".

Technically, the devices are not the source of the danger if the
attacker has access to CA private keys. The danger comes from the
"intended-untrusted" devices (and non-device processes) that are NOT
the devices with real certificates, but fake certificates, that are
attacker controlled. 

Section 5.3 repeats much of the disaster pattern identification
material in the introductory part of Section 5. Some of those could be
potentially merged.

In the fifth paragraph of 5.3, generalize "forgets a password" to "CA
key staff lose access to authentication secrets, such as a password",
as CAs (hopefully) do not generally operate on password protection.
Incapacitation seems sufficient to mention here, since staff dying can
in a secular world view be considered a special case of it.

In the sixth paragraph, "deals with" could be replaced with "addresses
the risk of" (physical damage).

In the seventh paragraph: suggest replacing "becomes: how are the
backups unlocked, or activated" with "becomes how the backups are
unlocked or activated." This section could potentially be condensed
slightly as its style includes quite a few question marks and a
detective story style which departs from the earlier tone of the
document.

If there is a reference available for the DNSSEC Root anecdote, that
would be an interesting addition.

5.3.1 a more commonly recognized name of the Shamir scheme seems to be
"secret sharing" as opposed to splitting. It may not be necessary to
describe here as it gets quite specific, but I see no harm in it. I
recommend not underlining staff death here too, as readers may find it
overly dramatic. Incapacitation is sufficient for a key executive to
not be motivated to prioritize coming to work to unlock keys on that
particular day.

In the 7th paragraph fo 5.3.1, "However" should probably be followed by
a comma in this kind of use. 

The #1 benefit of secret sharing as opposed to simply backing up the
secret to multiple executives is omitted: unlike secret copying, the
scheme tolerates at most k-1 executives to become corrupted.

The speculation for handling a code signing key at the end of 5.3.1
with a secret sharing scheme seems unnecessarily elaborate, refer to
the earlier mention of staff inventing workarounds when their work is
too hard.

In section 6.1, sentences formed as a question could be reordered to
not need a question mark (which is missing), for example "how far does
a board travel" should end in a question mark, but "how far a board
travels" does not need one (first-second-stage-gap). Others in e.g. 6.2
have question marks but maybe could be reorganized.

In 6.2, "n-components" has captured an extra hyphen. 

identity-shared-split-continents may be an unnecessary pattern for any
organization that is not international across continents. 'Sites' may
be more general-purpose.

As an ultimate meta nitpick, section 9 maybe "provides" should be
"provided". ;)

Thank you again for this work! As noted the above list is just for
consideration.

Best regards,

--Sini