Release 2 features

19 views
Skip to first unread message

Fraser Scott

unread,
May 15, 2015, 5:47:39 PM5/15/15
to pki...@googlegroups.com
Off the top of my head:

* service-less agent for remote key creation
* remote management over SSH (push)
* CA and cert import, with CA CSR export (for signing by third party)
* root entity
* tiered CAs
* SubjectAltName

I have started tagging issues with Release 2 on https://waffle.io/pki-io/core

One of the challenges will be getting the agent on remote systems. Either the admin cli could push the code (after downloading appropriate versions first) or it could copy an install script which would pull from the internet (like Chef does). We also need to think about keeping the agents up to date. What would be really nice is an auto update feature, on by default, that could be turned off if desired. That would suggest either direct internet access, or the API service could push when we get that far. Maybe support all three: binary push, binary pull from the internet, binary pull from API service.

Fraser Scott

unread,
Jun 18, 2015, 5:52:22 PM6/18/15
to pki...@googlegroups.com, fraser...@gmail.com
I added the following comment to core ticket number 2 (https://github.com/pki-io/core/issues/2) the other week regarding supporting SAN attributes. Including here for completeness.

Standalone certificates are created directly by an admin and are then signed by a CA. Because the admin is trusted, it would make sense to allow them to set whatever they want for the SANs. Maybe the cert creation could have a switch like --san which is given a comma separated list of domains.

For certs created by nodes, we don't want the nodes being able to control what SANs are used. In the same way we scope the cert DNs at the CA level, we could specify SANs at the CA. We could use a whitelist of domains and we could support a list of SANs that are set for all certs signed by that CA.

For example, creating or editing a CA with --san-required 'www.mydomain.com' and --san-optional '*.us.mydomain.com' would force all certs to have a SAN of 'www.mydomain.com' and optionally something below 'us.mydomain.com'.

Reply all
Reply to author
Forward
0 new messages