[Spike] Rework trusted manufacturer checks.

[mmartinv]

Currently the Rendevouz server gets the list of the trusted manufacturer CAs from the trusted_manufacturer_keys_path variable within the config file and checks if the OwnershipVoucher's Manufacturer Public Key (OwnershipVoucher.OVHeader.OVPubkey) is in the list of of the trusted manufacturer CA certificates by extracting the pub key of each CA.

But according to the FIDO specification the OwnershipVoucher.OVHeader.OVPubkey is used for the verification of the first entry of the OwnershipVoucher.OVEntryArray only because it's just a public key, not a certificate:

OVEPubKey is the public key that verifies the signature on the next entry’s COSE Sig1 object. The first entry is verified by OVHeader.OVPubKey. This creates a signature chain from the Ownership Voucher header through each entry, to the last entry. The last entry’s public key verifies a signature created during the TO2 protocol, in the TO2.ProveOVHdr message.

To decide which manufacturer's CAs are trusted by Rendevouz server I think we should perform a verification of the OwnershipVoucher.OVDevCertChain instead, the same check as the Owner is supposed to do.

Also, it might be convenient to explore the possibility of adding support for disabling this check so the servers can trust any manufacturer.

(It seems that currently the RendeVouzServer already checks the OwnershipVoucher.OVDevCertChain and trusts all the certificates)

[mmartinv]

Also from the FIDO Specification (thanks @7flying for the heads up):

It is preferred that the Rendezvous Server has a basis on which to trust at least one public key within the Ownership Voucher. For example, the manufacturer who ran the DI protocol to configure the Device, thereby choosing the Rendezvous Server, may register public keys with the Rendezvous Server to establish such a trust. The Owner may register its own keys additionally, or as an alternative. An intermediate signer of the Ownership Voucher might act as a national point of entry, using its keys to establish trust for devices in the Rendezvous Server as they arrive in country.

A given Rendezvous Server MAY choose to reject Ownership Proxies that are not trusted.

If the Rendezvous Server has no basis on which to trust the Ownership Voucher, it must apply its own internal policies to protect itself against a DoS attack, but may otherwise safely provide the Rendezvous Server (i.e., it can allow the TO0 and TO1 Protocols to succeed). This behavior is acceptable because the TO2 Protocol is able to verify the to1d “blob” defined in this message. However, such a Rendezvous Server must ensure that untrusted Ownership Proxies cannot degrade the service for trusted Ownership Proxies. This may be accomplished through hard limiting of resources, or even allocating a trusted- and non-trusted version of the service.

So we actually need a way to trust at least one Public Key within the OV entries array.

We must bear in mind, though, that the specification says that those are Public Keys and not X509 Certificates and we are assuming precisely the opposite.

Also this behavior should be optional and the rendezvous server must have a mechanism to protect itself against not trusted OVs.

[7flying]

Also from the FIDO Specification (thanks @7flying for the heads up):

It is preferred that the Rendezvous Server has a basis on which to trust at least one public key within the Ownership Voucher. For example, the manufacturer who ran the DI protocol to configure the Device, thereby choosing the Rendezvous Server, may register public keys with the Rendezvous Server to establish such a trust. The Owner may register its own keys additionally, or as an alternative. An intermediate signer of the Ownership Voucher might act as a national point of entry, using its keys to establish trust for devices in the Rendezvous Server as they arrive in country.
A given Rendezvous Server MAY choose to reject Ownership Proxies that are not trusted.
If the Rendezvous Server has no basis on which to trust the Ownership Voucher, it must apply its own internal policies to protect itself against a DoS attack, but may otherwise safely provide the Rendezvous Server (i.e., it can allow the TO0 and TO1 Protocols to succeed). This behavior is acceptable because the TO2 Protocol is able to verify the to1d “blob” defined in this message. However, such a Rendezvous Server must ensure that untrusted Ownership Proxies cannot degrade the service for trusted Ownership Proxies. This may be accomplished through hard limiting of resources, or even allocating a trusted- and non-trusted version of the service.

So we actually need a way to trust at least one Public Key within the OV entries array.

We must bear in mind, though, that the specification says that those are Public Keys and not X509 Certificates and we are assuming precisely the opposite.

X509 Certificates are a standard way of defining public keys, and always have a public key inside of them, so, I think that in this case "X509 Certificate" can be used interchangeably with "public key".

Also this behavior should be optional and the rendezvous server must have a mechanism to protect itself against not trusted OVs.

[mmartinv]

X509 Certificates are a standard way of defining public keys, and always have a public key inside of them, so, I think that in this case "X509 Certificate" can be used interchangeably with "public key".

The specification states that it is not a certificate and it does not identifies the manufacturer (for manufacturer's protection I guess?) in any way:

A key pair for device ownership, which will be used to create device credentials in the device and the Ownership Voucher. This key pair does not specifically identify the manufacturer (e.g., it is not in a certificate) and may be changed from time to time, so long as the Device Credential refers to the same key pair as the Ownership Voucher for that device.

I agree that the most familiar way for all of us would be the manufacturer using a certificate to sign the first entry, putting the public key within the OV for verification and providing the certificate to the owner.

But that's not what the specification says. If the manufacturer wants to use random public keys for some device sets and provide those to the corresponding rendezvous servers (public keys don't expire while certificates do), it would remain conformant to the specification.

In this case, we wouldn't be able to verify those public keys as we expect certificates but we could workaround the problem by disabling the verification of the manufacturing servers.

Either way, I think this is not crucial for passing the conformance tests and we can revisit it later.