[Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file

[Jan Cholasta]

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?

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

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

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

>
> Will cut a new patch tomorrow.
>
> Thanks,
> Fraser
>


-- 
Jan Cholasta