Comments on security

[andydowling-ie]

Great work on this!

A few points:

1) Geir made the point that self-signed certs should not be used in production in his email earlier today. I'd tend to agree. Although technically self-signed certs could be used if their fingerprints are explicitly trusted by the Registry (i.e. akin to importing a new root CA in your browser), each of these certs needs to be explicitly vetted before being added to the registry. At least if certs are issued by valid CAs, some of this work has been done, and it makes it easier to scale.

2) Suggest we replace SHA-1 (being deprecated) with SHA-256 or better for certificate fingerprints

3) We need to be careful when performing certificate matching. Considering the Registry is storing actual copies of the X.509 certs in the catalogue.xml, then its better to match based on cert fingerprint, rather than Common Name. (Although Common Name can be used to index the certs when searching the Registry for a match).

[wrygiel]

Thanks!

It's only the first version of the documentation. Of course - we can revise it in the next version, if we find any security concerns. Once we identify them we can also start a separate thread (issue) for each of them. But it's okay to have a general discussion too.

1. I agree that in general self-signed certificates should not be used on production systems. The registry should monitor the manifest files and enforce some policies. However, I suspect, that we might still want to grant partner a (temporary) permission to use a self-signed certificate in some special circumstances. Do you see any security concerns in using self-signed certs in production if each such certificate will be reviewed by a human?
2. Worth considering, thanks! Probably I'll start a new issue for that later.
3. We have been considering such scenario and concluded that it will cause problems when certificates on the server are upgraded (the server could be temporarily cut off from the network, if the manifest was not handled properly). We would need to analyze if the risk of a bad implementation outweighs the benefits of continuous availability. Should I start a separate issue for that?

[wrygiel]

One more argument for (3) - one Common Name can cover multiple certificates.

[wrygiel]

Also note, that I am playing with an idea of registry pushing every catalogue change into some public Git repository. This way, every change would be recorded, and every partner will be able to analyze it later.

[andydowling-ie]

1. Self-signed certs are fine by me if reviewed by a human. However, it's just an issue of scale. With a CA-signed cert, the identity of the Subject is checked and we get to piggyback on that process. With self-signed certs, the Registry maintainers would need to take the hit. For incidental usage (i.e. small number of developers/testers/temporary users), it should be fine.
2. I just realised that the choice of hash algorithm only applies if you're storing fingerprints and using them to compare certs. That said, certs with SHA-1/RSA are being deprecated and are being replaced with SHA-2.
3. If you compare using just Common Name, your security is dependent on all CAs in your trusted root store not issuing any maliciously or incorrectly-named certs. It's probably a fair assumption, but it you're paranoid, then comparing the cert fingerprint (or cert bytes) is stronger. Happy to discuss via separate thread.

[wrygiel]

With self-signed certs, the Registry maintainers would need to take the hit.

Since we are talking about client certificates only, I see no way avoiding such hit. Without the help of the Registry, how could the server know if the request is coming from within the EWP Network? EDIT: What I mean is that they'll need the registry even if we're not using self-signed certs.

I think we can only attempt to reduce this hit (hence the requirement of caching on the client side). Serving DNS Common Names (instead of whole certificates) also seems a good way of reducing the registry load (and has some other benefits).

[wrygiel]

Made separate issues for each of these discussions. Please comment there. Closing this one.