search

EntrustCorporation / draft-rats-pkix-evidence

An IETF Internet Draft specifying a standardized attestation evidence format intended for HSMs and other cryptographic devices
Other
1 stars 1 forks source link

Write a usecases section for the intro #1

Open ounsworth opened 3 months ago

optnfast commented 3 months ago

A few uses cases that come to mind:

  1. A Certification Authority receives a certificate signing request and wishes to verify that the subject public key was generated in an HSM (for example to satisfy CA/B Forum subscriber private key verification requirement). They may also wish to verify that the operations the HSM will allow for the corresponding private key are consistent with the purpose of the requested certificate.
  2. A user of a Cloud Service Provider's 'Bring Your Own Key' service wishes to transfer their locally-generated key securely to the CSP's service by encrypting it under the CSP's public key. As part of their due diligence on the CSP's key they wish to verify (1) that it was generated by an HSM and (2) may only be used to unwrap the key into an HSM (i.e. unwrap permission but not decrypt permission).
  3. An auditor of an identity provision service (or a competent end user) may wish to verify that keys representing end-user identities are held in an HSM and have permissions that are in line with the applicable regulations. For in example in the case of eIDAS, they may wish verify that the protection arrangements for assigned keys cannot be changed.

All of these can be done with a proprietary attestation scheme, but a standardized scheme would be expected to reduce the burden on relying parties, by allowing to cope with multiple HSM designs with a single verifier implementation. (They would still need to configure at least one trust anchor per HSM vendor.)

I'm sure there are more!

jpfiset commented 3 months ago

There is a use case where a manufacturer needs to perform an operation at a distance on one of its device. One of these operations could be a re-certification, where the manufacturer provides a certificate for a new key generated by the device.

The attestation from the device would provide enough information to the manufacturer to ensure that the manufacturer is emitting a certificate for a device previously manufactured by it.

This is very similar to a CA emitting a certificate for a public key. However, there must be claims to support the proper recognition.

Again, this could be accomplished using proprietary protocols. However, reusing common protocols and tools might lessen the burden of development and improve the security stance as it is widely scrutinized.

jpfiset commented 3 months ago

There is a use case where two devices are transferring keying material that requires identification. This identification could be based on application concerns (same domain, same realm, same customer, specific serial number).

In those circumstances, there is a need for a device to associate a transfer key with a device's attributes. The attestation protocol can be used to this end.

Again, this can be accomplished using a proprietary means. However, resources in HSMs are limited and there are gains to be accomplished by reusing the same protocol.

hannestschofenig commented 2 months ago

I added the use cases here: https://github.com/EntrustCorporation/draft-rats-pkix-evidence/pull/4