Puppet

I think this is a good idea: providing extra data in the CSR and the subsequent signed certificate provides capabilities that our users will benefit from.

I think we are better off allowing any extensions available as part of the regular CSR process, which includes appropriate extra attribute fields for use in, among other things, the CA determining if this is an acceptable request.

The patch series has been updated to include sending certdnsnames also.

So this looks like a good start … I’m confused a bit by the documentation because you supply a value of ‘attrval1 and 'attrval2’ — but your returned valuees when you check with openssl are ‘testoid1’ and ‘testoid2’. Perhaps I don’t understand properly how that works — do the numbers in the YaML file turn into text of some kind?

Overall though, the idea of filling out a separate CSR data file is fine with me. For us, we’d be filling two things into the CSR. 1) the ‘class’ that we intend on our node getting and 2) the ‘token’ we use to authenticate a node on bootup. Both of these would probably work in this setting just fine, as long as we can pull these CSR values independently as ‘facts’ or something.

Matt

X509 Attributes are made up of OIDs (like SNMP) and values. The OIDs in the file are converted to their named values – in this case testoid1 and testoid2.

How do you intend to get the values from the CSR to validate them?

Two different places .. 1) Having them available as ‘facts’ … something like $csrdata_foo. 2) Ability to pass them as variables to the ‘auto sign verification script’ that we’ve referenced in the other ticket. Something like $autosign = ‘myautosign.sh $csrdata_foo’

So some issues. The attributes are on the CSR which is destroyed/deleted when the certificate is signed. This may or may not be part of a Puppet run. Hence we need someway to extract and store the attributes from the CSR somewhere that results in them being added to Puppet. I am unclear how we could do this – except perhaps to write them to the certificate?

An alternative approach might be to be able to retrieve the CSR attributes using the certificate signing API? That way you could work out if you sign a certificate based on the value of the attribute returned by the API?

Thoughts?

So some issues. The attributes are on the CSR which is destroyed/deleted when the certificate is signed. This may or may not be part of a Puppet run. Hence we need someway to extract and store the attributes from the CSR somewhere that results in them being added to Puppet. I am unclear how we could do this – except perhaps to write them to the certificate?

I would have expected that additional attributes in the CSR would be transferred to the certificate, unless they were specifically part of the request process. (eg: the cert is basically the CSR, signed.)

An alternative approach might be to be able to retrieve the CSR attributes using the certificate signing API? That way you could work out if you sign a certificate based on the value of the attribute returned by the API?

This seems cumbersome, and to be much more prone to data drift. (eg: submit a new CSR with security=superdude, get a catalog with the wrong data, because the CSR lookup sees that, and not the certificate signed from the original CSR with security=nobody.)

Better, I think, embed the values into the certificate, and allow whatever introspection on that, since that has the signature chain to protect and authenticate it.