Subject: [netconf] draft-ietf-netconf-trust-anchors, deleting or:system certificates

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 18 Nov 2019 09:06:17 +0000

Hi Kent,

The question that I would have asked:

In the examples in the draft-ietf-netconf-trust-anchors draft, there are examples of certificates that are "origin: system".  Should it be possible for clients to explicitly delete some of these certificates, and if so what mechanism/configuration would they use to achieve this?

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Mon, 18 Nov 2019 17:44:11 +0000

Hi Rob,

> In the examples in the draft-ietf-netconf-trust-anchors draft, there are examples of certificates that are “origin: system”.

As a quick recap, since it hasn't been discussed in awhile, the intention is to support built-in keys and trust anchors, which would have origin "system".

Inconsistently, the Truststore example shows "operational state" while the Keystore example shows "configuration" (though the paragraph preceding it mistaking says otherwise).  Perhaps two examples (one for each view) should be in both drafts.  It may be better to just have the configuration view in the main body while adding a new section to each draft discussing support for built-in values...

> Should it be possible for clients to explicitly delete some of these certificates

Maybe, but not likely for the driving use-cases:

 1) a TPM-protected key and its associated IDevID certificates
       - values persisted in hardware (the TPM)
       - values presented in Keystore

 2) any trusted-by-default certificates
       - values persisted in firmware/OS (can vary release-to-release)
       - values presented in Truststore

It may be that an implementation allows these values to be "removed" from <operational>, but it seems more plausible that operators would just NOT copy them into <intended>.

> , and if so what mechanism/configuration would they use to achieve this?

If possible at all, how such "deletions" are realized is outside the scope of these documents.   The new sections mentioned above, discussing the support for built-in values, could say this, but it might be better to not say anything.

Kent // contributor