Re: [Freeipa-devel] change to interface used to provide certificates
On Mon, 2011-10-17 at 09:35 -0400, Rob Crittenden wrote: > 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. > > ldapsearch returns raw certificate data as well and this is what the IPA > tools were modeled on, so this is not unprecedented. > > PEM is just base64 with line limits, carriage returns and a > header/footer. Try passing that in as dashed argument and you'll see why > we allow it to be passed in as a single base64 blob (and even that is > rather awful). > > > > > 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. > > Considering that you can't pass binary data via XML-RPC you'd have to > base64 encode it anyway... > > > > > 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. > > Changing the meaning of arguments is not allowed at this point. Input of > certificates is not something a typical user will do, they will manage > certificates via the cert API. We just as a policy try not to hide > functionality so updating certificates is exposed like everything else is. > > > > > 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 fine with display of it as PEM and accepting it as PEM but I think > disallowing an input form that has been there for so long is bad. We can't disable it in 2.x We can discuss if it makes sense to do so in 3.0, but I doubt the 'benefits' will supersede the problems introduced by doing so. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] change to interface used to provide certificates
On Fri, Oct 14, 2011 at 11:23:27PM -0400, John Dennis wrote: > 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 we're talking about the "cert_request" RPC, then this impacts certmonger, so I need to know (and would prefer to know sooner rather than later) if it needs to change its expectations. Cheers, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] change to interface used to provide certificates
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. ldapsearch returns raw certificate data as well and this is what the IPA tools were modeled on, so this is not unprecedented. PEM is just base64 with line limits, carriage returns and a header/footer. Try passing that in as dashed argument and you'll see why we allow it to be passed in as a single base64 blob (and even that is rather awful). 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. Considering that you can't pass binary data via XML-RPC you'd have to base64 encode it anyway... 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. Changing the meaning of arguments is not allowed at this point. Input of certificates is not something a typical user will do, they will manage certificates via the cert API. We just as a policy try not to hide functionality so updating certificates is exposed like everything else is. 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 fine with display of it as PEM and accepting it as PEM but I think disallowing an input form that has been there for so long is bad. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] change to interface used to provide certificates
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
[Freeipa-devel] change to interface used to provide certificates
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 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
