Fraser, Good catch! I'm wondering why it was disabled. Could there be a reason? Fraser, if you have not done so, may I trouble you to take one more step in the testing and see if you can 1. verify the CRLs generated after the enabling of AKI indeed has the extension 2. the CRL is accepted by the OCSP 3. test FF cert verification with both CRL and OCSP Regarding upgrade script, I'll say yes if possible. But we should try to conform to the existing upgrade mechanisms/decision. thanks, Christina

On 10/29/2014 11:09 PM, Fraser Tweedale wrote: >This patch enables the Authority Key Identifier CRL Extension, which >is REQUIRED by RFC 5280, by default. > >Should existing instances be left alone or should I also look at an >upgrade script that offers to upgrade CS.cfg to be conformant? > >Fraser > > >_______________________________________________ >Pki-devel mailing list >Pki-devel(a)redhat.com >https://www.redhat.com/mailman/listinfo/pki-devel

_______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

Hi Christina, Following up on your request for further testing, see below. On Thu, Oct 30, 2014 at 09:25:56AM -0700, Christina Fu wrote: > Fraser, > > Good catch! > > I'm wondering why it was disabled. Could there be a reason? Fraser, if you > have not done so, may I trouble you to take one more step in the testing and > see if you can > 1. verify the CRLs generated after the enabling of AKI indeed has the > extension > The extension is present. > 2. the CRL is accepted by the OCSP > The OCSP responder works fine with the CRLs when the AKI extension has been enabled. > 3. test FF cert verification with both CRL and OCSP > Firefox OCSP check works fine. I'm not sure how to test the CRL in Firefox. Advice? > Regarding upgrade script, I'll say yes if possible. But we should try to > conform to the existing upgrade mechanisms/decision. > Patch will be out shortly.

Cheers, Fraser > thanks, > Christina > > On 10/29/2014 11:09 PM, Fraser Tweedale wrote: > >This patch enables the Authority Key Identifier CRL Extension, which > >is REQUIRED by RFC 5280, by default. > > > >Should existing instances be left alone or should I also look at an > >upgrade script that offers to upgrade CS.cfg to be conformant? > > > >Fraser > > > > > >_______________________________________________ > >Pki-devel mailing list > >Pki-devel(a)redhat.com > >https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

Hi Fraser, Regarding CRL, I found the following: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ilOoD... So I think we can just forget it then, unless you want to install old FF to try. You have an ACK on this patch now. About upgrade, I can see that you are on the right path there with the upgrade script, and it looks to do the thing, but since I don't have much experience with Python, could you please ask Endi to take a closer look?

thanks! Christina On 12/16/2014 06:36 PM, Fraser Tweedale wrote: >Hi Christina, > >Following up on your request for further testing, see below. > >On Thu, Oct 30, 2014 at 09:25:56AM -0700, Christina Fu wrote: >>Fraser, >> >>Good catch! >> >>I'm wondering why it was disabled. Could there be a reason? Fraser, if you >>have not done so, may I trouble you to take one more step in the testing and >>see if you can >>1. verify the CRLs generated after the enabling of AKI indeed has the >>extension >> >The extension is present. > >>2. the CRL is accepted by the OCSP >> >The OCSP responder works fine with the CRLs when the AKI extension >has been enabled. > >>3. test FF cert verification with both CRL and OCSP >> >Firefox OCSP check works fine. I'm not sure how to test the CRL in >Firefox. Advice? > >>Regarding upgrade script, I'll say yes if possible. But we should try to >>conform to the existing upgrade mechanisms/decision. >> >Patch will be out shortly. > >Cheers, > >Fraser > >>thanks, >>Christina >> >>On 10/29/2014 11:09 PM, Fraser Tweedale wrote: >>>This patch enables the Authority Key Identifier CRL Extension, which >>>is REQUIRED by RFC 5280, by default. >>> >>>Should existing instances be left alone or should I also look at an >>>upgrade script that offers to upgrade CS.cfg to be conformant? >>> >>>Fraser >>> >>> >>>_______________________________________________ >>>Pki-devel mailing list >>>Pki-devel(a)redhat.com >>>https://www.redhat.com/mailman/listinfo/pki-devel >>_______________________________________________ >>Pki-devel mailing list >>Pki-devel(a)redhat.com >>https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On 12/18/2014 7:59 AM, Fraser Tweedale wrote: >On Wed, Dec 17, 2014 at 10:13:04AM -0800, Christina Fu wrote: >>Hi Fraser, >>Regarding CRL, I found the following: >>https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ilOoDiCU4JM >>So I think we can just forget it then, unless you want to install old FF to >>try. >>You have an ACK on this patch now. >> >>About upgrade, I can see that you are on the right path there with the >>upgrade script, and it looks to do the thing, but since I don't have much >>experience with Python, could you please ask Endi to take a closer look? >> >Thanks Christina. > >Endi, any comments on upgrade script? > >Currently if you opt out of an upgrade step it aborts the whole >process. I think there could be scope for marking upgrade steps as >optional so that the process doesn't bail out, but I haven't >addressed that in the patch - wanted to solicit feedback first. > >Cheers, > >Fraser I have some comments: 1. The upgrade script will run automatically when you install the RPM. There's no opt-out mechanism with automatic upgrade, so the behavior of existing instances will change. If this is not what we want, we should not add an upgrade script.

