[Freeipa-devel] change to interface used to provide certificates

John Dennis jdennis at redhat.com
Sat Oct 15 03:23:27 UTC 2011


I've been fixing a bug in the web UI when we retrieve a certificate. The 
data that's displayed cannot be copied and used with any other 
certificate (i.e. x509) software, openssl and NSS being prime examples. 
The crux of the problem is it's not in a standard format. There are 2 
standard formats for certificates, DER if it's binary and PEM if it text.

What the web UI was outputting was bare base64 encoding of DER data 
(closely related to PEM, but not PEM). We've used bare base64 data in a 
number of places and have gradually fixed a number of them over time. 
The use of bare base64 all goes back to the dawn of IPA and how 
certificate data is stored in LDAP (binary DER) and how binary data 
passes through our RPC mechanism. The early limitations of handling 
certificate data got "institutionalized" in IPA and we got used to using 
the non-standard bare base64 form, not because it's correct but because 
of deficiencies in other parts of the code which are now fixed.

The fact is nobody else uses this format, it's completely non-standard. 
As part of the bug fix I'm working on (certificate output in PEM format 
rather than bare base64) I would also like to clean up the parts of the 
code in both the web UI and the command line which accept certificate 
data as bare base64 and change them so they only accept PEM. In fact as 
it stands now if you paste PEM into the web UI things will fail. The 
command line interface writes PEM data and accepts either PEM or bare 
base64. Currently the web UI outputs bare base64 and accepts bare 
base64. After my bug fix the web UI will output PEM but would still 
require bare base64 as input (if I don't fix that as well). These weird 
inconsistencies aren't good IMHO.

I'd like us to adopt the convention that we only ever input and output 
certificates (and CSR's) in either PEM or DER formats (and PKCS12 in 
specific cases). This matches what both openssl and NSS does and just 
about every other piece of software I'm familiar with. In practical 
terms for the near term it would mean we just support PEM, if we want to 
add DER support later we can, it won't be hard, but we need to stop 
accepting bare base64 data and insist on standard PEM.

This would be a change to the interface. More importantly it's a change 
somewhat late in the game just prior to a major release. But the 
consistency and adherence to standards warrant the change, not to 
mention we probably don't want version 2 of IPA to go out the door this 
way. It would train people with bad habits, frustrate them, and we would 
regret having to support it down the road.

Importing and exporting certs via the web UI and command line are not 
common operations. The only significant impact changing to requiring PEM 
input would be on our automated tests which would have to make sure they 
supplied PEM format.

Comments? Questions?

If I don't hear a major outcry I'm going to proceed with making the 
import and export of certs be PEM only for 100% consistency across the 
board (it would be weird if you couldn't paste the cert data into the 
web UI which you copied from the web UI).

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the Freeipa-devel mailing list