Hono: Support multiple trusted-ca objects in Tenant API

[pho-enix]

Tenant API should support multiple trusted-ca objects. This is needed for those use-cases:

• Within a tenant, devices with certificates from different CAs should be supported
• Key Rotation: If a CA certificate expires and a new one gets deployed, during a certain amount of time, both certificates should be accepted

I would recommend to change the data schema to something like:

"trusted-ca": [
  {
    "subject-dn": "CN=devices,O=ACME Corporation",
    "public-key": "aGFsbG8gT21hCg==",
    "not-before": "2015-01-01T00:00:00+0000",
    "not-after": "2025-01-01T00:00:00+0000"
  },
  {
    "subject-dn": "CN=devices,O=ACME Corporation",
    "public-key": "aGFsbG8gT21hMgo=",
    "not-before": "2024-01-01T00:00:00+0000",
    "not-after": "2034-01-01T00:00:00+0000"
  },
}

[boaks]

I would like to have at least the possibility to use a trusted-ca specific for an connector.
Especially, if "none-tls" connectors are in use, the may introduce their own "most common used" asymmetric variant, e.g. ECC for "coap over DTLS".

[Alfusainey]

@sophokles73 @pho-enix In the example above, the two trusted-cas have the same subject-dn i.e are issued by the same issuer. Is this right?

I was just wondering whether it is possible for two (or more) trust anchors to have the same subject-dn configured for a tenant?

[sophokles73]

@Alfusainey I do not see why not. In fact, the trust anchor itself is just the public key. The subject DN is simply the identifier that we use to determine the tenant.

[b-abel]

I would like to have at least the possibility to use a trusted-ca specific for an connector.
Especially, if "none-tls" connectors are in use, the may introduce their own "most common used" asymmetric variant, e.g. ECC for "coap over DTLS".

I'm trying to understand the requirements here.
@boaks Is it really necessary to restrict those specific trusted-ca to the corresponding protocol adapter? Or would it be OK to add it to the trusted-ca array?
Or is your point about the schema of such a specific trusted-ca? Maybe you can provide an example...

[Alfusainey]

@b-abel are you also working on this? I already started working on this issue and might file a PR for it this weekend :-)

[b-abel]

@b-abel are you also working on this? I already started working on this issue and might file a PR for it this weekend :-)

Didn't know that. But no problem, i haven't done anything substantial yet. I'll just move on to another topic :-)

[pho-enix]

/assign Alfusainey

[sophokles73]

I would like to have at least the possibility to use a trusted-ca specific for an connector.
Especially, if "none-tls" connectors are in use, the may introduce their own "most common used" asymmetric variant, e.g. ECC for "coap over DTLS".

@boaks Does this mean that you would like to be able to register a trust anchor per adapter type? FMPOV this would only make sense if we restrict the number of public keys in the trust anchor to 1. Otherwise we will still need to try each key in the set, which means that we could also stick with a single trust anchor (consisting of multiple keys), don't you think?

[boaks]

I have just no experience with "trust anchor (consisting of multiple keys)".

[boaks]

I would like to have at least the possibility to use a trusted-ca specific for an connector.
Especially, if "none-tls" connectors are in use, the may introduce their own "most common used" asymmetric variant, e.g. ECC for "coap over DTLS".

I'm trying to understand the requirements here.
@boaks Is it really necessary to restrict those specific trusted-ca to the corresponding protocol adapter? Or would it be OK to add it to the trusted-ca array?
Or is your point about the schema of such a specific trusted-ca? Maybe you can provide an example...

@b-abel

A little delayed:
When I wrote that comment, it was only possible to use one x.509 ca. per tenant. Without knowing about the "multiple keys trust anchor", that would end up in either RSA or ECC certificates for one tenant and it would have been not possible to use both for one tenant.
If the "multiple keys trust anchor" solves that in an other way, great.

[wklenk]

I also would like to vote for support of multiple trusted CAs per tenant. Reason is that our solution uses devices from multiple hardware manufactures. We cannot prescribe these manufacturers which root CAs to build their certificate chain on.

[sophokles73]

We cannot prescribe these manufacturers which root CAs to build their certificate chain on.

Just out of curiosity: who controls the provisioning of the client certs in this case? The HW manufacturer or the owner of the devices?

[wklenk]

As the client certificate (chain) is put on the device at the end of the manufacturing process, I think the manufacturer controls the provisioning of the client certificates.

