Need clarity on trust_bundle structure in certz.proto

[Devendra-Vamsi]

I have following questions regarding the trust_bundle mentioned in certz.proto.

1. trust_bundle is mentioned to be a single CertificateChain, instead shouldn't it be multiple CertificateChains or just a bundle of certificates? The reason I am saying that is, consider the case of two gnsi clients:

   • client1 with it's certificate as client1_cert which is issued by RootCA1. client1_cert <--- RootCA1
   • client2 with it's certificate as client2_cert which is issued in the following way: client2_cert <--- InterCA2 <--- RootCA2
   • For both the gnsi clients to be able to connect to Target, the SSL profile which is being used by Target should contain both RootCA1, InterCA2 and RootCA2 as part of it's trust_bundle. But from the current trust_bundle definition either RootCA1 or (InterCA2<---RootCA2) can be present in the SSL profile, so only one of those clients can connect to Target at any point of time. I think in a general situation, at any point of time the Target should be able to connect with various gnsi clients which have certificates issued by different independent Root/Intermediate CAs.

2. Can a SSL profile contain more than one trust_bundle? From https://github.com/openconfig/gnsi/blob/main/certz/certz.proto#L80, it appears that only one trust_bundle is supported, but there is a possibility to mention multiple trust_bundle entities in a single UploadRequest, in that case which trust_bundle should the Target install if SSL profile should contain only 1 trust_bundle?

[morrowc]

I have following questions regarding the trust_bundle mentioned in certz.proto.

hey there! I think you're really asking: "Hey, isn't there supposed to be some sort of 'featureprofile' test set for this??"

yup, there sure is... and that's this:
openconfig/featureprofiles#1563

that's been taking me a bit to finish up and ship :( but you can get an idea of the trust_bundle and
expectations surrounding it.

The comments in the proto file do say:
"// The trust bundle (a chain of Certificate Authority certificates) can be
// used to validate client's certificates."

so I think the intent is as described in the link above AND as described below.

1. trust_bundle is mentioned to be a single CertificateChain, instead shouldn't it be multiple CertificateChains or just a bundle of certificates? The reason I am saying that is, consider the case of two gnsi clients:

   • client1 with it's certificate as client1_cert which is issued by RootCA1. client1_cert <--- RootCA1
   • client2 with it's certificate as client2_cert which is issued in the following way: client2_cert <--- InterCA2 <--- RootCA2
   • For both the gnsi clients to be able to connect to Target, the SSL profile which is being used by Target should contain both RootCA1, InterCA2 and RootCA2 as part of it's trust_bundle. But from the current trust_bundle definition either RootCA1 or (InterCA2<---RootCA2) can be present in the SSL profile, so only one of those clients can connect to Target at any point of time. I think in a general situation, at any point of time the Target should be able to connect with various gnsi clients which have certificates issued by different independent Root/Intermediate CAs.

yup! it's really a big set of certificates from the various CAs in use.
(or you should plan on it being a big set of certs)

2. Can a SSL profile contain more than one trust_bundle? From https://github.com/openconfig/gnsi/blob/main/certz/certz.proto#L80, it appears that only one trust_bundle is supported, but there is a possibility to mention multiple trust_bundle entities in a single UploadRequest, in that case which trust_bundle should the Target install if SSL profile should contain only 1 trust_bundle?

I'd lean to either:

1. error on more than 1 trust-bundle being sent in a single UploadRequest
   (this is probably safest, really: "There's a trust_bundle, not trust_bundleS sorry dude")

2. concat the trust-bundles together.
   (this seems like it might work, but means you need to be a bunch more careful about handling on both sides)