Hi Alex, On Sun, Jan 13, 2013 at 11:29 PM, Alex Harvey <alexharv...@gmail.com> wrote: > On Thursday, January 10, 2013 5:58:02 AM UTC+11, Andy Parker wrote: >> >> >> Yeah, we've been finding these things. There are quite a few settings that >> are defined in there, but don't actually get used. Josh and I were looking >> into some of those, and I just had a conversation with him about signing and >> such with SSL. There are intricacies in there that I'm not fully familiar >> with, so I'll let him chime in on some of that. >>
I would recommend not reusing the ca_md setting, because the name of the setting doesn't really make sense when talking about the signature algorithm that the client would use to generate a certificate signing request (CSR). >> However, I think what you have said makes sense. Can you convert the >> examples that you give below to the equivalent puppet commands so that we >> can all be clear on what you are proposing for changes to the puppet >> commands? > > > The only change to puppet's functionality would be to connect --digest > wherever applicable to override the default algorithm of SHA256. The help > pages and online documentation will need to be updated too and I'm happy to > do that. > > Thus the following are the proposed new uses for --digest - > > 1) puppet agent -t [ --digest DIGEST ] > > An initial certificate signing request from a client will allow digest to be > optionally specified. Although the option 'puppet agent --digest DIGEST' > already exists it currently doesn't do anything unless used in conjunction > with --fingerprint. So this new usage is in addition to the existing usage > via 'puppet agent -t --fingerprint [ --digest DIGEST ]'. Note that > currently when SHA256 doesn't exist we get the following - > > # puppet agent -t --fingerprint > Error: Could not run: Unsupported digest algorithm (SHA256). > I'm concerned about overloading the same flag to specify different types of algorithms. To generate a CSR, we need to know what signature algorithm to use, e.g. sha256WithRSAEncryption. To generate a fingerprint, we only need to know what hash algorithm to apply to the public key. If we only allow the user to specify the hash portion of the signature algorithm, then the code has to make hard-coded assumptions about the type of encryption algorithm to use, and therefore, the types of keys in use (RSA vs DSA). Sadly, puppet already does this, but I'd prefer to not make it worse. I would recommend leaving the `--digest` flag specific to specifying the hash algorithm when generating a fingerprint. Then add a different flag for specifying the signature algorithm. Since this infrequently changes, I'd recommend making a global Puppet setting (but not ca_md). Ideally all of our ssl and certificate handling code should be agnostic with respect to the underlying algorithms. This would make it possible to easily change the algorithms in the future, similar to how openssl provides EVP functions: http://www.openssl.org/docs/crypto/evp.html. For example, Puppet::Host::SSL#digest_algorithm is an example of what not to do, because it makes assumptions about the syntax of the signature algorithm. > For overall consistency I would propose to fix this behaviour too (which > seems to be again an error coming from OpenSSL itself and not Puppet) such > that puppet always tries SHA1 after trying SHA256 even when just computing a > fingerprint. It would seem rather ugly to have it otherwise. > > 2) puppet ca generate [ --digest DIGEST ] # same as the above except > done via puppet ca. > > 3) puppet cert generate [ --digest DIGEST ] # same as the above. > > 4) puppet cert --sign CERTIFICATE [ --digest DIGEST ] # digest algorithm > to use when signing a certificate. > These would all use the signature algorithm option. > Meanwhile I think 'puppet certificate_request' and 'puppet > certificate_revocation_list' subcommands are broken. > > At least they don't > seem to do what the man pages say they will do - > > # puppet cert list > "myhost.example.com" (SHA1) > 97:68:B9:0B:B1:E7:05:A9:03:12:3D:C6:1B:38:8C:6A:6C:B1:D1:F2 > # > > # puppet certificate_request search myhost.example.com > Yes, I get the same thing. I am able to output the cert if I specify the terminus to use, but I don't understand how anyone else would know that: # puppet certificate_request --terminus ca search 'agent1' -----BEGIN CERTIFICATE REQUEST----- MIIEVjCCAj4CAQAwETEPMA0GA1UEAwwGYWdlbnQxMIICIjANBgkqhkiG9w0BAQEF ... -----END CERTIFICATE REQUEST----- > # > > # puppet certificate_revocation_list search myhost.example.com > Error: Could not call 'search' on 'certificate_revocation_list': can't > convert nil into String > Error: Could not call 'search' on 'certificate_revocation_list': can't > convert nil into String > Error: Try 'puppet help certificate_revocation_list search' for usage > # > So search is not a supported action, why I have no idea. The application does mention this in its help, but again the UX here is terrible. Instead you have to say `find` and give it a dummy argument.: $ puppet certificate_revocation_list find whatever -----BEGIN X509 CRL----- MIICejBkAgEBMA0GCSqGSIb3DQEBBQUAMCIxIDAeBgNVBAMMF1B1cHBldCBDQTog ... -----END X509 CRL----- > Likewise the 'puppet certificate' subcommand doesn't seem to be fully > implemented either. > It appears you need to specify the --ca-location (or --ca_location) option, though `puppet cert` needs no such thing. All of the face-based certificate applications are a mess... > Thus, (1) to (4) above seem to be extent of the proposed changes as well as > extending the internal default behaviour to be the highest supported digest > algorith where applicable. > > > How does all this sound? Something else to keep in mind, and something puppet has historically gotten wrong, is that we can't assume all agents and masters are using the same set of algorithms, key lengths, etc. So an agent may generate a CSR using md5WithRSAEncryption, but the master should be able to use SHA256 when outputting fingerprints. And one thing that puppet does wrong currently, is that it always uses SHA256 on the master when signing certificates. Instead, it should, depending on the CA policy, sign the CSR using the same signature algorithm that was used to generate the CSR, or the one that the master is configured to use. As it is now, if you have one agent that doesn't support SHA256, then you have to globally lower the security on your master when signing certificates for all other agents. Finally, when testing your changes, I recommend setting different default algorithms on your agent and master to ensure they can still interoperate. Josh -- Josh Cooper Developer, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
