On 10/14/2011 11:23 PM, John Dennis wrote:
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).
I'm in support of it, buit not for this release: target 3.0. We should
do this as an additional interface on top of what we have now. We can
tag the original as deprecated.
The web UI can convert the format on the way out or on the way in: from
PEM to bare base64 or DER. We can do this without breaking the existing
API. I think that changing this in the web UI can be done without
breaking anything but the QA tests.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
