Improve text around client cert profile

[thomas-fossati]

From MCR review:

Validation of client certificates (whether factory provisioned IDevIDs, or
locally enrolled LDevIDs) is a topic that I care a lot about, and
this text is inadequate.

As the (industrial) IoT market embraces IDevID certificates, there is some
concern that different markets will put different requirements on IDevID
contents.  So far it does not appear that anyone has created a situation
where a single (fat) IDevID certificate couldn't be used in a variety of
market verticals, the concern remains.

It was my intention to introduce a document about this issue. I think that
it's something that only the IETF can do.  Perhaps that would fit into this
UTA document, or perhaps parts of this section 15 goes into another document.

[mcr]

@mcr bread crumbs.

[OR13]

@mcr how can we make this issue more actionable?

Can you propose some text?

Are you asking for the section to be removed?

[mcr]

Re-reading -05, since it's been awhile.

• subjectPublicKeyInfo: should be made mandatory by this profile.
• Root CA Certificate: I don't understand why constraints on this, it's a trust anchor, not a certificate. As such, it needs to be marked with whatever capabilities are relevant, when the trust anchor is loaded into the trust store.
• subordinate CA: pathLenConstraint MAY be present, but you haven't said if it needs to be evaluated :-)
• EE extendedKeyUsage MUST be present and contain at least one of id-kp-serverAuth or id-kp-clientAuth IDevID, 802.1AR generally says that EKU should not be present, because IDevID SHOULD be as useful as possible, and EKU restricts useability significantly. This is a thing where generalized uses really beat out legal nonsense with EKU. ** But maybe you are trying to ail down the server certificate for a device that calls home, if so you need to say that

Avoid deep and complex CA hierarchies to reduce the number of subordinate CA certificates that need to be transmitted. I suggest you reference https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-00.html#name-number-of-levels-of-certification here.

Use session resumption to reduce the number of times a full handshake is needed. Use Connection IDs [DTLS-CID], when possible, to enable long-lasting connections. I have wondered whether some devices might initiate a TLS session in the factory, load a session resumption ticket valid for years to decades, and just ALWAYS use that.

Use client certificate URLs [RFC6066] instead of full certificates for clients. please also reference https://datatracker.ietf.org/doc/draft-ietf-dance-tls-clientid/

Whether to utilize any of the above extensions or a combination of them depends on the anticipated deployment environment, the availability of code, and the constraints imposed by already deployed infrastructure (e.g., CA infrastructure, tool support). too wishy-washy. Let's actually set some goals that people can code against, and that enterprises can specify that they want. (Section 18 is way more specific, and I like that)