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

> 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.
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

> 4) Over the wire, the certs should be DER-formatted, as that's the most
> common wire format in other API commands.

> 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.

Will cut a new patch tomorrow.


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to