Hi Alex, On Tue, Jan 15, 2013 at 5:31 PM, Alex Harvey <alexharv...@gmail.com> wrote: > Hi Josh, > > > On Tuesday, January 15, 2013 8:50:53 AM UTC+11, Josh Cooper wrote: >> >> >> 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. > > > Obviously it's almost the same from a coding point of view whether I extend > --digest or create a new option, e.g. > > # puppet agent -t [ --signature AGORITHM ] > > That said I am still not understanding why extending --digest would not be > the least surprising solution, i.e. allow --digest to affect the 'digest > algorithm' a.k.a. hashing algorithm in any situation where a hashing > algorithm is required.
My concern was increasing the number of places where we hard code RSA as the encryption algorithm. As in what happens when someone wants to use a third-party CA that uses DSA? We'd have to add another parameter to specify which encryption algorithm to use. With that said, puppet has other issues preventing us from supporting third-party CAs, trust chains, etc. > This seems more consistent with familiar system > commands like openssl where passing -sha1 in any context would select the > hash algorithm used - whether in the context of generating a fingerprint > (openssl dgst), or a CSR (openssl req). > Yeah, that makes sense, and I imagine that's what most puppet users would expect. As long as we don't couple 'ca' and 'digest', that sounds good to me. > Okay - perhaps after I have digested the code it will become clearer. > >> 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. > > > Is that method or the surrounding code actually being used though? > Yep, when generating a new certificate request we log the fingerprint of the cert: Puppet.info "Certificate Request fingerprint (#{digest.name}): #{digest.to_hex}" Fun times. 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.
