Extending generateCreationBundle to allow for specifying PKIX subject… #3999
Conversation
… data in CSR/issuance requests, and verifying that data against configured role data, if present
|
Thanks for submitting this but it's already in Vault! :-) |
|
I’m sorry, was it added recently? |
|
Yep, a day or two ago. |
|
As of the submission of this PR, this functionality did not exist. Can you point out a merged commit or issue for it? Thanks! |
|
Sure, #3992 |
|
I believe that the commit you referenced is only applicable to handling CA issuance, not non-CA issuance - and also does not immediately appear to set CN properly. |
|
It's for non CA issuance via roles. What do you mean by doesn't set CN properly? |
|
|
|
Ah, thanks. I hadn't yet dug into what was causing Travis failures currently, but that does explain it. :-) I took a look at the diff. What's the use-case for the client specifying values? It seemed to us that specifying at a role level should be sufficient, and not allowing the client to choose means you don't need to perform validation. Generally we don't see so much variance in OUs, much less O/L/C/etc. that creating a new role seemed like a significant lift. |
|
Allowing variable OUs would be a good thing for an org that would like to have a single role (or maybe multiple roles) for an intermediate CA that would issue end-entity certificates for different units within said org. Constraining the allowable PKIX field values based on the assigned role also seems reasonable. The only problem that I don’t believe I fully addressed is considering adding a flag in the role to allow supplicants to specify PKIX values. And thanks for reading all of my comments! |
|
(n.b.: adding multiple roles is a possible solution to this, but I believe that adds complexity to the supplicant process) |
Multiple roles is already the flow! :-) And yes -- it adds some complexity to the supplicant process. But once you make something a client driven option you start having to think about the different ways people will want to control it, so pretty soon you end up with e.g. a set of OUs that support globbing that the client can pick from. And that's still supplicant complexity, plus more code complexity. Taking a step back from there, it starts feeling like different OUs should reasonably correspond to different roles anyways. I'd rather take a wait and see approach here and see what demand is like. Sorry! |
|
No problem. I’m going to take CN fix and the tests that I’ve added here and submit them in a different PR, if that’s alright - it seems that #3992 didn’t precisely add full test coverage for the added features. |
|
Would that be a reasonable thing, at this point? And thanks for the feedback - looking forward to contributing. |
… data in CSR/issuance requests, and verifying that data against configured role data, if present.
The use case is to allow users to specify PKIX data when making a request, but if their role has PKIX fields pre-configured, then test to see if the request data is a subset of the role data. I believe that this has utility beyond my particular needs; would love to receive feedback.