On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote:
> On 9.8.2016 16:47, Fraser Tweedale wrote:
> > 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.
> 
> I don't think that's an issue in a -show command.
> 
cert_show is invoked by other commands (cert_find*, cert_show,
cert_request, cert_status, ca_del) but these all hit Dogtag anyway
so I suppose that's fine.  I'll return the cert *and* the chain in
separate attributes, unconditionally.

> > 
> > > > 
> > > > > 
> > > > > 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.
> 
> I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other.
> For example, if we added a call to retrieve external CA chain using certs
> from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to
> PKCS#7 if it was our cert chain format of choice.
> 
> What we can avoid though is executing "openssl pkcs7" to do the conversion -
> we can use an approach similar to our DNSSEC code and use python-cffi to
> call libcrypto's PKCS#7 conversion routines instead.
> 
I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to
exec `openssl' to do the job :)

I will transmit DER-encoded PKCS #7 object on the wire; we cannot
used multi-valued DER attribute because order is important.  Client
will convert to PEMs.

Should have new patch on list this afternoon.

Thanks,
Fraser

> > 
> > FWIW, man pages and code suggest that PKCS #7 is accepted in
> > installer, etc.
> 
> True, but that's a relatively new feature (since 4.1) and the installer
> internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-)
> 
> > 
> > > > 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.
> 
> See above.
> 
> > 
> > > > 
> > > > > 
> > > > > 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.
> 
> +1
> 
> > 
> > Thanks,
> > Fraser
> > 
> 
> 
> -- 
> Jan Cholasta

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

Reply via email to