2. The path to CS.cfg can be constructed like this: cfg_path = os.path.join(subsystem.conf_dir, 'CS.cfg') 3. The existing CS.cfg should be backed up before doing anything with it using this command: self.backup(cfg_path) 4. Ideally the CS.cfg should be read with a proper CS.cfg parser (e.g. in case it has multi-line properties). But since the parser only exists in Java and we're only modifying a simple property this is fine. 5. If this is going to be added into 10.2.2 you should create an empty common/upgrade/10.2.2 folder with a .gitignore file (just copy from another folder). If this is going to be added into 10.2.1 the script should be moved into server/upgrade/10.2.1 and be renamed to 02-EnableCRLAKIExtension. This patch is conditionally ACKed pending changes to address item #2, #3, and #5.

-- Endi S. Dewata

On 1/7/2015 12:12 PM, Fraser Tweedale wrote: >>1. The upgrade script will run automatically when you install the RPM. >>There's no opt-out mechanism with automatic upgrade, so the behavior of >>existing instances will change. If this is not what we want, we should not >>add an upgrade script. >> >I defer to Christina in this. If automatically turning on the >extension is not what customers want, we still want a way for them >to be able to do it easily. Is there currently a way to leverage >the upgrade framework to do this? > >Perhaps there is scope to declare upgrade modules as automatic >(executed when invoked via RPM) and manual (executed when invoked >manually). Or something like that. Yes, see this ticket: https://fedorahosted.org/pki/ticket/1135 So the plan is to split structural and behavioral upgrade scripts. Structural upgrade is mandatory and executed automatically, while behavioral upgrade is optional. Your upgrade script seems to be a behavioral one. We probably can use the same upgrade framework, but the behavioral scripts will be put under a separate folder. Also, since the script changes the CS.cfg, we should advise the admin to shutdown the server first to avoid corrupting the file. See: https://fedorahosted.org/pki/ticket/1163

-- Endi S. Dewata

On Wed, Jan 07, 2015 at 09:19:50AM +0700, Endi Sukma Dewata wrote: > On 12/18/2014 7:59 AM, Fraser Tweedale wrote: >> On Wed, Dec 17, 2014 at 10:13:04AM -0800, Christina Fu wrote: >>> Hi Fraser, >>> Regarding CRL, I found the following: >>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ilOoD... >>> So I think we can just forget it then, unless you want to install old FF to >>> try. >>> You have an ACK on this patch now. >>> >>> About upgrade, I can see that you are on the right path there with the >>> upgrade script, and it looks to do the thing, but since I don't have much >>> experience with Python, could you please ask Endi to take a closer look? >>> >> Thanks Christina. >> >> Endi, any comments on upgrade script? >> >> Currently if you opt out of an upgrade step it aborts the whole >> process. I think there could be scope for marking upgrade steps as >> optional so that the process doesn't bail out, but I haven't >> addressed that in the patch - wanted to solicit feedback first. >> >> Cheers, >> >> Fraser > I have some comments: > > 1. The upgrade script will run automatically when you install the RPM. > There's no opt-out mechanism with automatic upgrade, so the behavior of > existing instances will change. If this is not what we want, we should not > add an upgrade script. > I defer to Christina in this. If automatically turning on the extension is not what customers want, we still want a way for them to be able to do it easily. Is there currently a way to leverage the upgrade framework to do this?

Perhaps there is scope to declare upgrade modules as automatic (executed when invoked via RPM) and manual (executed when invoked manually). Or something like that. > 2. The path to CS.cfg can be constructed like this: > cfg_path = os.path.join(subsystem.conf_dir, 'CS.cfg') > > 3. The existing CS.cfg should be backed up before doing anything with it > using this command: > self.backup(cfg_path) > > 4. Ideally the CS.cfg should be read with a proper CS.cfg parser (e.g. in > case it has multi-line properties). But since the parser only exists in Java > and we're only modifying a simple property this is fine. > > 5. If this is going to be added into 10.2.2 you should create an empty > common/upgrade/10.2.2 folder with a .gitignore file (just copy from another > folder). > > If this is going to be added into 10.2.1 the script should be moved into > server/upgrade/10.2.1 and be renamed to 02-EnableCRLAKIExtension. > > This patch is conditionally ACKed pending changes to address item #2, #3, > and #5. > Will address these. Thanks! > -- > Endi S. Dewata