Sign responses

[bwesterb]

Do we want the MPIC service to sign its responses as evidence.

[sciros]

Depends on the anticipated client-service relationship(s) it'll support. At the moment I believe the open-mpic spec and implementation effectively assumes that it's to be deployed and maintained by the same organization that is acting as the client (i.e. a CA is using it for its own MPIC), then its effectively a service within that org and signing the responses doesn't add much in the way of trust (I think), especially if there are service logs available and accessible by the organization.

If we want the API to be crafted to support a client-service relationship where the API is basically externally facing (and I suppose that's the most practical reason to have a "standard" API at all, for there to be multiple externally available MPIC APIs hosted by, e.g., Cloudflare, etc.) then I think it's a valid question as to whether traceability and non-repudiation have a place in this. Perhaps there can be a kind of "mode" (configuration) under which the API is expected to be deployed -- externally facing, in which case a whole set of additional specification applies, or internally facing, in which case things are slightly simpler. Just thinking out loud.

[birgelee]

I think signed responses might be helpful particularly if it is third party run. This could remove any suspicion on the part of the CA and immediately show that the CA called the API. I like moving more towards CA accountability and transparency and if a CA saves its API responses with signatures, we no longer need to trust the CAs word that they did MPIC, there is now an unquestionable log.

[bwesterb]

I agree with the upsides. There is also a clear downside: signing responses requires a key that needs to be kept secure, and might be rolled once in a while.

[birgelee]

Would it be out of the question to make signed responses optional? I personally think it makes a lot more sense in the CloudFlare case than Open MPIC. In Open MPIC CAs operate their own APIs so they would have access to the signing key, significantly reducing the value of signed responses.

[sciros]

I personally believe that this should be optional. It has value for SaaS API deployments. It doesn't really for self-hosted deployments. I feel like open-mpic implementation would not implement that part of the API since it's not trying to enable a SaaS model.

[bwesterb]

Optional sounds good. I'd like to suggest to punt this to after the initial draft.

(There is of course a relation with #4: if in practice OpenMPIC users are using self-signed certificates or pinning, then we could do this instead, as it's essentially shouldering the same downsides.)

[gcimaszewski]

Including the signing functionality will likely make the implementation even more cloud provider-specific - the signing keys would need to be stored and accessed through a key management or secrets storage service, and AWS alone offers several of them. This would probably also need more discussion for how the signing key is decided on, administered, and rotated (especially if the signatures are intended to serve as a transparency log). I would vote on omitting it from an MPIC draft, but I do think the idea of creating a verifiable log that MPIC was performed is super interesting.

[SulemanAhmadd]

I think signed responses will be great for transparency and accountability. CAs can use the signatures to validate that they used a specific MPIC operator.

@gcimaszewski comments do resonate though. There is an additional consideration on how to discover the MPIC public keys. We can keep it out of the first iteration as a requirement but recommend in the considerations.

[TheEnbyperor]

[speaking with my Max-Planck Institute for Informatics hat on here]

I think signing responses with this is an absolute must. TLS provides message integrity and confidentiality guarantees, but does not provide long term non-repudiation. A general goal of WebPKI infrastructure is to be able to detect (and possibly blame) mis-behaving parties.

On the specifics how to achieve this I'm less certain. RFC 9421 HTTP Signatures seems like exactly what would be needed, and already exists within the IETF ecosystem. For this protocol we could define the keyid to be a URL to an X.509 with a new mpicServerCertification EKU. The SAN of that certificate can then bind the MPIC response to a domain as the MPIC provider's identity.

If we go down this route with X.509 certs then a mpicClientAuthorization EKU could also be used to solve #2.

I'm open to suggestions for better ways to do this, but I'm not willing to accept that non-refutable signatures aren't a core part of this protocol.

[bwesterb]

I'm open to suggestions for better ways to do this, but I'm not willing to accept that non-refutable signatures aren't a core part of this protocol.

With ACME, the subscriber doesn't sign the challenge with a non-refutable signature.

I think it's good to reason in concrete attacks here. When would the signature be useful? It doesn't help in the obvious case of a malicious MPIC service: that malicious service can simply claim it saw certain HTTP responses and then sign it. There is nothing to compare those claims to. I am not yet convinced that signing is categorically necessary here.

I don't think RFC 9421 signatures are ideal: they're very much tied to the HTTP context. We want CAs to extract them. I think it makes sense to piggy-back on the simple signature method used in CT RFC6962 with which CAs are already familiar.

[TheEnbyperor]

With ACME, the subscriber doesn't sign the challenge with a non-refutable signature.

You were not to know this, but I have had some discussions with the Chrome recently about long term verifiable DCV. The basic idea is to log the validation used by the CA publicly (a la CT) and require the website to keep that available for the duration of the certificate.

Signatures over MPIC would form part of this imo.

[birgelee]

So I think signatures do help in the case where a CA misbehaves and is not calling MPIC but wants to pretend they are. Essentially, should a CA wish to generate fraudulent validation logs claiming they did validation when they did not, MPIC service signatures from a 3rd party help.

I personally still think they should be optional. If a CA runs the MPIC service, I don't really think they are helpful. If these were to be implemented in Open MPIC, I would probably just have CAs input the signing keys as some sort of config file as opposed to using any type of AWS key management service (to avoid additional AWS dependency) and there would be no security against the CA owner taking the key and signing arbitrary responses.

Finally, I would advise against any signature scheme that expects HTTP messages. The core API object has been put mostly into JSON and I would not be surprised if the transport of these JSON requests/responses eventually moved off HTTPS in some implementations (e.g., Apache Kafka events, gRPC calls, etc...).