[iot-wg] draft-richardson-t2trg-idevid-considerations (part 3)

    > pki-level: similar consideration here, 'deep' is a bit ambiguous. Not
    > sure what the EE level to evaluate actually implies of the integrity of
    > the trust anchors, it seems more a category for e.g. integrity and
    > privacy of 'software signing PKI' or whatever we want to call this one-
    > to-many devices relationship vs. the many devices to 'one' integration
    > target in identities.

It's supposed to be evaluated according to the PKI level section.

    > pki-algorithms: potentially include also the timespan they are
    > considered valid or in active use, cf. keylength.org - it makes a big
    > difference if you trust the lowest rung of security for the next
    > several decades or just a year or two.

Yes, I agree with you that the algorithms in use have best-before dates, but
since we are talking about anchor that is baked into the device, it will be
baked in with a specific algorithm and strength.

In some cases a software update can replace those anchors, in other cases,
there are operational processes (RFC7030 EST cacerts request) that could
replace/ update the anchors.

But, let's say that this is the self-signed (EE) anchor that is used to talk to the cloud
service (you commented on that was missing).  We could indicate when this
anchor is going to be replaced here, but how can we know for sure?

    > - potentially also could differentiate here between algorithms actually
    > used in the PKI vs. algorithms the device in general is capable of,
    > because if they are not used in the PKI (and that is more painful to
    > enumerate) then their appearance is mostly irrelevant or a sign of
    > compromise. The current formulation implies the device is able to
    > handle these algorithms but if they are not used in the PKI now or
    > tomorrow they are irrelevant.

Yes, this is a good comment, and I'll adjust it.

    > (Generally algorithm filtering in semi-closed systems is best achieved
    > by just not signing certificates that are worse, not so much at

Agreed, so I will change the above metric to be about what is supported,
rather than actually in use.

    > pki-level-locked: This formulation is unclear. I think what it means is
    > whether X.509 path level constraints are applied in the root and/or
    > below. It is most relevant for the online subCAs if they are "handed
    > around" as opposed to being centrally controlled, i.e. can the subCA
    > quietly sign another subCA.

Exactly.  It's not so much that it's quietly, it's whether or not the device,
when it has been operating with a level-3 PKI can deal with a level-4 PKI.

    > pki-breadth: maybe hard to answer and potentially largely irrelevant as
    > I can't see outside public web CAs anyone coming to wag a finger if a
    > vendor suddenly becomes super popular and issues certificates for an
    > exponentially larger number of end entities with a wider series of CAs
    > than initially deployed.

These are private PKIs, so their fingers can stay in their coat pockets :-)
What I care about is whether the database is going to die after 10
code signing keys have been issued.  Will they lose track of stuff?
I'm thinking about CRL and OCSP issues here.
Just tell us a bit about your planning.

Remember that for some situations, a single core laptop locked in a filing
cabinet is *just fine* to sign the three software updates issued a year for
your heat pump.  The goal is not the "highest" security, but rather
*appropriate* level of security.

    > All they really need to do is add storage
    > space. The load on an individual issuing CA is more interesting from a
    > few different points of view, than the capacity of the full and very
    > expandable PKI tree. Though of course there might be some actual
    > limitations in some management software implementations too.

If you think it's useless, I can remove it.

    > "pki-lock-policy:    can any EE certificate be used with this trust
    > anchor to sign? Or, is there some kind of policy OID or Subject
    > restriction? Are specific subordinate CAs needed that lead to the EE?"

    > It is unclear here what the first sentence means, 'to sign what'
    > basically. OID references are good. I would replace 'needed' with
    > 'required' or 'demanded' as they are often constraints of systems
    > rather than actual needs.

Consider an EE cert used for software updates.
Can any EE cert from the trusted CA sign software updates, or does it need to
be blessed in some way?


--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/iot-wg/attachments/20221102/45c735e4/attachment-0001.sig>