[sophokles73]

Does this mean that if I buy such a device, then I have to trust the manufacturer to correctly set up a PKI and that I have no control over how the device authenticates to the Hono protocol adapter?

[wklenk]

Mhh, yes, you have to trust that the manufacturer sets up and operates his PKI in a reasonable way. As all manufacturers of this specific type of device are members of a consortium, there may be a set of rules and specifications to follow.
As an owner of the device, why should you be interested how the device connects to Hono (MQTT or HTTP)?

[sophokles73]

I can understand that you would not care much if you bought a solution from a provider which includes devices and the solution in the cloud that the devices are integrated with. The devices in that case would connect to the providers' back end and is therefore also responsible for making this as safe as possible.

However, if I buy devices from multiple vendors and want to integrate them with my own (or a third party's) back end, then I think that I will need to be able to provision credentials to the devices myself, wouldn't you agree?

Don't get me wrong, I am not strictly arguing for one or the other, my point is that I expect to find both cases in the real world and I am interested in a practitioner's point of view on it :-)

[sophokles73]

The whole idea of a trust anchor is to be able to validate certificate chains rooted at a given set of (trusted) public keys. When validating the chain, the trust anchor to use is chosen/set based on arbitrary criteria. The criteria used so far in Hono is: find the (single) public key that has been registered for a particular subject DN.

A common use case for having multiple public keys per tenant will probably be the roll over of trusted root certificates that have been used to sign device certificates. Originally, there will only be devices in the field having a client cert that has been signed using CA cert X. CA cert X is supposed to be used for e.g. 2 years. Towards the end of the lifespan of cert X, new devices being deployed in the field will thus contain a client cert that has been signed with CA cert Y, which will have a longer lifespan than cert X.

Based on that, it would be nice to be able to register both cert X and cert Y for the tenant. When a device's client cert is to be validated, the protocol adapter would look up the tenant based on the issuer DN in the client cert. The effective trust anchor to use for validating the cert chain should then consist of only those public keys that have been registered for the issuer DN and whose lifespan overlaps with the instant of time that the cert is validated at.

Note that several situations may occur:

• multiple CA certs with the same subject DN but different (maybe overlapping) lifespans are registered for a tenant
• multiple CA certs with different subject DN and arbitrary lifespans are registered for a tenant
• a combination of the above

In any case, it seems reasonable to store a CA cert's lifespan in the registry and use this information to determine the effective trust anchor when validating a client certificate.

The JSON structure proposed by @pho-enix originally would serve this purpose well, I suppose. However, if we adopt this proposal, then I would like to remove the option of passing an encoded cert instead of a public-key in the response of the tenant look-up so that the client can more easily determine the effective trust anchor.

@wklenk We currently have a constraint that no two tenants are allowed to have CA certs registered for the same subject DN. I wonder if this works for the use case that you have described where the devices' client certs are provisioned by the device manufacturer. What if two different tenants want to use devices produced by the same such manufacturer?

[Alfusainey]

The JSON structure proposed by @pho-enix originally would serve this purpose well, I suppose. However, if we adopt this proposal, then I would like to remove the option of passing an encoded cert instead of a public-key in the response of the tenant look-up so that the client can more easily determine the effective trust anchor.

@sophokles73: I just want to understand your point here..

don't you think that the client can still determine the effective trust anchor if the encoded cert is kept in the registry? the client can retrieve the valid trust anchors by checking all certificates that are valid at the point the tenant data is retrieved from the registry (since this check will only be done once upon retrieving the data).

This way, users have two options for configuring trust anchors for tenants:

1. Only providing the subject-dn and cert of each trusted-ca OR
   
   
   
   1. Providing the subject-dn, public-key, not-before and not-after properties of each trusted-ca
   
   

Or maybe I do not understand your point?

[sophokles73]

The client (i.e. the protocol adapters) should not bother with certs vs. public keys. We also already agreed that the client should not need to filter on the validity dates because that is already done by the Tenant service implementation. Thus, there is no need to transfer an encoded certificate to the adapter.
A manager of the content of the device registry might still be able to upload a certificate for a tenant. The Tenant service implementation may store the certificate in its encoded form or it may extract the subject DN, public key and validity period and store those. In any case, it will always only transfer those public keys and subject DNs to the adapters that are currently valid in response to a request from an adapter ...