On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > On 8.8.2016 09:06, Fraser Tweedale wrote: > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > Hi, > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > Please review the attached patch with adds --certificate-out and > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > on the server side. > > > > > Will option defined on client side be propagated to, and observable > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > *-out has been requested and executes additional command(s) on that > > basis. > > Is there a reason not to *always* return the certs? > We hit Dogtag to retrieve them.
> > > > > > > > 2) I don't think there should be additional information included in > > > summary > > > (and it definitely should not be multi-line). I would rather inform the > > > user > > > via an error message when unable to write the files. > > > > > I was just following the pattern of other commands that write certs, > > profile config, etc. Apart from consistency with other commands I > > agree that there is no need to have it. So I will remove it. > > > > > If you think there is an actual value in informing the user about > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > installers, there are no cert chains in API commands ATM). > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > or concatenated PEMs, but sometimes they must be concatenated > > forward, and othertimes backwards. There is no one size fits all. > > True, which is exactly why I think we should at least be self-consistent and > use concatenated PEM (and multi-value DER over the wire). > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept header). If we want list-of-PEMs between server and client we have to convert on the server. Do we have a good way of doing this without exec'ing `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' to do the conversion on the server? python-nss does not have PKCS7 functions and I am not keen on adding a pyasn1 PKCS7 parser just for the sake of pushing bits as list-of-PEMs. FWIW, man pages and code suggest that PKCS #7 is accepted in installer, etc. > > We can add an option to control the format later, but for now, > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > themselves. > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > so I'm afraid the worst case would happen virtually always. > If you're OK with invoking OpenSSL on the client to convert PKCS #7 to list-of-PEMs (similar to what is done in ipapython.certdb.NSSDatabase) then we can have the client perform the conversion. > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > common wire format in other API commands. > > > > > OK. > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > separate? For end-entity certs it makes sense to separate the cert from > > > the > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > login to certs issued by VPN sub-CA) then you often just want the > > cert. The chain option does subsume it, at cost of more work for > > administrators with this use case. I think it makes sense to keep > > both options. > > Does it? From what you described above, you either want just the sub-CA > cert, or the full chain including the sub-CA cert, in which case it might > make more sense to have a single --out option and a --chain flag. > How about --certificate-out which defaults to single cert, but does chain (as list-of-PEMs) when --chain flag given. Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more `--out' options. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
