Re: [Pki-devel] SSO

[Fraser Tweedale]

On Fri, Jul 03, 2020 at 11:11:17AM +0200, Pascal Jakobi wrote:
> I would be interested into trying this.
> 
> 1/ Is there a list of the "environment variables" (I guess these are HTML
> headers) that dogtag needs ? Did not find it
> 
> 2/ If I set an Apache reverse proxy, do I still need to insert an admin
> certificate in the browser's wallet ?
> 
No certificate is required.

You must use AJP protocol between Apache and pki-tomcatd.  It is
recommended to set an AJP shared secret because pki-tomcatd has
absolute trust in whatever data comes over AJP.

The AJP variables to set are:

- REMOTE_USER
- REMOTE_USER_GROUP_N (number of groups)
- REMOTE_USER_GROUP_$i (for $i in 0..N)

REMOTE_USER should get set automatically by mod_proxy_ajp.  For the
other variable, prepend "AJP_" when setting the Apache environment
variable, so that AJP will pick it up.  See [1] for an example.

[1] 
https://www.dogtagpki.org/wiki/GSS-API_authentication#Example_SSSD_and_Apache_configuration

Now that I am paging all of this back into my head, there is a
possible challenge.  For externally authenticated principals, the
set of ACLs to use for authorisation is looked up based on the
"realm" of the principal.

It would be fairly straightforward to implement another way of
conveying the realm, e.g. via an AJP variable.  But the current
implementation takes the realm from the principal name (i.e. the
value of REMOTE_USER).  The realm is whatever follows the '@'.  So
if REMOTE_USER is an email address and everyone has the same domain,
this could work with the current code.  Otherwise, we'll need to
make changes.

All that said, providing an alternative way of specifying the realm
is a small RFE with a big payoff.

HTH,
Fraser

> Thanks !
> 
> P
> 
> Le 03/07/2020 à 05:05, Fraser Tweedale a écrit :
> > On Thu, Jul 02, 2020 at 11:35:22AM -0400, Alex Scheel wrote:
> > > There's a proposal for GSS-API auth:
> > > 
> > > https://www.dogtagpki.org/wiki/GSS-API_authentication
> > > https://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication
> > > 
> > > However, it isn't implemented yet. This would probably suffice for
> > > SSO though.
> > > 
> > Although the design doc is called GSS-API Authentication, the
> > feature is actually a more general than that.  If you put Dogtag
> > behind a web frontend (e.g. Apache), you can authenticate users via
> > SAML or OIDC and convey the appropriate environment variables, and
> > it will work.  Dogtag just sees an external principal and their
> > groups conveyed via AJP request attributes.
> > 
> > Cheers,
> > Fraser
> > 
> > > 
> > > My 2c,
> > > 
> > > - Alex
> > > 
> > > - Original Message -
> > > > From: "Dinesh Prasanth Moluguwan Krishnamoorthy" 
> > > > To: "Pascal Jakobi" 
> > > > Cc: pki-devel@redhat.com
> > > > Sent: Thursday, July 2, 2020 11:18:53 AM
> > > > Subject: Re: [Pki-devel] SSO
> > > > 
> > > > Pascal,
> > > > 
> > > > I don't think Dogtag Web UI supports it. The feature you are suggesting
> > > > (sounds to me like it) requires a full fledged IDM deployment. You can 
> > > > look
> > > > at FreeIPA, if you are looking for MFA.
> > > > 
> > > > FreeIPA <https://www.freeipa.org/page/About> uses Dogtag CA as its 
> > > > backend
> > > > to issue certs and also combines several other components to offer a
> > > > full-fledged IDM deployment.
> > > > 
> > > > Nonetheless, I'm CC'ing pki-devel to see if other developers have any
> > > > thoughts.
> > > > 
> > > > Regards,
> > > > --Dinesh
> > > > 
> > > > On Mon, Jun 29, 2020 at 4:47 PM Pascal Jakobi 
> > > > wrote:
> > > > 
> > > > > Dinesh
> > > > > 
> > > > > In fact all I am doing here is in order to offer a GUI that may be 
> > > > > used
> > > > > with OpenId Connect (ie Keycloak or so...). The value of this is that 
> > > > > it is
> > > > > much more flexible than certificate based authentication. You can 
> > > > > have MFA,
> > > > > etc
> > > > > 
> > > > > So my question : is there a way to remove the certificate based access
> > > > > control in Dogtag's UI ? I would replace it with a tomcat valve that
> > > > > provides OIDC support.
> > > > > 
> > > > > Best
> > > > > --
> > > > > *Pascal Jakobi* 116 rue de Stalingrad 93100 Montreuil, France
> > > > > pascal.jak...@gmail.com - +33 6 87 47 58 19
> > > > > 
> > > > ___
> > > > Pki-devel mailing list
> > > > Pki-devel@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/pki-devel
> > > ___
> > > Pki-devel mailing list
> > > Pki-devel@redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-devel
> -- 
> *Pascal Jakobi* 116 rue de Stalingrad 93100 Montreuil, France
> pascal.jak...@gmail.com - +33 6 87 47 58 19

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] SSO

[Fraser Tweedale]

On Thu, Jul 02, 2020 at 11:35:22AM -0400, Alex Scheel wrote:
> There's a proposal for GSS-API auth:
> 
> https://www.dogtagpki.org/wiki/GSS-API_authentication
> https://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication
> 
> However, it isn't implemented yet. This would probably suffice for
> SSO though.
> 
Although the design doc is called GSS-API Authentication, the
feature is actually a more general than that.  If you put Dogtag
behind a web frontend (e.g. Apache), you can authenticate users via
SAML or OIDC and convey the appropriate environment variables, and
it will work.  Dogtag just sees an external principal and their
groups conveyed via AJP request attributes.

Cheers,
Fraser

> 
> 
> My 2c,
> 
> - Alex
> 
> - Original Message -
> > From: "Dinesh Prasanth Moluguwan Krishnamoorthy" 
> > To: "Pascal Jakobi" 
> > Cc: pki-devel@redhat.com
> > Sent: Thursday, July 2, 2020 11:18:53 AM
> > Subject: Re: [Pki-devel] SSO
> > 
> > Pascal,
> > 
> > I don't think Dogtag Web UI supports it. The feature you are suggesting
> > (sounds to me like it) requires a full fledged IDM deployment. You can look
> > at FreeIPA, if you are looking for MFA.
> > 
> > FreeIPA  uses Dogtag CA as its backend
> > to issue certs and also combines several other components to offer a
> > full-fledged IDM deployment.
> > 
> > Nonetheless, I'm CC'ing pki-devel to see if other developers have any
> > thoughts.
> > 
> > Regards,
> > --Dinesh
> > 
> > On Mon, Jun 29, 2020 at 4:47 PM Pascal Jakobi 
> > wrote:
> > 
> > > Dinesh
> > >
> > > In fact all I am doing here is in order to offer a GUI that may be used
> > > with OpenId Connect (ie Keycloak or so...). The value of this is that it 
> > > is
> > > much more flexible than certificate based authentication. You can have 
> > > MFA,
> > > etc
> > >
> > > So my question : is there a way to remove the certificate based access
> > > control in Dogtag's UI ? I would replace it with a tomcat valve that
> > > provides OIDC support.
> > >
> > > Best
> > > --
> > > *Pascal Jakobi* 116 rue de Stalingrad 93100 Montreuil, France
> > > pascal.jak...@gmail.com - +33 6 87 47 58 19
> > >
> > 
> > ___
> > Pki-devel mailing list
> > Pki-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Certificate Transparency SCT signature verification?

[Fraser Tweedale]

On Wed, Jun 17, 2020 at 12:59:57AM +1000, Fraser Tweedale wrote:
> Thanks for the testing notes, Christina.
> 
> Today I set up a local test CT log server using a container image.
> I plan to document more thoroughly but rough notes at [1].
> 
> Now to the issue I found - I have a commit[2] in a private branch.
> Hopefully the commit message and comments explain it well enough.
> 
> Is it the last issue?  Not sure yet, I finally got it compiled but
> haven't run the code yet.  Tomorrow's adventure.
> 
> [1] https://github.com/frasertweedale/notes-redhat/blob/master/ct.rst
> [2] https://github.com/frasertweedale/pki/tree/fix/ct-verify
> 
> Cheers,
> Fraser
> 

I went down the garden path on this one.  It turns out that JSS/NSS
*does* use the DER-encoded ECDSA-Sig-Value as the signature format.
(I wrote a small test program to check this).  So most of the code I
wrote yesterday is wrong.

Analysis continues.

Thanks,
Fraser

> On Mon, Jun 15, 2020 at 10:45:53AM -0700, Christina Fu wrote:
> > Hi Fraser,
> > That sounds good!  I just added the following page to document my "quick
> > test" procedure which I use during development:
> > https://www.dogtagpki.org/wiki/PKI_10.9_Certificate_Transparency
> > btw, the verifySCT is currently enabled, but the failure is ignored.
> > However, you could look in the debug log for "verifySCT" to see relevant
> > debug messages.
> > 
> > I'll ask Dinesh to add his more comprehensive testing procedure to the page.
> > thanks!!
> > Christina
> > 
> > On Thu, Jun 11, 2020 at 5:58 PM Fraser Tweedale  wrote:
> > 
> > > Hi Christina,
> > >
> > > I will find a day next week to have a close look.  Probably Tuesday
> > > or Wednesday.  It will help to have test environment setup
> > > documentation, i.e. how to set up a log server to test with, how to
> > > configure Dogtag, etc.  If this stuff is already written then you
> > > just need to tell me where to look :)
> > >
> > > Cheers,
> > > Fraser
> > >
> > > On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote:
> > > > HI Fraser,
> > > > verifySCT still fails.  I still think the fact the rfc does not require
> > > the
> > > > signed object to accompany the signature presents undue challenge to the
> > > > party that needs to verify the signature.  Although I understand that
> > > this
> > > > is v1, and the issue would not be present in v2 since there will not be
> > > > poison extension ;-/.
> > > > I'd appreciate it if you could find time to take a closer look.
> > > >
> > > > Here is my latest attempt:
> > > > https://github.com/dogtagpki/pki/pull/440
> > > > Since it's a patch against the latest code, for a full view, it would be
> > > > easier if you just apply the patch and read from "(Certificate
> > > > Transparency)" in
> > > > base/ca/src/com/netscape/ca/CAService.java
> > > > This patch would require JSS change at:
> > > > https://github.com/dogtagpki/jss/pull/575
> > > >
> > > > Code still requires some refinement but I wish to address the
> > > verification
> > > > issue before cleaning things up.  Of course I still let verifySCT 
> > > > returns
> > > > success for now just so people could still play with CT.
> > > > Much appreciated!
> > > > Christina
> > > >
> > > > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu  wrote:
> > > >
> > > > > Hi Fraser,
> > > > > Thanks for the response!
> > > > > Regarding the poison extension, yes I was aware that it needed to be
> > > > > removed so the code already had it removed.  It was the order of 
> > > > > things
> > > > > left inside tbsCert that I was concerned about since I used the
> > > existing
> > > > > delete method provided for the Extension class, which I wasn't sure if
> > > it'd
> > > > > preserve the order of the remaining extensions.  Thanks for confirming
> > > my
> > > > > suspicion.  I will double-check the order.
> > > > >
> > > > > Also thanks for the input on how to handle failed CT log communication
> > > > > v.s. response verification failure.   I will address them separately 
> > > > > as
> > > > > suggested.
> > > > > Finally, nice catch with the missing data length!!  I'll add that and
> > &

Re: [Pki-devel] Certificate Transparency SCT signature verification?

[Fraser Tweedale]

Thanks for the testing notes, Christina.

Today I set up a local test CT log server using a container image.
I plan to document more thoroughly but rough notes at [1].

Now to the issue I found - I have a commit[2] in a private branch.
Hopefully the commit message and comments explain it well enough.

Is it the last issue?  Not sure yet, I finally got it compiled but
haven't run the code yet.  Tomorrow's adventure.

[1] https://github.com/frasertweedale/notes-redhat/blob/master/ct.rst
[2] https://github.com/frasertweedale/pki/tree/fix/ct-verify

Cheers,
Fraser

On Mon, Jun 15, 2020 at 10:45:53AM -0700, Christina Fu wrote:
> Hi Fraser,
> That sounds good!  I just added the following page to document my "quick
> test" procedure which I use during development:
> https://www.dogtagpki.org/wiki/PKI_10.9_Certificate_Transparency
> btw, the verifySCT is currently enabled, but the failure is ignored.
> However, you could look in the debug log for "verifySCT" to see relevant
> debug messages.
> 
> I'll ask Dinesh to add his more comprehensive testing procedure to the page.
> thanks!!
> Christina
> 
> On Thu, Jun 11, 2020 at 5:58 PM Fraser Tweedale  wrote:
> 
> > Hi Christina,
> >
> > I will find a day next week to have a close look.  Probably Tuesday
> > or Wednesday.  It will help to have test environment setup
> > documentation, i.e. how to set up a log server to test with, how to
> > configure Dogtag, etc.  If this stuff is already written then you
> > just need to tell me where to look :)
> >
> > Cheers,
> > Fraser
> >
> > On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote:
> > > HI Fraser,
> > > verifySCT still fails.  I still think the fact the rfc does not require
> > the
> > > signed object to accompany the signature presents undue challenge to the
> > > party that needs to verify the signature.  Although I understand that
> > this
> > > is v1, and the issue would not be present in v2 since there will not be
> > > poison extension ;-/.
> > > I'd appreciate it if you could find time to take a closer look.
> > >
> > > Here is my latest attempt:
> > > https://github.com/dogtagpki/pki/pull/440
> > > Since it's a patch against the latest code, for a full view, it would be
> > > easier if you just apply the patch and read from "(Certificate
> > > Transparency)" in
> > > base/ca/src/com/netscape/ca/CAService.java
> > > This patch would require JSS change at:
> > > https://github.com/dogtagpki/jss/pull/575
> > >
> > > Code still requires some refinement but I wish to address the
> > verification
> > > issue before cleaning things up.  Of course I still let verifySCT returns
> > > success for now just so people could still play with CT.
> > > Much appreciated!
> > > Christina
> > >
> > > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu  wrote:
> > >
> > > > Hi Fraser,
> > > > Thanks for the response!
> > > > Regarding the poison extension, yes I was aware that it needed to be
> > > > removed so the code already had it removed.  It was the order of things
> > > > left inside tbsCert that I was concerned about since I used the
> > existing
> > > > delete method provided for the Extension class, which I wasn't sure if
> > it'd
> > > > preserve the order of the remaining extensions.  Thanks for confirming
> > my
> > > > suspicion.  I will double-check the order.
> > > >
> > > > Also thanks for the input on how to handle failed CT log communication
> > > > v.s. response verification failure.   I will address them separately as
> > > > suggested.
> > > > Finally, nice catch with the missing data length!!  I'll add that and
> > go
> > > > from there.
> > > >
> > > > thanks again!
> > > > Christina
> > > >
> > > > On Mon, Jun 1, 2020 at 7:31 PM Fraser Tweedale 
> > > > wrote:
> > > >
> > > >> Hi Christina,
> > > >>
> > > >> Adding pki-devel@ for wider audience.  Comments below.
> > > >>
> > > >> On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
> > > >> > Hi Fraser,
> > > >> > Do you know how the signature returned in the SCT response could be
> > > >> > verified by the CA?
> > > >> > My thought is that the CA should somehow verify the CT response
> > after
> > > >> &g

Re: [Pki-devel] Certificate Transparency SCT signature verification?

[Fraser Tweedale]

Hi Christina,

I will find a day next week to have a close look.  Probably Tuesday
or Wednesday.  It will help to have test environment setup
documentation, i.e. how to set up a log server to test with, how to
configure Dogtag, etc.  If this stuff is already written then you
just need to tell me where to look :)

Cheers,
Fraser

On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote:
> HI Fraser,
> verifySCT still fails.  I still think the fact the rfc does not require the
> signed object to accompany the signature presents undue challenge to the
> party that needs to verify the signature.  Although I understand that this
> is v1, and the issue would not be present in v2 since there will not be
> poison extension ;-/.
> I'd appreciate it if you could find time to take a closer look.
> 
> Here is my latest attempt:
> https://github.com/dogtagpki/pki/pull/440
> Since it's a patch against the latest code, for a full view, it would be
> easier if you just apply the patch and read from "(Certificate
> Transparency)" in
> base/ca/src/com/netscape/ca/CAService.java
> This patch would require JSS change at:
> https://github.com/dogtagpki/jss/pull/575
> 
> Code still requires some refinement but I wish to address the verification
> issue before cleaning things up.  Of course I still let verifySCT returns
> success for now just so people could still play with CT.
> Much appreciated!
> Christina
> 
> On Tue, Jun 2, 2020 at 3:05 PM Christina Fu  wrote:
> 
> > Hi Fraser,
> > Thanks for the response!
> > Regarding the poison extension, yes I was aware that it needed to be
> > removed so the code already had it removed.  It was the order of things
> > left inside tbsCert that I was concerned about since I used the existing
> > delete method provided for the Extension class, which I wasn't sure if it'd
> > preserve the order of the remaining extensions.  Thanks for confirming my
> > suspicion.  I will double-check the order.
> >
> > Also thanks for the input on how to handle failed CT log communication
> > v.s. response verification failure.   I will address them separately as
> > suggested.
> > Finally, nice catch with the missing data length!!  I'll add that and go
> > from there.
> >
> > thanks again!
> > Christina
> >
> > On Mon, Jun 1, 2020 at 7:31 PM Fraser Tweedale 
> > wrote:
> >
> >> Hi Christina,
> >>
> >> Adding pki-devel@ for wider audience.  Comments below.
> >>
> >> On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
> >> > Hi Fraser,
> >> > Do you know how the signature returned in the SCT response could be
> >> > verified by the CA?
> >> > My thought is that the CA should somehow verify the CT response after
> >> > sending the add-pre-chain request and before signing the cert.  Since
> >> log
> >> > inclusion verification would not be feasible right after the request
> >> (the
> >> > SCT response is supposed to be just a "promise, according to the rfc),
> >> I
> >> > ruled that out and intend to stay with just the following two
> >> verifications
> >> > on the response itself:
> >> >
> >> >- checking if log id (CT log signer public key hash) returned in the
> >> CT
> >> >response is correct
> >> >- this I have no problem verifying
> >> >   - Verifying if the signature returned in the CT response is
> >> correct
> >> >   - this I can't seem to get it working.
> >> >
> >> > I put the verification work above in the method "verifySCT".
> >> >
> >> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L1209
> >> > What I am wondering is how this can be done properly.  Since the
> >> tbsCert is
> >> > not to contain the poison extension, the poison extension needs to be
> >> > removed by the CT server before it signs.  What if the order of the
> >> > extensions contained in the tbsCert gets changed in the process?
> >> >
> >> The poison extension must be removed, and care must be taken to keep
> >> everything else in the same order, and reserialise the parts in
> >> exactly the same way.
> >>
> >> > It seems that the response should contain the tbsCert that it signs
> >> (which
> >> > isn't per the rfc) or I am not sure how the CA could verify the
> >> signature.
> >> >
> >> The response does not contain the TBCCertificate.  Both sides

Re: [Pki-devel] Questions regarding addition of our own Cockpit module

[Fraser Tweedale]

On Wed, Jun 03, 2020 at 08:17:39PM -0400, Dinesh Prasanth Moluguwan 
Krishnamoorthy wrote:
> Hello team,
> 
> I’m part of Dogtag PKI open-source project [1]. Our team strives to provide
> enterprise-class open-source Public Key Infrastructure (PKI) [2].
> 
> Dogtag PKI server is a Java web application running on Tomcat. Currently,
> we have a stand-alone Java AWT client tool called pkiconsole to access PKI
> services on the server. PKI users are authenticated using client
> certificates stored in LDAP. These users only exist in LDAP, they are not
> users on the host itself.
> 
> We are trying to convert pkiconsole into a web application. We had a chance
> to look at Cockpit from a very high-level and have some questions. I’m
> reaching out to the members of the Cockpit team, before we could make a
> concrete decision on whether Cockpit is a perfect choice for us.
> 
> The questions are:
> 
> 1. According to [3] Cockpit seems to require the host to join the IdM
> domain in order to authenticate PKI users into Cockpit using client cert
> auth. Is it possible to use client cert auth without joining a domain? Will
> that require major changes in Cockpit?
> 
At a glance at the linked doc, it looks like Cockpit is using
mod_lookup_identity certmap capability or something similar for user
cert authn.  Therefore to work directly for Dogtag users I think it
is more than just configuration; something would need to be built.

> 2. Suppose the user has been authenticated into Cockpit using a client cert
> as described in #1, is it possible for Cockpit to use the same client
> certificate auth to access PKI server? Or do we need to use a different
> auth mechanism?
> 

How would this even work?  Cockpit does not have the user's private
key.

Or Cockpit would need a highly privileged agent credential and
access control around its use.  Danger!  We had quite a few CVEs in
FreeIPA because of this kind of privilege separation violation.

Or some new mechanism like a signed "endorsement" from Cockpit that
user "alice" requests to do operation X, with ACL enforcement
staying in Dogtag (where it belongs).

Anything is possible, but only some approaches are secure.  I like
the idea of Cockpit using a proxy credential.  But the only
mechanism we have for that is GSS-API/Kerberos, which takes us full
circle back to the requirement for a full-fledge IDM environment.

Cheers,
Fraser

> Regards,
> The PKI Team
> 
> [1] https://github.com/dogtagpki/pki
> 
> [2] https://www.dogtagpki.org/wiki/PKI_Main_Page
> 
> [3] https://cockpit-project.org/guide/latest/cert-authentication

> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Certificate Transparency SCT signature verification?

[Fraser Tweedale]

Hi Christina,

Adding pki-devel@ for wider audience.  Comments below.

On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
> Hi Fraser,
> Do you know how the signature returned in the SCT response could be
> verified by the CA?
> My thought is that the CA should somehow verify the CT response after
> sending the add-pre-chain request and before signing the cert.  Since log
> inclusion verification would not be feasible right after the request (the
> SCT response is supposed to be just a "promise, according to the rfc),  I
> ruled that out and intend to stay with just the following two verifications
> on the response itself:
> 
>- checking if log id (CT log signer public key hash) returned in the CT
>response is correct
>- this I have no problem verifying
>   - Verifying if the signature returned in the CT response is correct
>   - this I can't seem to get it working.
> 
> I put the verification work above in the method "verifySCT".
> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L1209
> What I am wondering is how this can be done properly.  Since the tbsCert is
> not to contain the poison extension, the poison extension needs to be
> removed by the CT server before it signs.  What if the order of the
> extensions contained in the tbsCert gets changed in the process?
> 
The poison extension must be removed, and care must be taken to keep
everything else in the same order, and reserialise the parts in
exactly the same way.

> It seems that the response should contain the tbsCert that it signs (which
> isn't per the rfc) or I am not sure how the CA could verify the signature.
>
The response does not contain the TBCCertificate.  Both sides (log
and client) remove the poison extension (and change nothing else),
then both sides can sign the same data.

> So the question now is if I should just leave out the check, unless you
> have other suggestions.
>
I do think we should verify the signature, to ensure the message was
actually received by the log server we wanted and not an impostor.

> Of course, I also could have missed something in my code.
> 
The binary format is complex and it's easy to miss something.  After
you implement removal of the poison extension, if it is still not
working I will go over the code with a fine-tooth comb.

I copied some of the code and left comments below, too.  Comments
begin with `!!'.  I think I found one bug and a couple of possible
improvements.

> One last question, currently in the code, if verifySCT fails, I just
> "continue" to process for next CT log.  Should this just bail out all
> together or it's fine to continue? Or could this be a choice by the admin.
> What do you think and why?
> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L951
>
My line of thinking is this:

- we should tolerate communication errors with log (perhaps
  enqueuing the cert for a retry later)

- but (assuming we implement it correctly) verifySCT failure is
  indicative of something wrong with the log (e.g. key changed); it
  is not a communication error and can be treated differently.

- I think it's OK to fail hard.  Admins will likely want to know if
  something is wrong with CT logging.

- But in case we make a mistake, or an org needs issuance to
  continue despite CT log misbehaviour, there should be a config
  knob to allow this condition to be ignored.  "In case of
  emergency..."


> 
> thanks,
> Christina

boolean verifySCT(CTResponse response, byte[] tbsCert, String logPublicKey)
throws Exception {

/* ... SNIP ... */

byte[] extensions = new byte[] {0, 0};
!! although no extensions have been defined I think we should we take
   extensions from the CT response to future-proof this code.  i.e.
   decode the base64 data from the "extensions" field, and prepend the length.

// piece them together

int data_len = version.length + signature_type.length +
 timestamp.length + entry_type.length +
 issuer_key_hash.length + tbsCert.length + extensions.length;

logger.debug(method + " data_len = "+ data_len);
ByteArrayOutputStream ostream = new ByteArrayOutputStream();

ostream.write(version);
ostream.write(signature_type);
ostream.write(timestamp);

ostream.write(entry_type);
ostream.write(issuer_key_hash);
ostream.write(tbsCert);
!! I believe you need to prepend the length of tbsCert as a
   THREE-byte length field, because its definition is
   `opaque TBSCertificate<1..2^24-1>;'

ostream.write(extensions);

byte[] data = ostream.toByteArray();

// Now, verify the signature
// Note: this part currently does not work; see method comment above

// cfu ToDo: interpret the alg bytes later; hardcode for now
Signature signer = Signature.getInstance("SHA256withEC", "Mozilla-JSS");

Re: [Pki-devel] ACME certificate IDs

[Fraser Tweedale]

On Fri, Mar 20, 2020 at 03:41:05PM -0400, Endi Sukma Dewata wrote:
> - Original Message -
> > > Let me backtrack a little bit. Is there a plan to modify Dogtag to
> > > eventually support different serial number domains? If not, this is
> > > not an issue for Dogtag.
> >
> > There is no plan to do so.  It is not an issue for Dogtag.  But
> > still, I feel basing certificate ID on only serial number is not a
> > robust approach in general.
> > 
> > > If there is such plan, will the issuer DN
> > > be unique across LWCAs? If issuer DN will be unique, it's something
> > > to consider. If not, (issuer DN, serial number) will not be unique
> > > either, so we need to use something else such as authority ID.
> > > 
> > > Or is there another backend with multiple issuers that we want to
> > > support in the future? The cert ID will have to be something like
> > > (issuer ID, serial number) where the issuer ID is unique for the
> > > backend. If the issuer DN is unique, it can be used as the issuer
> > > ID. Otherwise, it needs to be a backend-specific unique ID similar
> > > to authority ID in Dogtag.
> >
> > All certs must have unique (issuer,serial).  This is implied by the
> > requirement that all certs from a given issuer must have different
> > serial numbers.
> > 
> > > We need to consider these possibilities before changing the cert ID.
> > > On the other hand, I'm still not sure it's actually necessary to
> > > include these information into cert ID.
> > > 
> > > Let's look at the code. For cert enrollment (ACMEFinalizeOrderService)
> > > we convert the serial number that we get from ACMEBackend into cert ID:
> > > 
> > >   BigInteger serialNumber = backend.issueCertificate(csr);
> > >   String certID =
> > >   Base64.encodeBase64URLSafeString(serialNumber.toByteArray());
> > > 
> > > We can change it so ACMEBackend can generate the cert ID like this:
> > > 
> > >   String certID = backend.issueCertificate(csr);
> > > 
> > 
> > I strongly agree with pushing the certID generation into the
> > ACMEBackend.  Stepping away from the whole (issuer,serial)
> > discussion, say (for example) the only "handle" a backend has for
> > accessing a cert is a UUID.  Then storing the serial number is no
> > good - you cannot derive the UUID handle from the serial number.
> > 
> > So the backend must generate the (String) certID that is appropriate
> > for that backend.
> > 
> > > If the cert ID is (issuer DN, serial number), we can generate the
> > > cert ID from the new cert. But does the backend return the new cert
> > > or just the serial number?
> > >
> > Yeah, good question; of course you must be able to retrieve the
> > cert (and therefore you can learn the Issuer DN) but this could mean
> > another round-trip to Dogtag.  Which is the next thing you said :)
> > 
> > > If the serial number is not unique, the
> > > backend might need to be changed to return the cert itself so we
> > > can get the issuer DN.
> > > 
> > > If the cert ID is (authority ID, serial number), how do we get the
> > > authority ID since it's not included in the cert? The backend might
> > > need to be changed to return the authority ID along with the new
> > > cert, or to provide a way to look up the authority ID using a cert.
> > >
> > I am not suggesting to use the authority ID.  But FWIW Dogtag does
> > enforce that Issuer DN <-> Authority ID is a bijection.
> > 
> > > 
> > > For cert retrieval (ACMECertificateService) we're passing the cert ID
> > > to ACMEBackend:
> > > 
> > >   String certChain = backend.getCertificateChain(certID);
> > > 
> > > The ACMEBackend can extract the issuer DN or authority ID from the
> > > cert ID so it can retrieve the cert from the backend again.
> > > 
> > > Since we get the cert during enrollment anyway, we can actually store
> > > it into ACME database like this:
> > > 
> > >   String certChain = backend.issueCertificate(csr);
> > >   String certID = database.addCert(certChain, orderID, accountID,
> > >   expirationTime);
> > > 
> > > Later we can simply retrieve it from the database instead of calling
> > > the backend again:
> > > 
> > >   String certChain = database.getCertificateChain(certID);
> > > 
> > As I said in previous email, I am opposed to storing the cert
> > (chain) in the ACME database.  If some backend requires it e.g.
> > because the backend itself does not store the cert, then it can be
> > optional.  But we do not need that now.
> > 
> > > Here the cert ID can simply be a unique ID generated by the database.
> > > Unlike earlier, the backend doesn't need to know about cert ID at all.
> > > 
> > > For cert revocation (ACMERevokeCertificateService) the client will
> > > only provide the cert binaries. It doesn't provide the cert ID.
> > > 
> > And the ACMEBackend implementation receives the cert, and must work
> > out what to do with it.  How it tells the backend system to revoke
> > the certificate, and whether that process even involves a string
> > CertID handle, or just a 

Re: [Pki-devel] ACME certificate IDs

[Fraser Tweedale]

Hi Endi,

Responses inline.

On Fri, Mar 20, 2020 at 12:55:46AM -0400, Endi Sukma Dewata wrote:
> - Original Message -
> > > > Currently on ACMEBackend interface we have
> > > > 
> > > >   public BigInteger issueCertificate(String csr);
> > > > 
> > > > I think this is a bit of a problem.  e.g. Dogtag currently supports
> > > > multiple issuers (LWCAs).  It is incidental that serial numbers do
> > > > not collide.  This might not hold for other backends.  Yet we need
> > > > the certificate ID to uniquely identify the certificate, so that we
> > > > can retrieve it, revoke it, etc.
> > > > 
> > > > I suggest changing the return value to a string (which is how it
> > > > gets stored in the ACMEOrder object anyway).
> > > > 
> > > > I'd further suggest that by convention, where possible, the string
> > > > be a representation of issuer+serial, which is a bit nicer for
> > > > humans looking at the stored objects than a base64url-encoded
> > > > big-endian bigint.
> > >
> > > I agree there is a problem, but I'm not sure about using issuer+serial
> > > as certificate ID. What do we use as "issuer", is it the issuer DN
> > > or the authority ID?
> >
> > The issuer DN.
> > 
> > > Is issuer DN unique enough?
> >
> > (issuer, serial) pair must be globally unique.
> > 
> > > How do we join with the serial number?
> > > What format do we use for serial number?
> >
> > Doesn't really matter as long as it is unambiguous.  For example,
> > serial as decimal number, followed by ';', followed by string
> > representation of Issuer DN.
> > 
> > > What if we need to add another field in the future? It seems there's going
> > > to
> > > be many questions/issues with this solution.
> >
> > It is up to the ACMEBackend to produce a certificate ID.  I'm simply
> > proposing this because a backend could contain multiple CAs with
> > separate serial number domains, hence deriving certificate ID from
> > serial number alone would not be unique.  The idea of
> > (issuer,serial) pair is just a suggested convention.  Some backends
> > e.g. might prefer UUIDs or whatever makes it easy to retrieve a
> > certificate/chain.
> >
> > > How about this instead?
> > > 
> > > 1. Change issueCertificate() to return the full cert chain.
> > > 2. Store the cert chain in a "certs" table in ACME database.
> > > 3. Autogenerate the cert ID for each cert record.
> > > 4. Store the account ID in the cert record.
> > > 5. Store the cert ID in the order record.
> > > 
> > > So a copy of the cert will be stored in ACME database. The cert
> > > ID will be unique for that particular ACME server. We don't need
> > > to include the issuer DN/ID. The cert serial number will not matter
> > > either. We can also use the certs table to authorize revocation
> > > requests.
> >
> > I thought about this a little while back, and I prefer the current
> > approach of storing an identifier as a "handle" to retrieve the cert
> > from the backend.  Cert objects will increase the size of
> > records/objects significantly.  For the LDAP backend it could be a
> > problem, both for disk usage but in particular for replication.
> > 
> > I'm OK with the idea of *optional* certificate/chain storage in the
> > ACME database, e.g. for backends that do not support retrieval.  But
> > I don't think we need that with the current backends (certainly not
> > with the PKIBackend).
> > 
> > > The cert ID is not meant to be human readable anyway (as
> > > shown in RFC 8555).
> >
> > But it doesn't matter if it is human readable.  Either way, storing
> > only the serial number is not enough IMO.
> 
> Let me backtrack a little bit. Is there a plan to modify Dogtag to
> eventually support different serial number domains? If not, this is
> not an issue for Dogtag.
>
There is no plan to do so.  It is not an issue for Dogtag.  But
still, I feel basing certificate ID on only serial number is not a
robust approach in general.

> If there is such plan, will the issuer DN
> be unique across LWCAs? If issuer DN will be unique, it's something
> to consider. If not, (issuer DN, serial number) will not be unique
> either, so we need to use something else such as authority ID.
> 
> Or is there another backend with multiple issuers that we want to
> support in the future? The cert ID will have to be something like
> (issuer ID, serial number) where the issuer ID is unique for the
> backend. If the issuer DN is unique, it can be used as the issuer
> ID. Otherwise, it needs to be a backend-specific unique ID similar
> to authority ID in Dogtag.
>
All certs must have unique (issuer,serial).  This is implied by the
requirement that all certs from a given issuer must have different
serial numbers.

> 
> We need to consider these possibilities before changing the cert ID. 
> On the other hand, I'm still not sure it's actually necessary to
> include these information into cert ID.
> 
> Let's look at the code. For cert enrollment (ACMEFinalizeOrderService)
> we convert the serial number that we get 

Re: [Pki-devel] ACME certificate IDs

[Fraser Tweedale]

On Tue, Mar 17, 2020 at 05:04:59PM -0400, Endi Sukma Dewata wrote:
> - Original Message -
> > Hi Endi,
> > 
> > Just want to quickly discuss certificate IDs.
> > 
> > Currently on ACMEBackend interface we have
> > 
> >   public BigInteger issueCertificate(String csr);
> > 
> > I think this is a bit of a problem.  e.g. Dogtag currently supports
> > multiple issuers (LWCAs).  It is incidental that serial numbers do
> > not collide.  This might not hold for other backends.  Yet we need
> > the certificate ID to uniquely identify the certificate, so that we
> > can retrieve it, revoke it, etc.
> > 
> > I suggest changing the return value to a string (which is how it
> > gets stored in the ACMEOrder object anyway).
> > 
> > I'd further suggest that by convention, where possible, the string
> > be a representation of issuer+serial, which is a bit nicer for
> > humans looking at the stored objects than a base64url-encoded
> > big-endian bigint.
> > 
> > What do you think?
> > 
> > Cheers,
> > Fraser
> 
> Hi Fraser,
> 
> I agree there is a problem, but I'm not sure about using issuer+serial
> as certificate ID. What do we use as "issuer", is it the issuer DN
> or the authority ID?
>
The issuer DN.

> Is issuer DN unique enough?
>
(issuer, serial) pair must be globally unique.

> How do we join with
> the serial number?
> What format do we use for serial number?
>

Doesn't really matter as long as it is unambiguous.  For example,
serial as decimal number, followed by ';', followed by string
representation of Issuer DN.

> What if we need to add another field in the future? It seems there's going to
> be many questions/issues with this solution.
> 
It is up to the ACMEBackend to produce a certificate ID.  I'm simply
proposing this because a backend could contain multiple CAs with
separate serial number domains, hence deriving certificate ID from
serial number alone would not be unique.  The idea of
(issuer,serial) pair is just a suggested convention.  Some backends
e.g. might prefer UUIDs or whatever makes it easy to retrieve a
certificate/chain.

> How about this instead?
> 
> 1. Change issueCertificate() to return the full cert chain.
> 2. Store the cert chain in a "certs" table in ACME database.
> 3. Autogenerate the cert ID for each cert record.
> 4. Store the account ID in the cert record.
> 5. Store the cert ID in the order record.
> 
> So a copy of the cert will be stored in ACME database. The cert
> ID will be unique for that particular ACME server. We don't need
> to include the issuer DN/ID. The cert serial number will not matter
> either. We can also use the certs table to authorize revocation
> requests.
>
I thought about this a little while back, and I prefer the current
approach of storing an identifier as a "handle" to retrieve the cert
from the backend.  Cert objects will increase the size of
records/objects significantly.  For the LDAP backend it could be a
problem, both for disk usage but in particular for replication.

I'm OK with the idea of *optional* certificate/chain storage in the
ACME database, e.g. for backends that do not support retrieval.  But
I don't think we need that with the current backends (certainly not
with the PKIBackend).

> The cert ID is not meant to be human readable anyway (as
> shown in RFC 8555).
> 

But it doesn't matter if it is human readable.  Either way, storing
only the serial number is not enough IMO.

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] ACME certificate IDs

[Fraser Tweedale]

Hi Endi,

Just want to quickly discuss certificate IDs.

Currently on ACMEBackend interface we have

  public BigInteger issueCertificate(String csr);

I think this is a bit of a problem.  e.g. Dogtag currently supports
multiple issuers (LWCAs).  It is incidental that serial numbers do
not collide.  This might not hold for other backends.  Yet we need
the certificate ID to uniquely identify the certificate, so that we
can retrieve it, revoke it, etc.

I suggest changing the return value to a string (which is how it
gets stored in the ACMEOrder object anyway).

I'd further suggest that by convention, where possible, the string
be a representation of issuer+serial, which is a bit nicer for
humans looking at the stored objects than a base64url-encoded
big-endian bigint.

What do you think?

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Dogtag Build

[Fraser Tweedale]

On Tue, Jan 28, 2020 at 07:02:36PM +0530, Sharath wrote:
> Hello Team,
> 
> I have taken the source code git repository, currently pointing
> origin/DOGTAG_10_6_BRANCH. Can you please text the steps to build Dogtag PKI
> source ?
> 
> ./build.sh is failed due to dependencies...
> 
> is there any automated script or solution to install the required
> dependencies ?
> 
Try yum-builddep(1), from the yum-utils package:

  yum-builddep pki.spec

Cheers,
Fraser

> Currently using below OS:
> 
> NAME="CentOS Linux"
> VERSION="7 (Core)"
> ID="centos"
> ID_LIKE="rhel fedora"
> VERSION_ID="7"
> PRETTY_NAME="CentOS Linux 7 (Core)"
> ANSI_COLOR="0;31"
> CPE_NAME="cpe:/o:centos:centos:7"
> HOME_URL="https://www.centos.org/;
> BUG_REPORT_URL="https://bugs.centos.org/;
> 
> CENTOS_MANTISBT_PROJECT="CentOS-7"
> CENTOS_MANTISBT_PROJECT_VERSION="7"
> REDHAT_SUPPORT_PRODUCT="centos"
> REDHAT_SUPPORT_PRODUCT_VERSION="7"
> 
> Thanks,
> 
> Sharath
> 
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [acme] getOrderByAuthorization() / orders and authorisations

[Fraser Tweedale]

On Thu, Dec 05, 2019 at 11:18:15AM +1000, Fraser Tweedale wrote:
> On Wed, Dec 04, 2019 at 06:36:24PM -0500, Endi Sukma Dewata wrote:
> > - Original Message -
> > > Just want to flag something related to ACME orders and
> > > authorisations.
> > > 
> > > In ACME authorizations can be shared by multiple orders.  In fact
> > > you can also "preauthorize" your account for an identifier, so there
> > > can also be a authorizations with no orders attached.
> > > 
> > > Does the way we have implemented the ACME service ensure that an
> > > authorization has only one order (or at most one order)?  If so, do
> > > we want it that way?  It entails that every identifier must be
> > > re-authorised upon every order.
> > > 
> > > Personally I think this is not the way we want to go.  Let me
> > > describe a scenario.
> > > 
> > > Client orders a cert for a.example.com, completes the authorisation
> > > for a.example.com, and gets the cert.
> > > 
> > > Shortly afterwards, they realise they also need b.example.com on the
> > > certificate.  So they make a new order with BOTH identifiers.
> > > 
> > > Should the client have to complete another authorisation for
> > > a.example.com, while their existing authorisation remains "fresh"
> > > (unexpired)?  It is valid to require the client to re-authorise
> > > every identifier for every order.  But it is not optimal.  Ideally
> > > we should observe that for the account there is already a
> > > non-expired authorisation for "a.example.com", and attach that to
> > > the order (along with the new authorisation for "b.example.com"
> > > which the client must complete).
> > > 
> > > Anyhow just some ideas as I proceed with implementation of the LDAP
> > > database implement.  Let me know your thoughts.
> > 
> > I think you're right. The database schema itself is not limiting to
> > one order per authorization, but the current code is making that
> > assumption.
> > 
> > We could change getOrderByAuthorization() to getOrdersByAuthorization(),
> > then move this code into a loop to process all orders associated to
> > that authorization:
> > https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMEChallengeService.java#L124-L144
> > 
> > If we want to reuse existing authorizations, we will need to modify this
> > code to find an existing authorization that is still valid instead of
> > creating a new one:
> > https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMENewOrderService.java#L72-L83
> > 
> OK, I'll file a ticket now and we can come back to it later.
> 
Ticket is https://projects.engineering.redhat.com/browse/RHCS-814,
part of the RHCS-35 epic.

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [acme] getOrderByAuthorization() / orders and authorisations

[Fraser Tweedale]

Just want to flag something related to ACME orders and
authorisations.

In ACME authorizations can be shared by multiple orders.  In fact
you can also "preauthorize" your account for an identifier, so there
can also be a authorizations with no orders attached.

Does the way we have implemented the ACME service ensure that an
authorization has only one order (or at most one order)?  If so, do
we want it that way?  It entails that every identifier must be
re-authorised upon every order.

Personally I think this is not the way we want to go.  Let me
describe a scenario.

Client orders a cert for a.example.com, completes the authorisation
for a.example.com, and gets the cert.

Shortly afterwards, they realise they also need b.example.com on the
certificate.  So they make a new order with BOTH identifiers.

Should the client have to complete another authorisation for
a.example.com, while their existing authorisation remains "fresh"
(unexpired)?  It is valid to require the client to re-authorise
every identifier for every order.  But it is not optimal.  Ideally
we should observe that for the account there is already a
non-expired authorisation for "a.example.com", and attach that to
the order (along with the new authorisation for "b.example.com"
which the client must complete).

Anyhow just some ideas as I proceed with implementation of the LDAP
database implement.  Let me know your thoughts.

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] How to generate the certificate in pkcs #12 format using Dogtag PKI

[Fraser Tweedale]

On Fri, Nov 01, 2019 at 05:29:40PM +0530, Sharath wrote:
> HI Team,
> 
> 1. Can you please help, how to generate the certificate using pkcs #12
> format??
> 
Hi Sharath,

PKCS #12 is a key and certificate archival format.  The main use of
PKCS #12 in Dogtag is retrieving archived keys from the KRA (key
recovery authority).

If you have a certificate and the corresponding private key you can
create a PKCS #12 file using 'openssl pkcs12', or for keys in NSS
databases 'pk12util'.

If provide more context about your use case, we may be able to
provide more assistance :)

> 2. Is there any to validate the certificate with password using Dogtag PKI
> ??
> 
Again, it's not clear what you're trying to do.  But with PKI you
never need a passphrase or private key to validate certificate
signatures.

Cheers,
Fraser

> Thanks,
> 
> Sharath
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Dogtag+FreeIPA: adapting to the Fedora mass orphaning

[Fraser Tweedale]

On Mon, Mar 11, 2019 at 03:58:17PM +0100, François Cami wrote:
> Hi,
> 
> The Java maintainers have orphaned most, if not all, of the Java stack
> in Fedora, in favor of modules:
> https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/message/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/
> 
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/ITDMQ7UACH4CL6754IMOYQ45QOBVPOX6/
> 
> As this change would lead into a lot of retired packages (maven and
> all that depends on it, like Dogtag), there was a proposal to create a
> SIG that would take care of these packages.
> It does not seem to have advanced much for the past month:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/I7AP2G7KUBGT6FP4GJBDBLCHZJ54YZG2/#I7AP2G7KUBGT6FP4GJBDBLCHZJ54YZG2
> 
> And it seems unrealistic for the Dogtag and FreeIPA teams to take over
> all these packages.
> 
> In the future packages will be able to BuildRequire modules:
> https://tree.taiga.io/project/modularity-wg/epic/12
> but it is not possible yet and there is no ETA.
> 
> The consequence is that Dogtag will be considered FTBFS as soon as
> maven and other dependencies are retired.
> Dogtag will therefore will be retired (along with FreeIPA) if
> maintenance for the dependencies is not picked up.
> 
> There does not seem to be a good solution except by moving both Dogtag
> and FreeIPA to modules (where we could BR: existing modules) before
> Fedora releng starts to retire our packages.
> 
> Thoughts?
> 
> Cheers
> François
> 
We are already in a module for RHEL 8.  I don't perceive any major
disadvantage if we have to move to modules in Fedora too.  Are there
any big reasons, from a user point of view, against moving to
modules?

Thanks,
Fraser

> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] New update: PKI 10.6.7 and its deps

[Fraser Tweedale]

Dear Dinesh,

The 10.6.7-1 update[1] was given negative karma due to FreeIPA
installation failure[2] on openqa.  I have spent considerable time
trying to reproduce the failure using the same package from
updates-testing, without success.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-83e180a755
[2] https://openqa.fedoraproject.org/tests/291997

The error in the openqa logs seems to be something to do with the
resteasy jackson provider and inability to construct the
ConfigurationRequest class.  Says it can't see the zero-arg
constructor... (it's definitely there!)

I'm on PTO tomorrow but keep me in the loop if you make any
progress.

Cheers,
Fraser

On Fri, Oct 05, 2018 at 12:07:22PM -0400, Dinesh Prasanth Moluguwan 
Krishnamoorthy wrote:
> Hi everyone,
> Today, we have released a new update of pki-core and its dependencies.
> PKI 10.6.7 is now available upstream:
> https://github.com/dogtagpki/pki/releases/tag/v10.6.7Tomcatjss 7.3.6 is
> now available upstream:
> https://github.com/dogtagpki/tomcatjss/releases/tag/v7.3.6
> Fedora 28 builds are available via the following update:pki-core,
> nuxwdog, dogtag-pki: 
> https://bodhi.fedoraproject.org/updates/pki-core-10.6.7-1.fc28%20nuxwdog-1.0.5-2.fc28%20dogtag-pki-10.6.7-1.fc28tomcatjss:
>  https://bodhi.fedoraproject.org/updates/FEDORA-2018-5558d54d37
> Fedora 29 builds are available via the following update:pki-core,
> nuxwdog, dogtag-pki, tomcatjss:
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-fd68715f9c
> Rawhide builds are available in Koji.
> Fedora 27 builds are available in this COPR repository:
> https://copr.fedorainfracloud.org/coprs/g/pki/10.6/
> Regards,Dinesh

> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] New RFCs 8398 and 8399 update RFC 5280 (X.509)

[Fraser Tweedale]

Just a quick heads up that a couple of new RFCs[1][2] update RFC
5280 w.r.t. i18n support.

[1] https://tools.ietf.org/html/rfc8398
[2] https://tools.ietf.org/html/rfc8399

The most notable change is a new otherName type to represent
internationalised email addresses (i.e. when the local part is not
ASCII).  I have filed a ticket[3] to support this in FreeIPA (no
Dogtag changes are needed).  I don't think it is urgent, but
eventually someone will ask for it.

[3] https://pagure.io/freeipa/issue/7564

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] PKI 10.6.0 and TomcatJSS 7.3.0

[Fraser Tweedale]

On Tue, May 01, 2018 at 09:34:23PM -0400, Endi Sukma Dewata wrote:
> Hi,
> 
> PKI 10.6.0 and TomcatJSS 7.3.0 has officially been released
> upstream and in Fedora 28:
> 
> https://github.com/dogtagpki/pki/releases/tag/v10.6.0
> https://github.com/dogtagpki/tomcatjss/releases/tag/v7.3.0
> 
> Please note that there are no changes since the last Release
> Candidate.
> 
> Thanks for your contributions!
> 
\o/ thanks, all, for your efforts.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Dogtag PKI Website URL

[Fraser Tweedale]

On Tue, Mar 27, 2018 at 09:52:22PM -0400, Endi Sukma Dewata wrote:
> - Original Message -
> > On Tue, Mar 27, 2018 at 11:16:01AM -0400, Endi Sukma Dewata wrote:
> > > Hi,
> > > 
> > > The Dogtag PKI Website URL has changed as follows:
> > > 
> > > * Old URL: http://pki.fedoraproject.org
> > > * New URL: http://www.dogtagpki.org
> > > 
> > > Please use the new URL whenever possible. The old URL should
> > > automatically be redirected to the new URL, so all existing links
> > > should continue to work.
> > > 
> > > Unfortunately, there was a glitch during the transition yesterday
> > > causing it to be redirected to redhat.com. If you are experiencing
> > > this, you may need to clear the browser cache/history. Please refer
> > > to your browser's documentation since the steps are browser-specific.
> > > 
> > > Sorry for the inconvenience. Thanks!
> > > 
> > Thanks for the update, Endi.
> > 
> > Now that the domain change is done, what needs to be done to enable
> > TLS?
> > 
> > Thanks,
> > Fraser
> 
> I think Matt/Nathan is in the process of getting an SSL cert, unless
> there's an easy way to use Let's Encrypt?
> 

We should be able to use the ACME HTTP or DNS challenges to get a
certificate from Let's Encrypt.  Not sure which would be easiest to
get going (and automate) on OpenShift.  Here's a recently published
article on the official OpenShift blog about it:

https://blog.openshift.com/lets-encrypt-acme-v2-api/

It's a shame OpenShift Online hasn't got automatic OOTB TLS support
via ACME/LE yet.  I have them a heads-up years ago.  We are behind
the competition.

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Dogtag PKI Website URL

[Fraser Tweedale]

On Tue, Mar 27, 2018 at 11:16:01AM -0400, Endi Sukma Dewata wrote:
> Hi,
> 
> The Dogtag PKI Website URL has changed as follows:
> 
> * Old URL: http://pki.fedoraproject.org
> * New URL: http://www.dogtagpki.org
> 
> Please use the new URL whenever possible. The old URL should
> automatically be redirected to the new URL, so all existing links
> should continue to work.
> 
> Unfortunately, there was a glitch during the transition yesterday
> causing it to be redirected to redhat.com. If you are experiencing
> this, you may need to clear the browser cache/history. Please refer
> to your browser's documentation since the steps are browser-specific.
> 
> Sorry for the inconvenience. Thanks!
> 
Thanks for the update, Endi.

Now that the domain change is done, what needs to be done to enable
TLS?

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] CMS.debug(Throwable e); stack trace suppressed?

[Fraser Tweedale]

On Fri, Mar 09, 2018 at 07:02:23PM +1000, Fraser Tweedale wrote:
> Hi,
> 
> It seems that with the change in logging backend, calls to
> CMS.debug(Throwable e) no longer print the stack trace.  The name of
> the exception is printed by the error message has been suppressed.
> 
> I couldn't work out why this is happening but in my working tree I'm
> carrying the below change to get the stack traces back.  Not sure if
> it's a "proper" way to fix it but it's doing the trick.
> 
Another thing I just remembered to mention: when the day rolls over
the debug log starts going to stdout/journal(?), instead of a file
with the new date.  I have to restart the server to get it logging
to the expected file after the day changes.

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] IPAddress General Name patches

[Fraser Tweedale]

Hi Christina et al,

Could someone with a familiarity/interest in IPAddress altnames /
name constraints please review this patchset and the three related
patchsets, when you have time?

https://review.gerrithub.io/#/c/398356/

The related BZ is
https://bugzilla.redhat.com/show_bug.cgi?id=1538311 (Using a Netmask
produces an odd entry in a certifcate).

Any questions, you can reply or note them in gerrit.

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Gerrit submit type

[Fraser Tweedale]

On Mon, Oct 09, 2017 at 02:12:17PM -0400, Ade Lee wrote:
> After discussion in CS meeting:
> 
> Policy now set to "rebase if necessary".
> 
> Ade
> 
Great, thanks!

> On Mon, 2017-10-09 at 12:38 -0400, Ade Lee wrote:
> > Can you describe a bit the ramifications of this change and why it is
> > needed?  
> > 
> > I notice that most of the Openstack projects use the default "Merge
> > If
> > Necessary", and want to understand (or at least document) why we want
> > to do things differently.
> > 
> > Ade
> > 
> > On Sat, 2017-10-07 at 13:26 +1000, Fraser Tweedale wrote:
> > > To whoever has management permission on gerrithub,
> > > 
> > > Could you please change the `Submit Type' config to `Rebase if
> > > Necessary'?  This will avoid explicit merge commits without the
> > > developer having to explicitly rebase the change before submitting.
> > > 
> > > https://gerrit-review.googlesource.com/Documentation/project-config
> > > ur
> > > ation.html#submit_type
> > > 
> > > Thanks,
> > > Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Gerrit submit type

[Fraser Tweedale]

To whoever has management permission on gerrithub,

Could you please change the `Submit Type' config to `Rebase if
Necessary'?  This will avoid explicit merge commits without the
developer having to explicitly rebase the change before submitting.

https://gerrit-review.googlesource.com/Documentation/project-configuration.html#submit_type

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0179 KRA: do not accumulate recovered keys in token

[Fraser Tweedale]

On Wed, Apr 26, 2017 at 06:40:59PM +1000, Fraser Tweedale wrote:
> On Thu, Apr 06, 2017 at 05:22:34PM +1000, Fraser Tweedale wrote:
> > The attached patch fixes a regression (I think?) where recovered
> > keys accumulate in the key storage token.
> > 
> > Thanks,
> > Fraser
> 
> Gerrit review: https://review.gerrithub.io/#/c/358632/
>
ACKed by Ade.  Pushed to master
(da624993c302a81a11f37f984d75c37a467dc5e5)

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] pki-0178, jss-0000..0002 - PKCS #12 key bag AES encryption

[Fraser Tweedale]

On Tue, Apr 11, 2017 at 03:23:18PM -0700, Christina Fu wrote:
> Thank you. Please see review comments:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1355358#c6
> 
> I will review PKCS12Util later.
> 
> Christina
> 
Updated patch jss-0002 and also created
https://bugzilla.mozilla.org/show_bug.cgi?id=1359731 with some
other JSS patches.

Created Gerrit review branch for Dogtag patches:
https://review.gerrithub.io/#/c/358634/.  This includes patch
pki-0178 and also a new patch to change KRA PKCS #12 recovery to use
AES, which depends on the new JSS patches linked above.

Thanks,
Fraser

> 
> On 04/10/2017 11:30 PM, Fraser Tweedale wrote:
> > On Thu, Apr 06, 2017 at 03:45:55PM -0700, Christina Fu wrote:
> > > Hi Fraser,
> > > 
> > > Could you please do the following first?
> > > 
> > > 1.  file a Mozilla bugzilla bug for this against Product JSS Release 
> > > 4.4.1,
> > > then assign to yourself:
> > > https://bugzilla.mozilla.org/
> > > 2. After making sure your patch compiles well with the 4.4.1 base, attach
> > > the patch to that ticket, and mark reviewers
> > > 
> > > thanks!
> > > 
> > > Christina
> > > 
> > Thanks Christina, I filed
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1355358
> > 
> > I was unable to assign myself to the bug ('Assignee' field is not
> > active when I go to Edit Bug.
> > 
> > Also not sure how to "mark reviewers".  I added you and Elio to Cc
> > though.
> > 
> > Thanks,
> > Fraser
> > 
> > > On 04/04/2017 02:56 AM, Fraser Tweedale wrote:
> > > > Hi team,
> > > > 
> > > > Please review attached patches for JSS and Dogtag that:
> > > > 
> > > > - add some new EncryptedPrivateKeyInfo export and import functions
> > > > to JSS
> > > > 
> > > > - update Dogtag's `pki pkcs12' command to use the new functions to
> > > > achieve AES encryption of the key bags, with wrapping/unwrapping
> > > > occurring on the token.
> > > > 
> > > > PKCS #12 files produced by current releases continue to import
> > > > properly (of course, this is an important test vector).
> > > > 
> > > > These patches do not address the PKCS #12 KRA recovery export; This
> > > > is my next task and separate patches will be produced.
> > > > 
> > > > Thanks,
> > > > Fraser
> 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0179 KRA: do not accumulate recovered keys in token

[Fraser Tweedale]

On Thu, Apr 06, 2017 at 05:22:34PM +1000, Fraser Tweedale wrote:
> The attached patch fixes a regression (I think?) where recovered
> keys accumulate in the key storage token.
> 
> Thanks,
> Fraser

Gerrit review: https://review.gerrithub.io/#/c/358632/

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0159..0161 Fix config param removal in profile modification

[Fraser Tweedale]

I have created a gerrit review for this patchset:
https://review.gerrithub.io/#/c/357607/

Thanks,
Fraser

On Tue, Feb 07, 2017 at 09:39:52PM +1000, Fraser Tweedale wrote:
> Please review the attached patches which fix
> https://fedorahosted.org/pki/ticket/2588, a bug in profile
> modification where config params can only be added or changed, but
> not removed.
> 
> Thanks,
> Fraser

> From 0a86f63cfe2d5391befe401541e9dcc0dae6ce29 Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Tue, 7 Feb 2017 17:27:06 +1000
> Subject: [PATCH 159/161] LDAPProfileSubsystem: avoid duplicating logic in
>  superclass
> 
> Part of: https://fedorahosted.org/pki/ticket/2588
> ---
>  .../cmscore/profile/AbstractProfileSubsystem.java  |  7 +++-
>  .../cmscore/profile/LDAPProfileSubsystem.java  | 43 
> --
>  2 files changed, 13 insertions(+), 37 deletions(-)
> 
> diff --git 
> a/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
>  
> b/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
> index 
> 116b8e2026e80b012fb87647fd8924b567194fa3..2a209ad5b2656d65db57d36b7ecb2745527ab081
>  100644
> --- 
> a/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
> +++ 
> b/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
> @@ -121,7 +121,7 @@ public abstract class AbstractProfileSubsystem implements 
> IProfileSubsystem {
>  /**
>   * Commits a profile.
>   */
> -public void commitProfile(String id)
> +public synchronized void commitProfile(String id)
>  throws EProfileException {
>  IConfigStore cs = mProfiles.get(id).getConfigStore();
>  
> @@ -157,6 +157,11 @@ public abstract class AbstractProfileSubsystem 
> implements IProfileSubsystem {
>  
>  // finally commit the configStore
>  //
> +commitConfigStore(id, cs);
> +}
> +
> +protected void commitConfigStore(String id, IConfigStore cs)
> +throws EProfileException {
>  try {
>  cs.commit(false);
>  } catch (EBaseException e) {
> diff --git 
> a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
>  
> b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
> index 
> fff8ead3f2088aedaf5856c308dd33be90af7779..bce675e7bf993d97a086fb830e34d5c4f396
>  100644
> --- 
> a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
> +++ 
> b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
> @@ -303,43 +303,14 @@ public class LDAPProfileSubsystem
>  readProfile(entry);
>  }
>  
> +/**
> + * Commit the configStore and track the resulting
> + * entryUSN and (in case of add) the nsUniqueId
> + */
>  @Override
> -public synchronized void commitProfile(String id) throws 
> EProfileException {
> -LDAPConfigStore cs = (LDAPConfigStore) 
> mProfiles.get(id).getConfigStore();
> -
> -// first create a *new* profile object from the configStore
> -// and initialise it with the updated configStore
> -//
> -IPluginRegistry registry = (IPluginRegistry)
> -CMS.getSubsystem(CMS.SUBSYSTEM_REGISTRY);
> -String classId = mProfileClassIds.get(id);
> -IPluginInfo info = registry.getPluginInfo("profile", classId);
> -String className = info.getClassName();
> -IProfile newProfile = null;
> -try {
> -newProfile = (IProfile) Class.forName(className).newInstance();
> -} catch (ClassNotFoundException | InstantiationException | 
> IllegalAccessException e) {
> -throw new EProfileException("Could not instantiate class '"
> -+ classId + "' for profile '" + id + "': " + e);
> -}
> -newProfile.setId(id);
> -try {
> -newProfile.init(this, cs);
> -} catch (EBaseException e) {
> -throw new EProfileException(
> -"Failed to initialise profile '" + id + "': " + e);
> -}
> -
> -// next replace the existing profile with the new profile;
> -// this is to avoid any intermediate state where the profile
> -// is not fully initialised with its inputs, outputs and
> -// policy objects.
> -//
> -mProfiles.put(id, newProfile);
> -
> -// finally commit the configStore and track the resulting
> -// entr

Re: [Pki-devel] [PATCH] pki-0178, jss-0000..0002 - PKCS #12 key bag AES encryption

[Fraser Tweedale]

On Thu, Apr 06, 2017 at 03:45:55PM -0700, Christina Fu wrote:
> Hi Fraser,
> 
> Could you please do the following first?
> 
> 1.  file a Mozilla bugzilla bug for this against Product JSS Release 4.4.1,
> then assign to yourself:
> https://bugzilla.mozilla.org/
> 2. After making sure your patch compiles well with the 4.4.1 base, attach
> the patch to that ticket, and mark reviewers
> 
> thanks!
> 
> Christina
> 
Thanks Christina, I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1355358

I was unable to assign myself to the bug ('Assignee' field is not
active when I go to Edit Bug.

Also not sure how to "mark reviewers".  I added you and Elio to Cc
though.

Thanks,
Fraser

> 
> On 04/04/2017 02:56 AM, Fraser Tweedale wrote:
> > Hi team,
> > 
> > Please review attached patches for JSS and Dogtag that:
> > 
> > - add some new EncryptedPrivateKeyInfo export and import functions
> >to JSS
> > 
> > - update Dogtag's `pki pkcs12' command to use the new functions to
> >achieve AES encryption of the key bags, with wrapping/unwrapping
> >occurring on the token.
> > 
> > PKCS #12 files produced by current releases continue to import
> > properly (of course, this is an important test vector).
> > 
> > These patches do not address the PKCS #12 KRA recovery export; This
> > is my next task and separate patches will be produced.
> > 
> > Thanks,
> > Fraser
> 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0179 KRA: do not accumulate recovered keys in token

[Fraser Tweedale]

The attached patch fixes a regression (I think?) where recovered
keys accumulate in the key storage token.

Thanks,
Fraser
From ab470a00827673f327d5f171ff3fdf1baea4ae5e Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 6 Apr 2017 16:07:07 +1000
Subject: [PATCH] KRA: do not accumulate recovered keys in token

When using token-based unwrapping of archived keys, the key is being
stored in the token.  We do not want to accumulate the keys here;
make them temporary.

Part of: https://pagure.io/dogtagpki/issue/2610
---
 base/kra/src/com/netscape/kra/RecoveryService.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/base/kra/src/com/netscape/kra/RecoveryService.java 
b/base/kra/src/com/netscape/kra/RecoveryService.java
index 
c89e2f388f037bb8608b24389b26f8076511adf7..817f3f01586e851007d25e0724c03d213f0b6c4a
 100644
--- a/base/kra/src/com/netscape/kra/RecoveryService.java
+++ b/base/kra/src/com/netscape/kra/RecoveryService.java
@@ -409,7 +409,7 @@ public class RecoveryService implements IService {
 privKey = mStorageUnit.unwrap(
 keyRecord.getPrivateKeyData(),
 pubkey,
-false,
+true /* temporary */,
 
keyRecord.getWrappingParams(mKRA.getStorageKeyUnit().getOldWrappingParams()));
 } catch (Exception e) {
 mKRA.log(ILogger.LL_FAILURE, 
CMS.getLogMessage("CMSCORE_KRA_PRIVATE_KEY_NOT_FOUND"));
-- 
2.9.3

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] KRA questions

[Fraser Tweedale]

Hi all,

I have some questions about KRA operation.  These questions came up
as part of my PKCS #12 AES key bag encryption effort.

1) the kra.allowEncDecrypt.recovery setting controls whether
unwrapping the archived key takes place on a crypto token (the
default) or within Dogtag.  It seems to be an instance-wide setting.

What is the purpose of this setting?  Is it just a provision for
environments that do not support the key (un)wrapping on a token?
Or does it have some other purpose?

2) When kra.allowEncDecrypt.recovery is false, the private keys
being recovered accumulate in the /etc/pki/pki-tomcat/alias NSSDB
(i.e. the NSS internal token).  Presumably the same occurs for
hardware tokens, too.  The unwrapping of the archived key in
RecoveryService.recoverKey() calls with boolean temporary = false;

This seems like the wrong behaviour... why would we want to keep the
key in the token?

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] pki-0178, jss-0000..0002 - PKCS #12 key bag AES encryption

[Fraser Tweedale]

Hi team,

Please review attached patches for JSS and Dogtag that:

- add some new EncryptedPrivateKeyInfo export and import functions
  to JSS

- update Dogtag's `pki pkcs12' command to use the new functions to
  achieve AES encryption of the key bags, with wrapping/unwrapping
  occurring on the token.

PKCS #12 files produced by current releases continue to import
properly (of course, this is an important test vector).

These patches do not address the PKCS #12 KRA recovery export; This
is my next task and separate patches will be produced.

Thanks,
Fraser
From de2d7f049eb4462c7442795a77a8a915ae70d216 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 3 Apr 2017 11:07:24 +1000
Subject: [PATCH 0/2] Add SEC_OID mappings for AES ECB/CBC algorithms

---
 org/mozilla/jss/crypto/Algorithm.c  |  8 +++-
 org/mozilla/jss/crypto/Algorithm.h  |  2 +-
 org/mozilla/jss/crypto/Algorithm.java   |  8 
 org/mozilla/jss/crypto/EncryptionAlgorithm.java | 18 --
 4 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/org/mozilla/jss/crypto/Algorithm.c 
b/org/mozilla/jss/crypto/Algorithm.c
index 
8679eadca573fdb2bc7903c3e5d0a1a05d4bbd2f..d32bcad469c45c9edcdd5bedfa5e98f2fab0e3a2
 100644
--- a/org/mozilla/jss/crypto/Algorithm.c
+++ b/org/mozilla/jss/crypto/Algorithm.c
@@ -86,7 +86,13 @@ JSS_AlgInfo JSS_AlgTable[NUM_ALGS] = {
 /* 55 */{SEC_OID_PKCS5_PBMAC1, SEC_OID_TAG},
 /* 56 */{SEC_OID_ANSIX962_ECDSA_SIGNATURE_SPECIFIED_DIGEST, SEC_OID_TAG},
 /* 57 */{CKM_NSS_AES_KEY_WRAP, PK11_MECH},
-/* 58 */{CKM_NSS_AES_KEY_WRAP_PAD, PK11_MECH}
+/* 58 */{CKM_NSS_AES_KEY_WRAP_PAD, PK11_MECH},
+/* 59 */{SEC_OID_AES_128_ECB, SEC_OID_TAG},
+/* 60 */{SEC_OID_AES_128_CBC, SEC_OID_TAG},
+/* 61 */{SEC_OID_AES_192_ECB, SEC_OID_TAG},
+/* 62 */{SEC_OID_AES_192_CBC, SEC_OID_TAG},
+/* 63 */{SEC_OID_AES_256_ECB, SEC_OID_TAG},
+/* 64 */{SEC_OID_AES_256_CBC, SEC_OID_TAG}
 /* REMEMBER TO UPDATE NUM_ALGS!!! */
 };
 
diff --git a/org/mozilla/jss/crypto/Algorithm.h 
b/org/mozilla/jss/crypto/Algorithm.h
index 
ec2dddb76e66187fce29051069d84293315199f0..c18623185184590799c3c2e0f0627579661051f7
 100644
--- a/org/mozilla/jss/crypto/Algorithm.h
+++ b/org/mozilla/jss/crypto/Algorithm.h
@@ -24,7 +24,7 @@ typedef struct JSS_AlgInfoStr {
 JSS_AlgType type;
 } JSS_AlgInfo;
 
-#define NUM_ALGS 59
+#define NUM_ALGS 65
 
 extern JSS_AlgInfo JSS_AlgTable[];
 extern CK_ULONG JSS_symkeyUsage[];
diff --git a/org/mozilla/jss/crypto/Algorithm.java 
b/org/mozilla/jss/crypto/Algorithm.java
index 
919c2ece0608418015a2f05e7c363cdd70a2b16a..1818bd4703b8d55ae81a64d468a5ade890b21382
 100644
--- a/org/mozilla/jss/crypto/Algorithm.java
+++ b/org/mozilla/jss/crypto/Algorithm.java
@@ -212,4 +212,12 @@ public class Algorithm {
 protected static final short 
SEC_OID_ANSIX962_ECDSA_SIGNATURE_SPECIFIED_DIGEST=56;
 protected static final short CKM_NSS_AES_KEY_WRAP=57;
 protected static final short CKM_NSS_AES_KEY_WRAP_PAD=58;
+
+// AES Encryption Algorithms
+protected static final short SEC_OID_AES_128_ECB = 59;
+protected static final short SEC_OID_AES_128_CBC = 60;
+protected static final short SEC_OID_AES_192_ECB = 61;
+protected static final short SEC_OID_AES_192_CBC = 62;
+protected static final short SEC_OID_AES_256_ECB = 63;
+protected static final short SEC_OID_AES_256_CBC = 64;
 }
diff --git a/org/mozilla/jss/crypto/EncryptionAlgorithm.java 
b/org/mozilla/jss/crypto/EncryptionAlgorithm.java
index 
db10305c14f7c5d75920624c1243feae09b0c92a..8e389b47035d51f073a9005756aed0cde915e024
 100644
--- a/org/mozilla/jss/crypto/EncryptionAlgorithm.java
+++ b/org/mozilla/jss/crypto/EncryptionAlgorithm.java
@@ -347,12 +347,14 @@ public class EncryptionAlgorithm extends Algorithm {
 { 2, 16, 840, 1, 101, 3, 4, 1 } );
 
 public static final EncryptionAlgorithm
-AES_128_ECB = new EncryptionAlgorithm(CKM_AES_ECB, Alg.AES, Mode.ECB,
+AES_128_ECB = new EncryptionAlgorithm(SEC_OID_AES_128_ECB,
+Alg.AES, Mode.ECB,
 Padding.NONE, (Class)null, 16,
 AES_ROOT_OID.subBranch(1), 128);
 
 public static final EncryptionAlgorithm
-AES_128_CBC = new EncryptionAlgorithm(CKM_AES_CBC, Alg.AES, Mode.CBC,
+AES_128_CBC = new EncryptionAlgorithm(SEC_OID_AES_128_CBC,
+Alg.AES, Mode.CBC,
 Padding.NONE, IVParameterSpecClasses, 16,
 AES_ROOT_OID.subBranch(2), 128);
 
@@ -361,11 +363,13 @@ public class EncryptionAlgorithm extends Algorithm {
 Padding.PKCS5, IVParameterSpecClasses, 16, null, 128); // no oid
 
 public static final EncryptionAlgorithm
-AES_192_ECB = new EncryptionAlgorithm(CKM_AES_ECB, Alg.AES, Mode.ECB,
+AES_192_ECB = new EncryptionAlgorithm(SEC_OID_AES_192_ECB,
+Alg.AES, Mode.ECB,
 Padding.NONE, (Class)null, 16, AES_ROOT_OID.subBranch(21), 192);
 
 public static final EncryptionAlgorithm
-AES_1

Re: [Pki-devel] [PATCH] 0167..0175 external authentication support

[Fraser Tweedale]

On Tue, Mar 07, 2017 at 11:16:37AM +1000, Fraser Tweedale wrote:
> Hi team,
> 
> Please review the attached patches, which add support for external
> authentication (e.g. GSS-API/SPNEGO).
> 
> These patches depend on some other outstanding patches:
> 0157, 0158, 0165, 0166.
> 
> You can review the whole branch (including those commits just
> mentioned) on GitHub:
> https://github.com/dogtagpki/pki/compare/master...frasertweedale:feature/1359-gssapi
> 
> Thanks!
> Fraser

7 patches acked by alee; pushed to master:

67d51413323e1d55fdc04ca5edf5d9f05afb0ebe Update ACLInterceptor to support 
external principals
ef84ef36be06944a7f6338ed022f13e066cd5c32 Update SessionContextInterceptor to 
handle external principals
76f60251f7e1b2f1f9ad1752121c0c5cb1cb5b8b Update AuthMethodInterceptor to handle 
external principals
433c7b70d7dd8609dea31b28aee042e48a41ac9f Add IAuthToken implementation for 
external principals
00cf1cd2c6b9f5d8116921e4c3f1d07e7708388e Add groups and request attributes to 
external principals
4cf87aa3babc4c7d8ea60a46cb548ebfee493ae4 CertProcessor: extract method 
setAuthTokenIntoRequest
295cb2f175711a85f371c0fa93c584ad235066e4 Define AgentCertAuthentication token 
keys in IAuthToken

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0163..0165 Include revocation reason in REST cert data

[Fraser Tweedale]

On Mon, Mar 13, 2017 at 03:59:24PM -0400, Ade Lee wrote:
> ACK
> 
Thanks; 0165 pushed to master
(6fa6b692882d00c8228aed7f5780b13f1b09c98c)

> On Wed, 2017-02-22 at 12:12 +1000, Fraser Tweedale wrote:
> > The following patches add the revocation reason to the REST cert
> > data (i.e. GET /ca/rest/certs/{id}).
> > 
> > Patches 0163 and 0164 were pushed under trivial rule.
> > 
> > Please review 0165.
> > 
> > Thanks,
> > Fraser
> > ___
> > Pki-devel mailing list
> > Pki-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0176..0177 small manpage fixes

[Fraser Tweedale]

Please review attached patches that fix a couple of problems in
pkispawn.8 and pki_default.cfg.5.

Thanks,
Fraser
From e6c683eec351be54fb65f22629e78865839bf263 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 9 Mar 2017 14:30:29 +1000
Subject: [PATCH 176/177] pkispawn.8: fix setup-ds.pl command name

---
 base/server/man/man8/pkispawn.8 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/base/server/man/man8/pkispawn.8 b/base/server/man/man8/pkispawn.8
index 
40ec7f0ad17acfa3a1e909dfac2ef16782dda6c6..002520a0b2207014989b82001ec4723fefd309f1
 100644
--- a/base/server/man/man8/pkispawn.8
+++ b/base/server/man/man8/pkispawn.8
@@ -1387,7 +1387,7 @@ Directory Server and Admin Server instances can be 
created with the following
 command:
 
 .IP
-\fBsetup-ds-admin.pl\fP
+\fBsetup-ds.pl\fP
 
 .PP
 Enable LDAPS in the Directory Server with the following command:
-- 
2.9.3

From 852c6e5783648bf9786aa6c4c3aa20ff90b86790 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 9 Mar 2017 15:38:50 +1000
Subject: [PATCH 177/177] pki_default.cfg.5: fix ca_signing tag name

---
 base/server/man/man5/pki_default.cfg.5 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/base/server/man/man5/pki_default.cfg.5 
b/base/server/man/man5/pki_default.cfg.5
index 
1eb4ab99b1863a1927fba0f3f69ccf2e0431211f..856081dcf195df325fe48172f32a2afaeeef8e85
 100644
--- a/base/server/man/man5/pki_default.cfg.5
+++ b/base/server/man/man5/pki_default.cfg.5
@@ -107,7 +107,7 @@ If an optional hardware security module (HSM) is being 
utilized (rather than the
 .SS SYSTEM CERTIFICATE PARAMETERS
 \fBpkispawn\fP sets up a number of system certificates for each subsystem.  
The system certificates which are required differ between subsystems.  Each 
system certificate is denoted by a tag, as noted below.  The different system 
certificates are:
 .IP
-* signing certificate ("signing").  Used to sign other certificates.  Required 
for CA.
+* signing certificate ("ca_signing").  Used to sign other certificates.  
Required for CA.
 .IP
 * OCSP signing certificate ("ocsp_signing" in CA, "signing" in OCSP).  Used to 
sign CRLs.  Required for OCSP and CA.
 .IP
-- 
2.9.3

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0166 CMS.getLogMessage: escape format elements in arguments

[Fraser Tweedale]

Hi team,

Please review attached patch that fixes an issue in CMS message
formatting: if one of the message arguments contains '{' or '}', in
subsequent logging this is interpreted as a FormatElement and
parsing fails.

Thanks,
Fraser
From 45c90767ff697209c4e46581f796807c0093f527 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 2 Mar 2017 16:32:21 +1000
Subject: [PATCH] CMS.getLogMessage: escape format elements in arguments

CMS.getLogMessage performs message formatting via MessageFormat,
then the message gets logged via a Logger.  The Logger also performs
message formatting via MessageFormat.  If the formatted log message
contains '{' or '}' (e.g. if it contains JSON) the MessageFormat
implementation interprets these as FormatElement delimiters and
parsing fails.

Update CMS.getLogMessage() to scan arguments for unsafe characters
and if found, escape the whole message so that subsequent logging
will succeed.

Part of: https://pagure.io/dogtagpki/issue/1359
---
 .../cmscore/src/com/netscape/cmscore/apps/CMSEngine.java | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java 
b/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java
index 
90ee8b90a4841ee79970c9b857b95468d7ecd2ec..31ec53f8aaeda818bf174111f115cf611267897c
 100644
--- a/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java
+++ b/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java
@@ -1592,7 +1592,21 @@ public class CMSEngine implements ICMSEngine {
 return msg;
 MessageFormat mf = new MessageFormat(msg);
 
-return mf.format(params);
+String escapedParams[] = new String[params.length];
+for (int i = 0; i < params.length; i++)
+escapedParams[i] = escapeLogMessageParam(params[i]);
+
+return mf.format(escapedParams);
+}
+
+/** Quote a string for inclusion in a java.text.MessageFormat
+ */
+private String escapeLogMessageParam(String s) {
+if (s == null)
+return null;
+if (s.contains("{") || s.contains("}"))
+return "'" + s.replaceAll("'", "''") + "'";
+return s;
 }
 
 public void debug(byte data[]) {
-- 
2.9.3

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0163..0165 Include revocation reason in REST cert data

[Fraser Tweedale]

The following patches add the revocation reason to the REST cert
data (i.e. GET /ca/rest/certs/{id}).

Patches 0163 and 0164 were pushed under trivial rule.

Please review 0165.

Thanks,
Fraser
From f50507eac86edba2fba01ff25d6937f7d991770e Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 22 Feb 2017 10:39:02 +1000
Subject: [PATCH 163/165] Remove unused import

Part of: https://fedorahosted.org/pki/ticket/2601
---
 base/server/cmscore/src/com/netscape/cmscore/dbs/RevocationInfo.java | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/dbs/RevocationInfo.java 
b/base/server/cmscore/src/com/netscape/cmscore/dbs/RevocationInfo.java
index 
36f470511ae1ec0ea31d1997a76f6e4655eb1b2b..2cc9acb583266c19bee7fbad43962d35785aaf45
 100644
--- a/base/server/cmscore/src/com/netscape/cmscore/dbs/RevocationInfo.java
+++ b/base/server/cmscore/src/com/netscape/cmscore/dbs/RevocationInfo.java
@@ -21,7 +21,6 @@ import java.io.Serializable;
 import java.util.Date;
 
 import netscape.security.x509.CRLExtensions;
-import netscape.security.x509.CRLReasonExtension;
 
 import com.netscape.certsrv.dbs.certdb.IRevocationInfo;
 
-- 
2.9.3

From dd77a7d4e199d7678176398324957c2d45e28205 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 22 Feb 2017 10:45:15 +1000
Subject: [PATCH 164/165] Refactor CertRetrievalRequest construction

Remove an unused constructor from CertRetrievalRequest, and add a
constructor that receives the CertId, simplifying usage.

Part of: https://fedorahosted.org/pki/ticket/2601
---
 base/ca/src/org/dogtagpki/server/ca/rest/CertService.java |  3 +--
 .../com/netscape/certsrv/cert/CertRetrievalRequest.java   | 15 ++-
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java 
b/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
index 
54a349e2a60c6fd7571c2cb43a0504d96050c11a..2f9f467294322428620e2dc800618cde59faf28d
 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
@@ -136,8 +136,7 @@ public class CertService extends PKIService implements 
CertResource {
 throw new BadRequestException("Unable to get certificate: Invalid 
id.");
 }
 
-CertRetrievalRequest data = new CertRetrievalRequest();
-data.setCertId(id);
+CertRetrievalRequest data = new CertRetrievalRequest(id);
 
 CertData certData = null;
 
diff --git 
a/base/common/src/com/netscape/certsrv/cert/CertRetrievalRequest.java 
b/base/common/src/com/netscape/certsrv/cert/CertRetrievalRequest.java
index 
ac8ea079ac468ed7d819f1ce68e494882b5a86d6..7e653d7111202a0583dd8de93411e73bf111ede5
 100644
--- a/base/common/src/com/netscape/certsrv/cert/CertRetrievalRequest.java
+++ b/base/common/src/com/netscape/certsrv/cert/CertRetrievalRequest.java
@@ -41,8 +41,6 @@ import com.netscape.certsrv.request.RequestIdAdapter;
 @XmlAccessorType(XmlAccessType.FIELD)
 public class CertRetrievalRequest {
 
-private static final String CERT_ID = "certId";
-
 @XmlElement
 @XmlJavaTypeAdapter(CertIdAdapter.class)
 protected CertId certId;
@@ -55,10 +53,8 @@ public class CertRetrievalRequest {
 // required for JAXB (defaults)
 }
 
-public CertRetrievalRequest(MultivaluedMap<String, String> form) {
-if (form.containsKey(CERT_ID)) {
-certId = new CertId(form.getFirst(CERT_ID));
-}
+public CertRetrievalRequest(CertId certId) {
+this.certId = certId;
 }
 
 /**
@@ -68,11 +64,4 @@ public class CertRetrievalRequest {
 return certId;
 }
 
-/**
- * @param CertId the CertId to set
- */
-public void setCertId(CertId certId) {
-this.certId = certId;
-}
-
 }
-- 
2.9.3

From 1ee1d50819811d364778add187026d4069b8ab68 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 22 Feb 2017 11:26:43 +1000
Subject: [PATCH 165/165] Include revocation reason in REST cert data

Fixes: https://fedorahosted.org/pki/ticket/2601
---
 .../src/org/dogtagpki/server/ca/rest/CertService.java  | 18 ++
 .../common/src/com/netscape/certsrv/cert/CertData.java | 10 ++
 2 files changed, 28 insertions(+)

diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java 
b/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
index 
2f9f467294322428620e2dc800618cde59faf28d..ebbab25728b0df2b9f64e7042a1e8002aebcdce2
 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
@@ -64,6 +64,7 @@ import com.netscape.certsrv.dbs.certdb.CertId;
 import com.netscape.certsrv.dbs.certdb.ICertRecord;
 import com.netscape.certsrv.dbs.certdb.ICertRecordList;
 import com.netscape.certsrv.dbs.certdb.ICertificateRepository;
+import com

[Pki-devel] [PATCH] 0162 Fix NPE in server shutdown when startup failed

[Fraser Tweedale]

The attached patch fixes an NPE that can occur if startup fails
(e.g. due to database unavailable).

Pushed under trivial rule.

Thanks,
Fraser
From aa9bca02d0469e16a93812564bf44369c30002da Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 20 Feb 2017 11:08:50 +1000
Subject: [PATCH] Fix NPE in server shutdown when startup failed

If server startup fails, the shutdown() routine tries to shut down
the logger instance, which may not have been initialised.  This
raises a NullPointerException which can mask the original exception.

Only attempt to shut down the logger instance if it is non-null.
---
 .../cmscore/src/com/netscape/cmscore/selftests/SelfTestSubsystem.java  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/selftests/SelfTestSubsystem.java 
b/base/server/cmscore/src/com/netscape/cmscore/selftests/SelfTestSubsystem.java
index 
d7d7a3a8974b0810f110aefe6823513a396288c1..4ddb42c67506c727bb52fdc6092a383f87ad22bb
 100644
--- 
a/base/server/cmscore/src/com/netscape/cmscore/selftests/SelfTestSubsystem.java
+++ 
b/base/server/cmscore/src/com/netscape/cmscore/selftests/SelfTestSubsystem.java
@@ -1883,7 +1883,8 @@ public class SelfTestSubsystem
 instance.shutdownSelfTest();
 }
 
-mLogger.shutdown();
+if (mLogger != null)
+mLogger.shutdown();
 }
 
 /**
-- 
2.9.3

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0150 Allow DirAclAuthz to be configured to read alternative entry

[Fraser Tweedale]

On Tue, Jan 24, 2017 at 02:45:48PM +1000, Fraser Tweedale wrote:
> The attached patch (part of the GSS-API effort) allows DirAclAuthz
> configuration to specify to read the ACLs from a different entry (it
> is currently hard-coded).
> 
> Thanks,
> Fraser
>
ACKed by alee; pushed to master:
76266bbf9b48f0ff01e7bfc9cd114c7ced460256

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0151..0155 Add profile component that copies CN to SAN

[Fraser Tweedale]

On Wed, Feb 01, 2017 at 05:25:58PM +1000, Fraser Tweedale wrote:
> Hi all,
> 
> The attached patches implement the long-desired feature to copy CN
> to SubjectAltName (https://fedorahosted.org/pki/ticket/1710).
> 
> I've also pushed the branch to my GitHub repo; feel free to review
> the patches there:
> https://github.com/frasertweedale/pki/commits/feature/1710-cn-to-san
> 
> Thanks,
> Fraser

ACKed by mharmsen and batkisso.

Pushed to master with following trivial changes:

- fix a missing import in upgrade scriptlet
- break upgrade scriptlet into separate patch, for easy exclusion
  or modification when backporting

* 31dfbb569756e8c28500b597ac4486f780761c4c Add upgrade script to add 
CommonNameToSANDefault plugin
* 9cb00049ec731cca36de822f6c1e834f7febcb4f Add profile component that copies CN 
to SAN dNSName
* 979b6a2da433e97c1ada6434b432aa4aabc47ab5 X500Name: add method to get all 
attributes of a given type
* a67816eebbed2332327fbf391f3e23223ee7690e SubjectAlternativeNameExtension: add 
GeneralNames getter/setter
* 225dd099efa7e2f752c3f50157aaec71a9834873 GeneralName: add method to get at 
inner value
* f371114134ee3b6a83b747eecf46e001080b1e9c DNSName: add method to get value

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0159..0161 Fix config param removal in profile modification

[Fraser Tweedale]

Please review the attached patches which fix
https://fedorahosted.org/pki/ticket/2588, a bug in profile
modification where config params can only be added or changed, but
not removed.

Thanks,
Fraser
From 0a86f63cfe2d5391befe401541e9dcc0dae6ce29 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 7 Feb 2017 17:27:06 +1000
Subject: [PATCH 159/161] LDAPProfileSubsystem: avoid duplicating logic in
 superclass

Part of: https://fedorahosted.org/pki/ticket/2588
---
 .../cmscore/profile/AbstractProfileSubsystem.java  |  7 +++-
 .../cmscore/profile/LDAPProfileSubsystem.java  | 43 --
 2 files changed, 13 insertions(+), 37 deletions(-)

diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
 
b/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
index 
116b8e2026e80b012fb87647fd8924b567194fa3..2a209ad5b2656d65db57d36b7ecb2745527ab081
 100644
--- 
a/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
+++ 
b/base/server/cmscore/src/com/netscape/cmscore/profile/AbstractProfileSubsystem.java
@@ -121,7 +121,7 @@ public abstract class AbstractProfileSubsystem implements 
IProfileSubsystem {
 /**
  * Commits a profile.
  */
-public void commitProfile(String id)
+public synchronized void commitProfile(String id)
 throws EProfileException {
 IConfigStore cs = mProfiles.get(id).getConfigStore();
 
@@ -157,6 +157,11 @@ public abstract class AbstractProfileSubsystem implements 
IProfileSubsystem {
 
 // finally commit the configStore
 //
+commitConfigStore(id, cs);
+}
+
+protected void commitConfigStore(String id, IConfigStore cs)
+throws EProfileException {
 try {
 cs.commit(false);
 } catch (EBaseException e) {
diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
 
b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
index 
fff8ead3f2088aedaf5856c308dd33be90af7779..bce675e7bf993d97a086fb830e34d5c4f396
 100644
--- 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
+++ 
b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
@@ -303,43 +303,14 @@ public class LDAPProfileSubsystem
 readProfile(entry);
 }
 
+/**
+ * Commit the configStore and track the resulting
+ * entryUSN and (in case of add) the nsUniqueId
+ */
 @Override
-public synchronized void commitProfile(String id) throws EProfileException 
{
-LDAPConfigStore cs = (LDAPConfigStore) 
mProfiles.get(id).getConfigStore();
-
-// first create a *new* profile object from the configStore
-// and initialise it with the updated configStore
-//
-IPluginRegistry registry = (IPluginRegistry)
-CMS.getSubsystem(CMS.SUBSYSTEM_REGISTRY);
-String classId = mProfileClassIds.get(id);
-IPluginInfo info = registry.getPluginInfo("profile", classId);
-String className = info.getClassName();
-IProfile newProfile = null;
-try {
-newProfile = (IProfile) Class.forName(className).newInstance();
-} catch (ClassNotFoundException | InstantiationException | 
IllegalAccessException e) {
-throw new EProfileException("Could not instantiate class '"
-+ classId + "' for profile '" + id + "': " + e);
-}
-newProfile.setId(id);
-try {
-newProfile.init(this, cs);
-} catch (EBaseException e) {
-throw new EProfileException(
-"Failed to initialise profile '" + id + "': " + e);
-}
-
-// next replace the existing profile with the new profile;
-// this is to avoid any intermediate state where the profile
-// is not fully initialised with its inputs, outputs and
-// policy objects.
-//
-mProfiles.put(id, newProfile);
-
-// finally commit the configStore and track the resulting
-// entryUSN and (in case of add) the nsUniqueId
-//
+protected void commitConfigStore(String id, IConfigStore configStore)
+throws EProfileException {
+LDAPConfigStore cs = (LDAPConfigStore) configStore;
 try {
 String[] attrs = {"entryUSN", "nsUniqueId"};
 LDAPEntry entry = cs.commitReturn(false, attrs);
-- 
2.9.3

From ca09f58f4a953fb8d40898a1924f236bba42fa29 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 7 Feb 2017 17:39:33 +1000
Subject: [PATCH 160/161] ISourceConfigStore: add clear() method to interface

The SourceConfigStore load() method does not clear the config store,
but this might be necessary to avoid stale data if wanting 

[Pki-devel] [PATCH] 0157..0158 authToken-related refactors

[Fraser Tweedale]

Please review attached patches; a couple of small refactors to ease
upcoming GSS-API work.

Thanks,
Fraser
From 71a94aba941b395a07a849eacb125b9657f70f59 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 7 Feb 2017 11:38:03 +1000
Subject: [PATCH 157/158] Define AgentCertAuthentication token keys in
 IAuthToken

Small refactor to define the auth token keys set by
AgentCertAuthentication in IAuthToken, so that consumers do not need
to import AgentCertAuthentication directly, or redefine the
constants.

Part of: https://fedorahosted.org/pki/ticket/1359
---
 .../com/netscape/certsrv/authentication/IAuthToken.java |  3 +++
 .../cms/authentication/AgentCertAuthentication.java | 17 +
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git 
a/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java 
b/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
index 
a3f240e9c35987462eb2f176de650a769df1005c..59c6af20c32e2ae7b94fb80208539c01303a9fcd
 100644
--- a/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
+++ b/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
@@ -37,8 +37,11 @@ public interface IAuthToken {
 /**
  * Constant for userid.
  */
+public static final String USER = "user";
+public static final String USER_DN = "userdn";
 public static final String USER_ID = "userid";
 public static final String UID = "uid";
+public static final String GROUP = "group";
 public static final String GROUPS = "groups";
 
 /* Subject name of the certificate in the authenticating entry */
diff --git 
a/base/server/cms/src/com/netscape/cms/authentication/AgentCertAuthentication.java
 
b/base/server/cms/src/com/netscape/cms/authentication/AgentCertAuthentication.java
index 
c65dd397148c989fd9aa4d0e1e4ae7faf735342d..b7fafc895781e4bc950fa60b03444a6ad33248c7
 100644
--- 
a/base/server/cms/src/com/netscape/cms/authentication/AgentCertAuthentication.java
+++ 
b/base/server/cms/src/com/netscape/cms/authentication/AgentCertAuthentication.java
@@ -57,13 +57,6 @@ import com.netscape.certsrv.usrgrp.IUser;
 public class AgentCertAuthentication implements IAuthManager,
 IProfileAuthenticator {
 
-/* result auth token attributes */
-public static final String TOKEN_USERDN = "user";
-public static final String TOKEN_USER_DN = "userdn";
-public static final String TOKEN_USERID = "userid";
-public static final String TOKEN_UID = "uid";
-public static final String TOKEN_GROUP = "group";
-
 /* required credentials */
 public static final String CRED_CERT = IAuthManager.CRED_SSL_CLIENT_CERT;
 protected String[] mRequiredCreds = { CRED_CERT };
@@ -225,11 +218,11 @@ public class AgentCertAuthentication implements 
IAuthManager,
 throw new 
EInvalidCredentials(CMS.getUserMessage("CMS_AUTHORIZATION_ERROR"));
 }
 }
-authToken.set(TOKEN_USERDN, user.getUserDN());
-authToken.set(TOKEN_USER_DN, user.getUserDN());
-authToken.set(TOKEN_USERID, user.getUserID());
-authToken.set(TOKEN_UID, user.getUserID());
-authToken.set(TOKEN_GROUP, groupname);
+authToken.set(IAuthToken.USER, user.getUserDN());
+authToken.set(IAuthToken.USER_DN, user.getUserDN());
+authToken.set(IAuthToken.USER_ID, user.getUserID());
+authToken.set(IAuthToken.UID, user.getUserID());
+authToken.set(IAuthToken.GROUP, groupname);
 authToken.set(CRED_CERT, certs);
 
 CMS.debug("AgentCertAuthentication: authenticated " + 
user.getUserDN());
-- 
2.9.3

From 04df8149e4caea2ace84e81b5b166be637f0b00d Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 7 Feb 2017 11:47:54 +1000
Subject: [PATCH 158/158] CertProcessor: extract method setAuthTokenIntoRequest

The "set auth token into request" logic is extensive and warrants
extraction.  It also has a separate concern mixed in with it: the
self-assignment of the request if the authenticated user is a
"Registration Manager Agent".

Separate these concerns and extract the setAuthTokenIntoRequest
method.

Part of: https://fedorahosted.org/pki/ticket/1359
---
 .../netscape/cms/servlet/cert/CertProcessor.java   | 68 +++---
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git 
a/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java 
b/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
index 
026f4d4af5c2316ae8a93b2ecc62bc398d3b8b71..47b522208af05486a22abdd6196d8385dd615857
 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
@@ -116,6 +116,30 @@ public class CertProcessor e

[Pki-devel] [PATCH] 0156 Remove unused dependency from tomcat classes build

[Fraser Tweedale]

Pushed under one-liner/trivial rule.

Thanks,
Fraser
From 463be6afd824f39c9e02881d7b9b168cd92093a1 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 7 Feb 2017 10:31:32 +1000
Subject: [PATCH 156/158] Remove unused dependency from tomcat classes build

---
 base/server/tomcat/src/CMakeLists.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/base/server/tomcat/src/CMakeLists.txt 
b/base/server/tomcat/src/CMakeLists.txt
index 
21d1c63311a7d2a6d0ad0b0f977ecdd6f45484b7..087bcd9acd7f0be8de274c9716466e3920bc3f52
 100644
--- a/base/server/tomcat/src/CMakeLists.txt
+++ b/base/server/tomcat/src/CMakeLists.txt
@@ -114,5 +114,4 @@ javac(pki-tomcat-classes
 OUTPUT_DIR
 ${CMAKE_BINARY_DIR}/../../tomcat
 DEPENDS
-pki-tools-jar
 )
-- 
2.9.3

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0151..0155 Add profile component that copies CN to SAN

[Fraser Tweedale]

Discussion for devs: once this is merged should I updated all the
included service-oriented profiles (e.g. caCAcert; not user or CA
cert profiles) to add this profile component?

IMO we should do it, but we should not automatically update existing
installations.  Instead, we (I) can produce a KBase article about
using the new component.

Let me know what you think.

Cheers,
Fraser

On Thu, Feb 02, 2017 at 12:46:30PM -0700, Matthew Harmsen wrote:
> On 02/01/2017 12:25 AM, Fraser Tweedale wrote:
> > Hi all,
> > 
> > The attached patches implement the long-desired feature to copy CN
> > to SubjectAltName (https://fedorahosted.org/pki/ticket/1710).
> > 
> > I've also pushed the branch to my GitHub repo; feel free to review
> > the patches there:
> > https://github.com/frasertweedale/pki/commits/feature/1710-cn-to-san
> > 
> > Thanks,
> > Fraser
> > 
> > 
> > ___
> > Pki-devel mailing list
> > Pki-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> Fraser,
> 
> In order to review this patch, I am going to apply it and make a scratch
> build of Dogtag 10.2.6 on RHEL 7.2 so that Red Hat IT can test it out for
> us.
> 
> If they give us their approval, you can consider yourself granted an ACK on
> this patch and check it into master so that I can cherry-pick it into the
> 10.3 branches.
> 
> -- Matt
> 
> P. S. - FYI, the following conversation took place on #cs today:
> 
> dminnich,walrus: ftweedal has released a patch for
>https://fedorahosted.org/pki/ticket/1710 - Add profile component
>that copies CN to SAN -- if I applied that patch to a 10.3.3
>pki-core for RHEL 7.3, could you guys test it out, or in order to
>test it out, do you need a scratch build of Dogtag 10.2.6 on RHEL
>7.2 like last time?
> mharmsen: having a scratch build of 7.2 would be quickest
> we are just now planning the 7.3 upgrade, which will take
>some time to get into dev
> walrus: okay, I can try to see if I can do that, but
>remember that we will not deliver an official RHEL 7.2 build of RHCS 9.1
> yeah we should be on 7.3 in a month or so... a lot of
>things to test on a lot of servers :)
> csnell|wfh: ^^^
> walrus: completely understood! LOL
> mharmsen: that will be a very welcome patch
> mharmsen: do you happen to know if ACLs work against SANs?
> dminnich: not off the top of my head
> edewata, cfu, jmagne: ^^^?
> that is something on our to investigate list as well
> dminnich: I am going to drop an email to ftweedal, and I
>will ask that question
> mharmsen: no idea about SAN
> mharmsen, don't know
> dminnich, mharmsen , what does that mean?
> cfu: right now we allow only people in LDAP group X to
>issue certs for domains that meet Y regex.  but we don't check
>SANs.  so somebody could CN=blah.devlab.com and get approved but add
>a SAN for www.redhat.com and we don't deny it
> dminnich: where is X & Y defined?
>
>
> https://gitolite.corp.redhat.com/cgit/puppet-cfg/modules/rhcs.git/tree/templates/ca/profiles/ca/caDirServerCert-pnt-devops-domains.cfg#n12
>
> https://gitolite.corp.redhat.com/cgit/puppet-cfg/modules/rhcs.git/tree/templates/ca/profiles/ca/caDirServerCert-pnt-devops-domains.cfg#n26
> edewata: ^ some of that might be added by puppet later.but
> thats the gist
> dminnich: ok, it's in profile, not ACL
> authz.acl=group  and constraints
> dminnich, dminnich ah, I see. so it's like a pattern
>constraint just like what we have for subject name now in the
>profile.  Yeah, you can write a constraint plugin for that
> dminnich, anyway, feel free to file a ticket for it.
> cfu: will do
> 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0151..0155 Add profile component that copies CN to SAN

[Fraser Tweedale]

Hi all,

The attached patches implement the long-desired feature to copy CN
to SubjectAltName (https://fedorahosted.org/pki/ticket/1710).

I've also pushed the branch to my GitHub repo; feel free to review
the patches there:
https://github.com/frasertweedale/pki/commits/feature/1710-cn-to-san

Thanks,
Fraser
From 3f913b1857712dd0a962d42f56f29d7faebf244e Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 1 Feb 2017 16:15:39 +1000
Subject: [PATCH 151/155] DNSName: add method to get value

To implement a profile default that copies CN to SAN dNSName, we
need to examine existing dNSName values.  To support this, add the
'getValue()' method to 'DNSName'.

Part of: https://fedorahosted.org/pki/ticket/1710
---
 base/util/src/netscape/security/x509/DNSName.java | 8 
 1 file changed, 8 insertions(+)

diff --git a/base/util/src/netscape/security/x509/DNSName.java 
b/base/util/src/netscape/security/x509/DNSName.java
index 
361c23571f423f635e2026c64c7bcf902f5ff3be..2161adf3701a554040ca4afc5b0c39337ed8452a
 100644
--- a/base/util/src/netscape/security/x509/DNSName.java
+++ b/base/util/src/netscape/security/x509/DNSName.java
@@ -79,4 +79,12 @@ public class DNSName implements GeneralNameInterface {
 public String toString() {
 return ("DNSName: " + name);
 }
+
+/**
+ * Get the raw DNSName value.
+ */
+public String getValue() {
+return name;
+}
+
 }
-- 
2.9.3

From aaa8d03d36f31894fed3c8d9c7b5126ac5417774 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 1 Feb 2017 16:17:51 +1000
Subject: [PATCH 152/155] GeneralName: add method to get at inner value

The 'GeneralNameInterface' interface represents a single X.509
General Name value.  Various types are supported.  The 'GeneralName'
class (which also implements 'GeneralNameInterface') is a singleton
container for another 'GeneralNameInterface' value.

To implement a profile component that copies CN to a SAN dNSName, we
need to examine existing General Names in the SAN extension (if
present), to avoid duplicate values.  We can iterate 'GeneralNames',
but if the value is of type 'GeneralName' we need a way to "unwrap"
the value, down to the innermost value which will be of a specific
General Name type.

Add the 'unwrap' method to 'GeneralName'.

Part of: https://fedorahosted.org/pki/ticket/1710
---
 base/util/src/netscape/security/x509/GeneralName.java | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/base/util/src/netscape/security/x509/GeneralName.java 
b/base/util/src/netscape/security/x509/GeneralName.java
index 
a90ac7bf259b519c91bb2f67cf159f7b4178b182..55b5bfcf304c0c8ccf893f9a6ef70d2e5c2ee0e2
 100644
--- a/base/util/src/netscape/security/x509/GeneralName.java
+++ b/base/util/src/netscape/security/x509/GeneralName.java
@@ -196,4 +196,19 @@ public class GeneralName implements GeneralNameInterface {
  constructedForm, (byte) nameType), tmp);
 }
 }
+
+/**
+ * Unwrap this GeneralName until we reach something that is not
+ * a GeneralName.
+ */
+public GeneralNameInterface unwrap() {
+if (this == name)
+return null;  // can't happen, but just in case...
+
+if (name instanceof GeneralName)
+return ((GeneralName) name).unwrap();
+else
+return name;
+}
+
 }
-- 
2.9.3

From 805b2e2d753f86c39af225d13c7614974e10c154 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 1 Feb 2017 16:25:11 +1000
Subject: [PATCH 153/155] SubjectAlternativeNameExtension: add GeneralNames
 getter/setter

To implement a profile default that copies CN to SAN dNSName, we
need to read and set the 'GeneralNames' of the extension.  This can
be done via the 'get' and 'set' methods but this interface is
awkward and requires the caller to deal with exceptions that aren't
fundamental to the get/set actions.

Add the 'setGeneralNames' and 'getGeneralNames' methods.

Part of: https://fedorahosted.org/pki/ticket/1710
---
 .../security/x509/SubjectAlternativeNameExtension.java| 15 +++
 1 file changed, 15 insertions(+)

diff --git 
a/base/util/src/netscape/security/x509/SubjectAlternativeNameExtension.java 
b/base/util/src/netscape/security/x509/SubjectAlternativeNameExtension.java
index 
d96c821604308c11723644e8842e1dcc6f224034..82f87e1ef647496353f598a33290d6dcfb5e8f04
 100644
--- a/base/util/src/netscape/security/x509/SubjectAlternativeNameExtension.java
+++ b/base/util/src/netscape/security/x509/SubjectAlternativeNameExtension.java
@@ -199,6 +199,21 @@ public class SubjectAlternativeNameExtension extends 
Extension
 }
 
 /**
+ * Set the GeneralNames of this extension.
+ */
+public void setGeneralNames(GeneralNames names) {
+clearValue();
+this.names = names;
+}
+
+/**
+ * Get the GeneralNames of this extension.
+ */
+ 

[Pki-devel] [PATCH] 0149 Use BigInteger for entryUSN

[Fraser Tweedale]

The attached patch fixes https://fedorahosted.org/pki/ticket/2579.

Thanks,
Fraser
From 4201b2c02546e4d404816a4932ba2d0d688f2c55 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 23 Jan 2017 17:11:26 +1000
Subject: [PATCH] Use BigInteger for entryUSN

Currently we try to parse the entryUSN into an Integer, which wraps
the 'int' primitive type.  If entryUSN value is too large to fit in
'int', NumberFormatException is raised.

Change LDAPProfileSubsystem and CertificateAuthority to use
BigInteger for entryUSN values.

Fixes: https://fedorahosted.org/pki/ticket/2579
---
 base/ca/src/com/netscape/ca/CertificateAuthority.java   | 12 ++--
 .../com/netscape/cmscore/profile/LDAPProfileSubsystem.java  | 13 +++--
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java 
b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 
92bf64412c0edcf5540830438e6c356dbb4811bc..7ad40a9f6e436d4d3c4c947165a2c7ae18dc960a
 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -334,7 +334,7 @@ public class CertificateAuthority
 
 /* Maps and sets of entryUSNs and nsUniqueIds for avoiding race
  * conditions and unnecessary reloads related to replication */
-private static TreeMap<AuthorityID,Integer> entryUSNs = new TreeMap<>();
+private static TreeMap<AuthorityID,BigInteger> entryUSNs = new TreeMap<>();
 private static TreeMap<AuthorityID,String> nsUniqueIds = new TreeMap<>();
 private static TreeSet deletedNsUniqueIds = new TreeSet<>();
 
@@ -2902,7 +2902,7 @@ public class CertificateAuthority
 
 LDAPAttribute attr = entry.getAttribute("entryUSN");
 if (attr != null) {
-Integer entryUSN = new Integer(attr.getStringValueArray()[0]);
+BigInteger entryUSN = new 
BigInteger(attr.getStringValueArray()[0]);
 entryUSNs.put(aid, entryUSN);
 CMS.debug("postCommit: new entryUSN = " + entryUSN);
 }
@@ -3268,7 +3268,7 @@ public class CertificateAuthority
 return;
 }
 
-Integer newEntryUSN = null;
+BigInteger newEntryUSN = null;
 LDAPAttribute entryUSNAttr = entry.getAttribute("entryUSN");
 if (entryUSNAttr == null) {
 CMS.debug("readAuthority: no entryUSN");
@@ -3285,14 +3285,14 @@ public class CertificateAuthority
 // entryUSN attribute being added.
 }
 } else {
-newEntryUSN = new Integer(entryUSNAttr.getStringValueArray()[0]);
+newEntryUSN = new 
BigInteger(entryUSNAttr.getStringValueArray()[0]);
 CMS.debug("readAuthority: new entryUSN = " + newEntryUSN);
 }
 
-Integer knownEntryUSN = entryUSNs.get(aid);
+BigInteger knownEntryUSN = entryUSNs.get(aid);
 if (newEntryUSN != null && knownEntryUSN != null) {
 CMS.debug("readAuthority: known entryUSN = " + knownEntryUSN);
-if (newEntryUSN <= knownEntryUSN) {
+if (newEntryUSN.compareTo(knownEntryUSN) <= 0) {
 CMS.debug("readAuthority: data is current");
 return;
 }
diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
 
b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
index 
213c7a9f19f93ded4c42b6c06768a893a1257f71..fff8ead3f2088aedaf5856c308dd33be90af7779
 100644
--- 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
+++ 
b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
@@ -19,6 +19,7 @@ package com.netscape.cmscore.profile;
 
 import java.io.ByteArrayInputStream;
 import java.io.InputStream;
+import java.math.BigInteger;
 import java.util.Arrays;
 import java.util.Enumeration;
 import java.util.Hashtable;
@@ -65,7 +66,7 @@ public class LDAPProfileSubsystem
 
 /* Map of profileId -> entryUSN for the most recent view
  * of the profile entry that this instance has seen */
-private TreeMap<String,Integer> entryUSNs;
+private TreeMap<String,BigInteger> entryUSNs;
 
 private TreeMap<String,String> nsUniqueIds;
 
@@ -168,14 +169,14 @@ public class LDAPProfileSubsystem
 }
 profileId = LDAPDN.explodeDN(dn, true)[0];
 
-Integer newEntryUSN = new Integer(
+BigInteger newEntryUSN = new BigInteger(
 ldapProfile.getAttribute("entryUSN").getStringValueArray()[0]);
 CMS.debug("readProfile: new entryUSN = " + newEntryUSN);
 
-Integer knownEntryUSN = entryUSNs.get(profileId);
+BigInteger knownEntryUSN = entryUSNs.get(profileId);
 if (knownEntryUSN != null) {

[Pki-devel] [PATCH] 0148 Remove principal type assumption from AuthorityService

[Fraser Tweedale]

Reviewed by alee:
https://github.com/frasertweedale/pki/commit/967727ea3104accbf1bd1e05fc676bfef0d9ba6d

Pushed to master (1d706a075f32d7c30a6259be675b8f34ef2a9c99).

Thanks,
Fraser
From 1d706a075f32d7c30a6259be675b8f34ef2a9c99 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 30 Nov 2016 10:06:15 +1000
Subject: [PATCH] Remove principal type assumption from AuthorityService

Part of: https://fedorahosted.org/pki/ticket/1359
---
 .../src/org/dogtagpki/server/ca/rest/AuthorityService.java   | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java 
b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
index 
584ab6e59638beada6c89a1882a176b4743a861d..18542d3794f2f1ba3975c634ee726f6d94ebba5b
 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
@@ -36,6 +36,7 @@ import javax.ws.rs.core.Response;
 import javax.ws.rs.core.UriInfo;
 
 import com.netscape.certsrv.apps.CMS;
+import com.netscape.certsrv.authentication.IAuthToken;
 import com.netscape.certsrv.authority.AuthorityData;
 import com.netscape.certsrv.authority.AuthorityResource;
 import com.netscape.certsrv.base.BadRequestDataException;
@@ -46,6 +47,7 @@ import com.netscape.certsrv.base.ForbiddenException;
 import com.netscape.certsrv.base.PKIException;
 import com.netscape.certsrv.base.ResourceNotFoundException;
 import com.netscape.certsrv.base.ServiceUnavailableException;
+import com.netscape.certsrv.base.SessionContext;
 import com.netscape.certsrv.ca.AuthorityID;
 import com.netscape.certsrv.ca.CADisabledException;
 import com.netscape.certsrv.ca.CAEnabledException;
@@ -59,7 +61,6 @@ import com.netscape.certsrv.ca.IssuerUnavailableException;
 import com.netscape.certsrv.common.OpDef;
 import com.netscape.certsrv.common.ScopeDef;
 import com.netscape.certsrv.logging.ILogger;
-import com.netscape.cms.realm.PKIPrincipal;
 import com.netscape.cms.servlet.base.PKIService;
 import com.netscape.cmsutil.util.Utils;
 
@@ -191,9 +192,6 @@ public class AuthorityService extends PKIService implements 
AuthorityResource {
 }
 }
 
-PKIPrincipal principal =
-(PKIPrincipal) servletRequest.getUserPrincipal();
-
 Map<String, String> auditParams = new LinkedHashMap<>();
 auditParams.put("dn", data.getDN());
 if (parentAID != null)
@@ -201,10 +199,12 @@ public class AuthorityService extends PKIService 
implements AuthorityResource {
 if (data.getDescription() != null)
 auditParams.put("description", data.getDescription());
 
+IAuthToken authToken = (IAuthToken)
+SessionContext.getContext().get(SessionContext.AUTH_TOKEN);
+
 try {
 ICertificateAuthority subCA = hostCA.createCA(
-principal.getAuthToken(),
-data.getDN(), parentAID, data.getDescription());
+authToken, data.getDN(), parentAID, data.getDescription());
 audit(ILogger.SUCCESS, OpDef.OP_ADD,
 subCA.getAuthorityID().toString(), auditParams);
 return createOKResponse(readAuthorityData(subCA));
-- 
2.7.4

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0144..0146 Move IRequest extdata-related constants

[Fraser Tweedale]

Acked by alee:

- 
https://github.com/frasertweedale/pki/commit/9826013dfcab72481f3ad6462e1d2c4692367a02
- 
https://github.com/frasertweedale/pki/commit/59071b422637e6e99dd956eed12c5c26e19c3ffc
- 
https://github.com/frasertweedale/pki/commit/7f1f4a2504280a5b8504b4db5df40eac122c280f

Pushed to master:

- 9c23b02b00b13a834b636e9266ee1ae80506f228 Define "req_authority_id" IRequest 
extdata key in IRequest
- a1b56be53d37561c6e80c2aa7daf1e7ab07518c5 Define "profileId" IRequest extdata 
key in one place
- d699d27c7d7a59cf613380ec2214333ecc96ec23 Define "auth_token" IRequest extdata 
key prefix in one place

Thanks,
Fraser

On Wed, Dec 07, 2016 at 02:39:22PM +1000, Fraser Tweedale wrote:
> The attached patches relocate / redefine some constants that are
> used as keys when setting or getting IRequest extdata attributes.
> 
> In some cases this removes duplicate constants or string literals.
> In other cases it actually defines a new constant.
> In all cases the key now uses a constant defined in IRequest, which
> is the appropriate place.
> 
> This is refactoring work undertaken as part of GSSAPI support.
> 
> Thanks,
> Fraser

> From 31d9026f2be5204dd4742ce00542bc80b614d9b9 Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Wed, 7 Dec 2016 12:25:01 +1000
> Subject: [PATCH 144/146] Define "auth_token" IRequest extdata key prefix in
>  one place
> 
> Part of: https://fedorahosted.org/pki/ticket/1359
> ---
>  base/common/src/com/netscape/certsrv/request/IRequest.java   |  4 
>  .../cms/src/com/netscape/cms/servlet/cert/CertProcessor.java |  9 +++--
>  .../src/com/netscape/cms/servlet/processors/CAProcessor.java |  1 -
>  .../cms/servlet/profile/ProfileSubmitCMCServlet.java | 12 
> +++-
>  4 files changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/base/common/src/com/netscape/certsrv/request/IRequest.java 
> b/base/common/src/com/netscape/certsrv/request/IRequest.java
> index 
> c892dbb1dc5d75d4b44e4e26b584f94717b2457c..f17f560de75e54cb7650ee06d870f3d1491e52ac
>  100644
> --- a/base/common/src/com/netscape/certsrv/request/IRequest.java
> +++ b/base/common/src/com/netscape/certsrv/request/IRequest.java
> @@ -85,6 +85,10 @@ public interface IRequest extends Serializable {
>  // server attributes: attributes generated by server modules.
>  public static final String SERVER_ATTRS = "SERVER_ATTRS";
>  
> +// Sometimes individual IAuthToken fields get set in request
> +// extdata, with key ("auth_token." + field_name).
> +public static final String AUTH_TOKEN_PREFIX = "auth_token";
> +
>  public static final String RESULT = "Result"; // service result.
>  public static final Integer RES_SUCCESS = Integer.valueOf(1); // result 
> value
>  public static final Integer RES_ERROR = Integer.valueOf(2); // result 
> value
> diff --git 
> a/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java 
> b/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
> index 
> 17b453ab5d82bd7c18612263f01e297a4e9df3da..cb5efa0b0e14274e0c4a9393522ab18071f60fd8
>  100644
> --- a/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
> +++ b/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
> @@ -310,12 +310,17 @@ public class CertProcessor extends CAProcessor {
>  String[] tokenVals = 
> authToken.getInStringArray(tokenName);
>  if (tokenVals != null) {
>  for (int i = 0; i < tokenVals.length; i++) {
> -req.setExtData(ARG_AUTH_TOKEN + "." + tokenName 
> + "[" + i + "]", tokenVals[i]);
> +req.setExtData(
> +IRequest.AUTH_TOKEN_PREFIX
> ++ "." + tokenName + "[" + i + "]"
> +, tokenVals[i]);
>  }
>  } else {
>  String tokenVal = authToken.getInString(tokenName);
>  if (tokenVal != null) {
> -req.setExtData(ARG_AUTH_TOKEN + "." + tokenName, 
> tokenVal);
> +req.setExtData(
> +IRequest.AUTH_TOKEN_PREFIX + "." + tokenName,
> +tokenVal);
>  // if RA agent, auto assign the request
>  if (tokenName.equals("uid"))
>  uid = tokenVal;
> diff --git 
> a/base/server/cms/src/com/

Re: [Pki-devel] [PATCH] 0141 Add getAuthzManagerNameByRealm to IAuthzSubsystem

[Fraser Tweedale]

Acked by alee:
https://github.com/frasertweedale/pki/commit/4a43f08a96f80a44ad0d8fffcb49f70b5d274277

Pushed to master (e2e4b70bab9c81b9007057cafd25447190d6cde4).

Thanks,
Fraser

On Tue, Nov 29, 2016 at 07:12:28PM +1000, Fraser Tweedale wrote:
> This patch renames (a better name) and moves to the IAuthzSubsystem
> interface a method in AuthzSubsystem that may be useful for doing
> authorisation checks for external principals.
> 
> Thanks,
> Fraser

> From 6a1ddf4cf79e40ff0a0702e063afa6e6237f0fb6 Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Fri, 25 Nov 2016 21:08:56 +1000
> Subject: [PATCH 141/141] Add getAuthzManagerNameByRealm to IAuthzSubsystem
> 
> The getAuthzManagerByRealm public method is defined in
> AuthzSubsystem but to support external principals we want to make
> this part of the IAuthzSubsystem interface, so other classes (e.g.
> ACLInterceptor) can use it.
> 
> Part of: https://fedorahosted.org/pki/ticket/1359
> ---
>  .../netscape/certsrv/authorization/IAuthzSubsystem.java  |  9 +
>  .../netscape/cmscore/authorization/AuthzSubsystem.java   | 16 
> +---
>  2 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git 
> a/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java 
> b/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java
> index 
> c7d8df56bbfb1bf8af6c51ce491fc1384560b4a8..6fcf8e7b03eb596bb7914912474eeb3c298b6da1
>  100644
> --- a/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java
> +++ b/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java
> @@ -21,6 +21,7 @@ import java.util.Enumeration;
>  import java.util.Hashtable;
>  
>  import com.netscape.certsrv.authentication.IAuthToken;
> +import com.netscape.certsrv.authorization.EAuthzUnknownRealm;
>  import com.netscape.certsrv.base.EBaseException;
>  import com.netscape.certsrv.base.ISubsystem;
>  
> @@ -181,4 +182,12 @@ public interface IAuthzSubsystem extends ISubsystem {
>   * @return an authorization manager interface
>   */
>  public IAuthzManager get(String name);
> +
> +/**
> + * Given a realm name, return the name of an authz manager for that 
> realm.
> + *
> + * @throws EAuthzUnknownRealm if no authz manager is found.
> + */
> +public String getAuthzManagerNameByRealm(String realm)
> +throws EAuthzUnknownRealm;
>  }
> diff --git 
> a/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
>  
> b/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
> index 
> 31d5e71b4bdd672fa3eae3108824480d87eafdf3..67d12bdff2e716bcea4034726d189a23c6f50796
>  100644
> --- 
> a/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
> +++ 
> b/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
> @@ -495,10 +495,7 @@ public class AuthzSubsystem implements IAuthzSubsystem {
>  // if record owner == requester, SUCCESS
>  if ((owner != null) && 
> owner.equals(authToken.getInString(IAuthToken.USER_ID))) return;
>  
> -String mgrName = getAuthzManagerByRealm(realm);
> -if (mgrName == null) {
> -throw new EAuthzUnknownRealm("Realm not found");
> -}
> +String mgrName = getAuthzManagerNameByRealm(realm);
>  
>  AuthzToken authzToken = authorize(mgrName, authToken, resource, 
> operation, realm);
>  if (authzToken == null) {
> @@ -506,12 +503,17 @@ public class AuthzSubsystem implements IAuthzSubsystem {
>  }
>  }
>  
> -public String getAuthzManagerByRealm(String realm) throws EBaseException 
> {
> +public String getAuthzManagerNameByRealm(String realm) throws 
> EAuthzUnknownRealm {
>  for (AuthzManagerProxy proxy : mAuthzMgrInsts.values()) {
>  IAuthzManager mgr = proxy.getAuthzManager();
>  if (mgr != null) {
>  IConfigStore cfg = mgr.getConfigStore();
> -String mgrRealmString = cfg.getString(PROP_REALM, null);
> +String mgrRealmString = null;
> +try {
> +mgrRealmString = cfg.getString(PROP_REALM, null);
> +} catch (EBaseException e) {
> +// never mind
> +}
>  if (mgrRealmString == null) continue;
>  
>  List mgrRealms = 
> Arrays.asList(mgrRealmString.split(","));
> @@ -521,7 +523,7 @@ public class AuthzSubsystem implements IAuthzSubsystem {
>  }
>  }
>  }
> -return null;
> +thr

Re: [Pki-devel] [PATCH] 0140 Allow ':' to appear in ACL expressions

[Fraser Tweedale]

Acked by alee:
https://github.com/frasertweedale/pki/commit/037c16e3e78bccfa16e3d50ef840675ad2e0f3ec

Pushed to master (7ab1bbb708d539d4db4e494418fedb952e4880bc)

Thanks,
Fraser

On Tue, Nov 29, 2016 at 07:08:48PM +1000, Fraser Tweedale wrote:
> With current ACL parsing, if you have a ':' in a group name (as
> occurs with FreeIPA permissions, which matter for upcoming external
> principal support) you are stuffed.  This commit fixes that.
> 
> It is really a band aid - the existing parsing code is poor and
> should be replaced with a nice combinatorial parser... but who has
> the time for that right now? ¯\_(ツ)_/¯
> 
> Note that if there is a ':' in any of the ACL descriptions/comments
> (the final field) this change breaks it.  We don't have any
> occurrences of that in our codebase.
> 
> Thanks,
> Fraser

> From 4e13cd0c960558b0f590c5f74ef0b52f0eb667f2 Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Fri, 25 Nov 2016 18:04:22 +1000
> Subject: [PATCH 140/141] Allow ':' to appear in ACL expressions
> 
> Currently if ':' appears in an ACL expression (e.g. a group name, as
> occurs in FreeIPA permissions), the ACL gets parsed incorrectly.
> 
> Look backwards from end of string for the final ':', so that the ACL
> parses correctly.
> 
> Part of: https://fedorahosted.org/pki/ticket/1359
> ---
>  base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java 
> b/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java
> index 
> e37ba25e0446108e266a1b068a7ba2a6e60fb769..9b87f6e2437a398ffd6c4956a8e91809918ab8b9
>  100644
> --- a/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java
> +++ b/base/server/cmscore/src/com/netscape/cmscore/apps/CMSEngine.java
> @@ -681,8 +681,10 @@ public class CMSEngine implements ICMSEngine {
>  
>  acl = new ACL(resource, rights, resACLs);
>  
> +// search *backwards* for final instance of ':', to handle case
> +// where acl expressions contain colon, e.g. in a group name.
>  String stx = st.substring(idx2 + 1);
> -int idx3 = stx.indexOf(":");
> +int idx3 = stx.lastIndexOf(":");
>  String aclStr = stx.substring(0, idx3);
>  
>  // getting list of acl entries
> -- 
> 2.7.4
> 

> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0139 Merge duplicate authz plugin code into superclass

[Fraser Tweedale]

Acked by alee:
https://github.com/frasertweedale/pki/commit/2d6e917470fce977d2537eba0b9ef2ee17fd0a41

Pushed to master (bfcf597d569e24fe6ec60062e37908c62bcff76)

On Tue, Nov 29, 2016 at 07:04:26PM +1000, Fraser Tweedale wrote:
> The attached patch merges some duplicate authz manager code into the
> existing AAclAuthz superclass.
> 
> It simplifies things if we end up adding a new authz manager as part
> of external authentication / GSS-API support.  But it's a nice
> refactor to do anyway :)
> 
> Thanks,
> Fraser

> From afc5fc3da5f1ea61305fb237e002bbe8b3d26e8c Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Fri, 25 Nov 2016 14:29:40 +1000
> Subject: [PATCH 139/141] Merge duplicate authz plugin code into superclass
> 
> DirAclAuthz and BasicAclAuthz both extend AAclAuthz, but there is
> still a lot of duplicate code.  Push the duplicated bits up into the
> AAclAuthz.
> 
> Also remove abstract method flushResourceACLs() from AAclAuthz, and
> its implementation from BasicAclAuthz, because it is only
> implemented (meaningfully) by DirAclAuthz.
> 
> Part of: https://fedorahosted.org/pki/ticket/1359
> ---
>  .../com/netscape/cms/authorization/AAclAuthz.java  |  93 ++---
>  .../netscape/cms/authorization/BasicAclAuthz.java  | 144 
> +
>  .../netscape/cms/authorization/DirAclAuthz.java| 105 +--
>  3 files changed, 78 insertions(+), 264 deletions(-)
> 
> diff --git 
> a/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java 
> b/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java
> index 
> b3e447cfca49951fe78f6b4896652921ffc43406..f95c98174a06dba9ebf3e43238e566be2e6b5594
>  100644
> --- a/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java
> +++ b/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java
> @@ -30,6 +30,9 @@ import com.netscape.certsrv.acls.IACL;
>  import com.netscape.certsrv.apps.CMS;
>  import com.netscape.certsrv.authentication.IAuthToken;
>  import com.netscape.certsrv.authorization.AuthzToken;
> +import com.netscape.certsrv.authorization.EAuthzAccessDenied;
> +import com.netscape.certsrv.authorization.EAuthzInternalError;
> +import com.netscape.certsrv.authorization.IAuthzManager;
>  import com.netscape.certsrv.base.EBaseException;
>  import com.netscape.certsrv.base.IConfigStore;
>  import com.netscape.certsrv.evaluators.IAccessEvaluator;
> @@ -61,7 +64,7 @@ import com.netscape.cmsutil.util.Utils;
>   * @version $Revision$, $Date$
>   * @see  HREF="http://developer.netscape.com/library/documentation/enterprise/admnunix/aclfiles.htm;>ACL
>  Files
>   */
> -public abstract class AAclAuthz {
> +public abstract class AAclAuthz implements IAuthzManager {
>  
>  protected static final String PROP_CLASS = "class";
>  protected static final String PROP_IMPL = "impl";
> @@ -69,6 +72,12 @@ public abstract class AAclAuthz {
>  
>  protected static final String ACLS_ATTR = "aclResources";
>  
> +/* name of this authorization manager instance */
> +private String mName = null;
> +
> +/* name of the authorization manager plugin */
> +private String mImplName = null;
> +
>  private IConfigStore mConfig = null;
>  
>  private Hashtable<String, ACL> mACLs = new Hashtable<String, ACL>();
> @@ -93,14 +102,14 @@ public abstract class AAclAuthz {
>  /**
>   * Initializes
>   */
> -protected void init(IConfigStore config)
> +public void init(String name, String implName, IConfigStore config)
>  throws EBaseException {
> -
> +mName = name;
> +mImplName = implName;
> +mConfig = config;
>  mLogger = CMS.getLogger();
>  CMS.debug("AAclAuthz: init begins");
>  
> -mConfig = config;
> -
>  // load access evaluators specified in the config file
>  IConfigStore mainConfig = CMS.getConfigStore();
>  IConfigStore evalConfig = mainConfig.getSubStore(PROP_EVAL);
> @@ -144,6 +153,20 @@ public abstract class AAclAuthz {
>  }
>  
>  /**
> + * gets the name of this authorization manager instance
> + */
> +public String getName() {
> +return mName;
> +}
> +
> +/**
> + * gets the plugin name of this authorization manager.
> + */
> +public String getImplName() {
> +return mImplName;
> +}
> +
> +/**
>   * Parse ACL resource attributes, then update the ACLs memory store
>   * This is intended to be used if storing ACLs on ldap is not desired,
>   * and the caller is expected to

Re: [Pki-devel] [PATCH] 0138 Move AuthToken key constants to IAuthToken

[Fraser Tweedale]

Acked by alee:
https://github.com/frasertweedale/pki/commit/b775ca19b2c1a3d554aca3134308a71fecd7bdd0

Pushed to master (1407b5f3af27d05970bb42ac2fefe51cb6b01abd)

Thanks,
Fraser

On Tue, Nov 29, 2016 at 07:02:12PM +1000, Fraser Tweedale wrote:
> The attached patch moves some string constants from AuthToken to
> IAuthToken.  External authentication support will bring a new
> implementation of IAuthToken so moving these to the interface
> simplifies things.
> 
> Thanks,
> Fraser

> From 8118f83cc7691e48c63111a050540c9180fd29e5 Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Tue, 29 Nov 2016 16:10:58 +1000
> Subject: [PATCH 138/141] Move AuthToken key constants to IAuthToken
> 
> Part of: https://fedorahosted.org/pki/ticket/1359
> ---
>  .../netscape/certsrv/authentication/AuthToken.java | 34 
> --
>  .../certsrv/authentication/IAuthToken.java | 34 
> ++
>  2 files changed, 34 insertions(+), 34 deletions(-)
> 
> diff --git 
> a/base/common/src/com/netscape/certsrv/authentication/AuthToken.java 
> b/base/common/src/com/netscape/certsrv/authentication/AuthToken.java
> index 
> 0febf87727d2ebde9dbcacbd5059f9b9afa13701..53959b131f2d9a99e6b9b65640f8546e84468c66
>  100644
> --- a/base/common/src/com/netscape/certsrv/authentication/AuthToken.java
> +++ b/base/common/src/com/netscape/certsrv/authentication/AuthToken.java
> @@ -51,40 +51,6 @@ import com.netscape.certsrv.usrgrp.Certificates;
>  public class AuthToken implements IAuthToken {
>  protected Hashtable<String, Object> mAttrs = null;
>  
> -/* Subject name of the certificate in the authenticating entry */
> -public static final String TOKEN_CERT_SUBJECT = "tokenCertSubject";
> -
> -/* NotBefore value of the certificate in the authenticating entry */
> -public static final String TOKEN_CERT_NOTBEFORE = "tokenCertNotBefore";
> -
> -/* NotAfter value of the certificate in the authenticating entry */
> -public static final String TOKEN_CERT_NOTAFTER = "tokenCertNotAfter";
> -
> -/* Cert Extentions value of the certificate in the authenticating entry 
> */
> -public static final String TOKEN_CERT_EXTENSIONS = "tokenCertExts";
> -
> -/* Serial number of the certificate in the authenticating entry */
> -public static final String TOKEN_CERT_SERIALNUM = "certSerial";
> -
> -/**
> - * Certificate to be renewed
> - */
> -public static final String TOKEN_CERT = "tokenCert";
> -
> -/* Certificate to be revoked */
> -public static final String TOKEN_CERT_TO_REVOKE = "tokenCertToRevoke";
> -
> -/**
> - * Name of the authentication manager that created the AuthToken
> - * as a string.
> - */
> -public static final String TOKEN_AUTHMGR_INST_NAME = "authMgrInstName";
> -
> -/**
> - * Time of authentication as a java.util.Date
> - */
> -public static final String TOKEN_AUTHTIME = "authTime";
> -
>  /**
>   * Constructs an instance of a authentication token.
>   * The token by default contains the following attributes: 
> diff --git 
> a/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java 
> b/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
> index 
> a71432446edcf6b5d838f1115df16b26acd01dce..a3f240e9c35987462eb2f176de650a769df1005c
>  100644
> --- a/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
> +++ b/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
> @@ -41,6 +41,40 @@ public interface IAuthToken {
>  public static final String UID = "uid";
>  public static final String GROUPS = "groups";
>  
> +/* Subject name of the certificate in the authenticating entry */
> +public static final String TOKEN_CERT_SUBJECT = "tokenCertSubject";
> +
> +/* NotBefore value of the certificate in the authenticating entry */
> +public static final String TOKEN_CERT_NOTBEFORE = "tokenCertNotBefore";
> +
> +/* NotAfter value of the certificate in the authenticating entry */
> +public static final String TOKEN_CERT_NOTAFTER = "tokenCertNotAfter";
> +
> +/* Cert Extentions value of the certificate in the authenticating entry 
> */
> +public static final String TOKEN_CERT_EXTENSIONS = "tokenCertExts";
> +
> +/* Serial number of the certificate in the authenticating entry */
> +public static final String TOKEN_CERT_SERIALNUM = "certSerial";
> +
> +/**
> + * Certificate to be renewed
> + */
> +public s

Re: [Pki-devel] [Pki-users] CS Server error

[Fraser Tweedale]

(Sorry, I sent this to the wrong list.)

On Thu, Dec 08, 2016 at 01:59:45PM +1000, Fraser Tweedale wrote:
> On Wed, Dec 07, 2016 at 05:29:41PM -0800, Rafael Leiva-Ochoa wrote:
> > Here you goI hope you can help. I am already starting to use it in
> > production testing...I would hate to start all over...: (
> > 
> The error in your log is:
> 
> [06/Dec/2016:23:28:45][localhost-startStop-1]: AuthSubsystem: 
> initializing authentication manager flatFileAuth
> Property auths.instance.flatFileAuth.pluginName missing value
> at 
> com.netscape.cmscore.base.PropConfigStore.getString(PropConfigStore.java:258)
> at 
> com.netscape.cmscore.authentication.AuthSubsystem.init(AuthSubsystem.java:200)
> at 
> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169)
> at 
> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075)
> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:582)
> at com.netscape.certsrv.apps.CMS.init(CMS.java:187)
> at com.netscape.certsrv.apps.CMS.start(CMS.java:1616)
> ... lots more traceback
> 
> This causes a shutdown of the Dogtag application (but not Tomcat
> itself, hence it is still able to respond to HTTP requests).
> 
> Have you modified anything in /etc/pki/pki-tomcat/ca/CS.cfg
> yourself?  If not, perhaps it was an update gone awry, or some other
> corruption of CS.cfg.
> 
> The `flatFileAuth' properties in CS.cfg should be something like:
> 
> auths.instance.flatFileAuth.authAttributes=PWD
> auths.instance.flatFileAuth.deferOnFailure=true
> 
> auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt
> auths.instance.flatFileAuth.keyAttributes=UID
> auths.instance.flatFileAuth.pluginName=FlatFileAuth
> 
> Try fixing that up and seeing if Dogtag starts.  If it does not,
> please attach debug log (latter portions thereof) and the CS.cfg.
> 
> Thanks,
> Fraser
> 
> 
> > On Wed, Dec 7, 2016 at 4:25 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> > 
> > > On Wed, Dec 07, 2016 at 02:11:53PM -0800, Rafael Leiva-Ochoa wrote:
> > > > Hi Team,
> > > >
> > > >  I have installed Dogtag on one of my Raspberry PI 3 devices for
> > > > testing. At first it was working great. Then, I noticed that it took a
> > > very
> > > > long time for the DogTag Start Page to startup when I rebooted my Pi. In
> > > > some cases, it took 10min's, but I attributed this to the fact that it
> > > was
> > > > running on a ARM processor, and it takes a while to start up. Now, for
> > > some
> > > > reason, I am getting this error:
> > > >
> > > > HTTP Status 500 - CS server is not ready to serve.
> > > >
> > > > *type* Exception report
> > > >
> > > > *message* *CS server is not ready to serve.*
> > > >
> > > > *description* *The server encountered an internal error that prevented 
> > > > it
> > > > from fulfilling this request.*
> > > >
> > > > *exception*
> > > >
> > > > java.io.IOException: CS server is not ready to serve.
> > > >   com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.
> > > java:445)
> > > >   javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> > > >   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > >   sun.reflect.NativeMethodAccessorImpl.invoke(
> > > NativeMethodAccessorImpl.java:62)
> > > >   sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > > DelegatingMethodAccessorImpl.java:43)
> > > >   java.lang.reflect.Method.invoke(Method.java:498)
> > > >   org.apache.catalina.security.SecurityUtil$1.run(
> > > SecurityUtil.java:293)
> > > >   org.apache.catalina.security.SecurityUtil$1.run(
> > > SecurityUtil.java:290)
> > > >   java.security.AccessController.doPrivileged(Native Method)
> > > >   javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
> > > >   org.apache.catalina.security.SecurityUtil.execute(
> > > SecurityUtil.java:325)
> > > >   org.apache.catalina.security.SecurityUtil.doAsPrivilege(
> > > SecurityUtil.java:176)
> > > >   java.security.AccessController.doPrivileged(Native Method)
> > > >   org.apache.tomcat.websocket.server.WsFilter.doFilter(
> > > WsFilter.java:52)
> > > >   sun.reflec

Re: [Pki-devel] [Pki-users] CS Server error

[Fraser Tweedale]

On Wed, Dec 07, 2016 at 05:29:41PM -0800, Rafael Leiva-Ochoa wrote:
> Here you goI hope you can help. I am already starting to use it in
> production testing...I would hate to start all over...: (
> 
The error in your log is:

[06/Dec/2016:23:28:45][localhost-startStop-1]: AuthSubsystem: initializing 
authentication manager flatFileAuth
Property auths.instance.flatFileAuth.pluginName missing value
at 
com.netscape.cmscore.base.PropConfigStore.getString(PropConfigStore.java:258)
at 
com.netscape.cmscore.authentication.AuthSubsystem.init(AuthSubsystem.java:200)
at 
com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169)
at 
com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075)
at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:582)
at com.netscape.certsrv.apps.CMS.init(CMS.java:187)
at com.netscape.certsrv.apps.CMS.start(CMS.java:1616)
... lots more traceback

This causes a shutdown of the Dogtag application (but not Tomcat
itself, hence it is still able to respond to HTTP requests).

Have you modified anything in /etc/pki/pki-tomcat/ca/CS.cfg
yourself?  If not, perhaps it was an update gone awry, or some other
corruption of CS.cfg.

The `flatFileAuth' properties in CS.cfg should be something like:

auths.instance.flatFileAuth.authAttributes=PWD
auths.instance.flatFileAuth.deferOnFailure=true

auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt
auths.instance.flatFileAuth.keyAttributes=UID
auths.instance.flatFileAuth.pluginName=FlatFileAuth

Try fixing that up and seeing if Dogtag starts.  If it does not,
please attach debug log (latter portions thereof) and the CS.cfg.

Thanks,
Fraser


> On Wed, Dec 7, 2016 at 4:25 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> 
> > On Wed, Dec 07, 2016 at 02:11:53PM -0800, Rafael Leiva-Ochoa wrote:
> > > Hi Team,
> > >
> > >  I have installed Dogtag on one of my Raspberry PI 3 devices for
> > > testing. At first it was working great. Then, I noticed that it took a
> > very
> > > long time for the DogTag Start Page to startup when I rebooted my Pi. In
> > > some cases, it took 10min's, but I attributed this to the fact that it
> > was
> > > running on a ARM processor, and it takes a while to start up. Now, for
> > some
> > > reason, I am getting this error:
> > >
> > > HTTP Status 500 - CS server is not ready to serve.
> > >
> > > *type* Exception report
> > >
> > > *message* *CS server is not ready to serve.*
> > >
> > > *description* *The server encountered an internal error that prevented it
> > > from fulfilling this request.*
> > >
> > > *exception*
> > >
> > > java.io.IOException: CS server is not ready to serve.
> > >   com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.
> > java:445)
> > >   javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> > >   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >   sun.reflect.NativeMethodAccessorImpl.invoke(
> > NativeMethodAccessorImpl.java:62)
> > >   sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > >   java.lang.reflect.Method.invoke(Method.java:498)
> > >   org.apache.catalina.security.SecurityUtil$1.run(
> > SecurityUtil.java:293)
> > >   org.apache.catalina.security.SecurityUtil$1.run(
> > SecurityUtil.java:290)
> > >   java.security.AccessController.doPrivileged(Native Method)
> > >   javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
> > >   org.apache.catalina.security.SecurityUtil.execute(
> > SecurityUtil.java:325)
> > >   org.apache.catalina.security.SecurityUtil.doAsPrivilege(
> > SecurityUtil.java:176)
> > >   java.security.AccessController.doPrivileged(Native Method)
> > >   org.apache.tomcat.websocket.server.WsFilter.doFilter(
> > WsFilter.java:52)
> > >   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >   sun.reflect.NativeMethodAccessorImpl.invoke(
> > NativeMethodAccessorImpl.java:62)
> > >   sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > >   java.lang.reflect.Method.invoke(Method.java:498)
> > >   org.apache.catalina.security.SecurityUtil$1.run(
> > SecurityUtil.java:293)
> > >   org.apache.catalina.security.SecurityUtil$1.run(
> > SecurityUtil.java:290)
> > >   java.security.AccessCont

[Pki-devel] [PATCH] 0144..0146 Move IRequest extdata-related constants

[Fraser Tweedale]

The attached patches relocate / redefine some constants that are
used as keys when setting or getting IRequest extdata attributes.

In some cases this removes duplicate constants or string literals.
In other cases it actually defines a new constant.
In all cases the key now uses a constant defined in IRequest, which
is the appropriate place.

This is refactoring work undertaken as part of GSSAPI support.

Thanks,
Fraser
From 31d9026f2be5204dd4742ce00542bc80b614d9b9 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 7 Dec 2016 12:25:01 +1000
Subject: [PATCH 144/146] Define "auth_token" IRequest extdata key prefix in
 one place

Part of: https://fedorahosted.org/pki/ticket/1359
---
 base/common/src/com/netscape/certsrv/request/IRequest.java   |  4 
 .../cms/src/com/netscape/cms/servlet/cert/CertProcessor.java |  9 +++--
 .../src/com/netscape/cms/servlet/processors/CAProcessor.java |  1 -
 .../cms/servlet/profile/ProfileSubmitCMCServlet.java | 12 +++-
 4 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/base/common/src/com/netscape/certsrv/request/IRequest.java 
b/base/common/src/com/netscape/certsrv/request/IRequest.java
index 
c892dbb1dc5d75d4b44e4e26b584f94717b2457c..f17f560de75e54cb7650ee06d870f3d1491e52ac
 100644
--- a/base/common/src/com/netscape/certsrv/request/IRequest.java
+++ b/base/common/src/com/netscape/certsrv/request/IRequest.java
@@ -85,6 +85,10 @@ public interface IRequest extends Serializable {
 // server attributes: attributes generated by server modules.
 public static final String SERVER_ATTRS = "SERVER_ATTRS";
 
+// Sometimes individual IAuthToken fields get set in request
+// extdata, with key ("auth_token." + field_name).
+public static final String AUTH_TOKEN_PREFIX = "auth_token";
+
 public static final String RESULT = "Result"; // service result.
 public static final Integer RES_SUCCESS = Integer.valueOf(1); // result 
value
 public static final Integer RES_ERROR = Integer.valueOf(2); // result value
diff --git 
a/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java 
b/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
index 
17b453ab5d82bd7c18612263f01e297a4e9df3da..cb5efa0b0e14274e0c4a9393522ab18071f60fd8
 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/cert/CertProcessor.java
@@ -310,12 +310,17 @@ public class CertProcessor extends CAProcessor {
 String[] tokenVals = authToken.getInStringArray(tokenName);
 if (tokenVals != null) {
 for (int i = 0; i < tokenVals.length; i++) {
-req.setExtData(ARG_AUTH_TOKEN + "." + tokenName + 
"[" + i + "]", tokenVals[i]);
+req.setExtData(
+IRequest.AUTH_TOKEN_PREFIX
++ "." + tokenName + "[" + i + "]"
+, tokenVals[i]);
 }
 } else {
 String tokenVal = authToken.getInString(tokenName);
 if (tokenVal != null) {
-req.setExtData(ARG_AUTH_TOKEN + "." + tokenName, 
tokenVal);
+req.setExtData(
+IRequest.AUTH_TOKEN_PREFIX + "." + tokenName,
+tokenVal);
 // if RA agent, auto assign the request
 if (tokenName.equals("uid"))
 uid = tokenVal;
diff --git 
a/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java 
b/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java
index 
bb3cfa84a423fe452ef55fb20e23c03911831690..ae91f649541db5ce77679844ad7a4fec680e99e9
 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java
@@ -72,7 +72,6 @@ import netscape.security.x509.X509CertImpl;
 
 public class CAProcessor extends Processor {
 
-public final static String ARG_AUTH_TOKEN = "auth_token";
 public final static String ARG_REQUEST_OWNER = "requestOwner";
 public final static String HDR_LANG = "accept-language";
 public final static String ARG_PROFILE = "profile";
diff --git 
a/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileSubmitCMCServlet.java
 
b/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileSubmitCMCServlet.java
index 
f3adc5e85e58e3fb2dbf47984cfeca6797cd569b..6191031905626cc7acb6ccbdc41ff84942baf86f
 100644
--- 
a/base/server/cms/src/com/netscape/cms/servlet/profile/Profil

[Pki-devel] [PATCH] 0143 Remove unused string constant

[Fraser Tweedale]

What it says on the tin.  Pushed under one-liner rule.

Thanks,
Fraser
From 01956aedf62f20713ca191c254a20f0b50d8e7af Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 7 Dec 2016 14:23:18 +1000
Subject: [PATCH 143/143] Remove unused string constant

Part of: https://fedorahosted.org/pki/ticket/1359
---
 base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java 
b/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java
index 
606b6afaa60c48bb6eec2602b86ae1ed68a22d26..bb3cfa84a423fe452ef55fb20e23c03911831690
 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/processors/CAProcessor.java
@@ -116,7 +116,6 @@ public class CAProcessor extends Processor {
 public static final String AUTHZ_MGR = "authzMgr";
 public static final String GET_CLIENT_CERT = "getClientCert";
 public static final String ACL_INFO = "ACLinfo";
-public static final String AUTHORITY_ID = "authorityId";
 public static final String PROFILE_SUB_ID = "profileSubId";
 
 public final static String LOGGING_SIGNED_AUDIT_CERT_REQUEST_PROCESSED =
-- 
2.7.4

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0141 Add getAuthzManagerNameByRealm to IAuthzSubsystem

[Fraser Tweedale]

This patch renames (a better name) and moves to the IAuthzSubsystem
interface a method in AuthzSubsystem that may be useful for doing
authorisation checks for external principals.

Thanks,
Fraser
From 6a1ddf4cf79e40ff0a0702e063afa6e6237f0fb6 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 25 Nov 2016 21:08:56 +1000
Subject: [PATCH 141/141] Add getAuthzManagerNameByRealm to IAuthzSubsystem

The getAuthzManagerByRealm public method is defined in
AuthzSubsystem but to support external principals we want to make
this part of the IAuthzSubsystem interface, so other classes (e.g.
ACLInterceptor) can use it.

Part of: https://fedorahosted.org/pki/ticket/1359
---
 .../netscape/certsrv/authorization/IAuthzSubsystem.java  |  9 +
 .../netscape/cmscore/authorization/AuthzSubsystem.java   | 16 +---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git 
a/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java 
b/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java
index 
c7d8df56bbfb1bf8af6c51ce491fc1384560b4a8..6fcf8e7b03eb596bb7914912474eeb3c298b6da1
 100644
--- a/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java
+++ b/base/common/src/com/netscape/certsrv/authorization/IAuthzSubsystem.java
@@ -21,6 +21,7 @@ import java.util.Enumeration;
 import java.util.Hashtable;
 
 import com.netscape.certsrv.authentication.IAuthToken;
+import com.netscape.certsrv.authorization.EAuthzUnknownRealm;
 import com.netscape.certsrv.base.EBaseException;
 import com.netscape.certsrv.base.ISubsystem;
 
@@ -181,4 +182,12 @@ public interface IAuthzSubsystem extends ISubsystem {
  * @return an authorization manager interface
  */
 public IAuthzManager get(String name);
+
+/**
+ * Given a realm name, return the name of an authz manager for that realm.
+ *
+ * @throws EAuthzUnknownRealm if no authz manager is found.
+ */
+public String getAuthzManagerNameByRealm(String realm)
+throws EAuthzUnknownRealm;
 }
diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
 
b/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
index 
31d5e71b4bdd672fa3eae3108824480d87eafdf3..67d12bdff2e716bcea4034726d189a23c6f50796
 100644
--- 
a/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
+++ 
b/base/server/cmscore/src/com/netscape/cmscore/authorization/AuthzSubsystem.java
@@ -495,10 +495,7 @@ public class AuthzSubsystem implements IAuthzSubsystem {
 // if record owner == requester, SUCCESS
 if ((owner != null) && 
owner.equals(authToken.getInString(IAuthToken.USER_ID))) return;
 
-String mgrName = getAuthzManagerByRealm(realm);
-if (mgrName == null) {
-throw new EAuthzUnknownRealm("Realm not found");
-}
+String mgrName = getAuthzManagerNameByRealm(realm);
 
 AuthzToken authzToken = authorize(mgrName, authToken, resource, 
operation, realm);
 if (authzToken == null) {
@@ -506,12 +503,17 @@ public class AuthzSubsystem implements IAuthzSubsystem {
 }
 }
 
-public String getAuthzManagerByRealm(String realm) throws EBaseException {
+public String getAuthzManagerNameByRealm(String realm) throws 
EAuthzUnknownRealm {
 for (AuthzManagerProxy proxy : mAuthzMgrInsts.values()) {
 IAuthzManager mgr = proxy.getAuthzManager();
 if (mgr != null) {
 IConfigStore cfg = mgr.getConfigStore();
-String mgrRealmString = cfg.getString(PROP_REALM, null);
+String mgrRealmString = null;
+try {
+mgrRealmString = cfg.getString(PROP_REALM, null);
+} catch (EBaseException e) {
+// never mind
+}
 if (mgrRealmString == null) continue;
 
 List mgrRealms = 
Arrays.asList(mgrRealmString.split(","));
@@ -521,7 +523,7 @@ public class AuthzSubsystem implements IAuthzSubsystem {
 }
 }
 }
-return null;
+throw new EAuthzUnknownRealm("Realm not found");
 }
 
 }
-- 
2.7.4

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0139 Merge duplicate authz plugin code into superclass

[Fraser Tweedale]

The attached patch merges some duplicate authz manager code into the
existing AAclAuthz superclass.

It simplifies things if we end up adding a new authz manager as part
of external authentication / GSS-API support.  But it's a nice
refactor to do anyway :)

Thanks,
Fraser
From afc5fc3da5f1ea61305fb237e002bbe8b3d26e8c Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 25 Nov 2016 14:29:40 +1000
Subject: [PATCH 139/141] Merge duplicate authz plugin code into superclass

DirAclAuthz and BasicAclAuthz both extend AAclAuthz, but there is
still a lot of duplicate code.  Push the duplicated bits up into the
AAclAuthz.

Also remove abstract method flushResourceACLs() from AAclAuthz, and
its implementation from BasicAclAuthz, because it is only
implemented (meaningfully) by DirAclAuthz.

Part of: https://fedorahosted.org/pki/ticket/1359
---
 .../com/netscape/cms/authorization/AAclAuthz.java  |  93 ++---
 .../netscape/cms/authorization/BasicAclAuthz.java  | 144 +
 .../netscape/cms/authorization/DirAclAuthz.java| 105 +--
 3 files changed, 78 insertions(+), 264 deletions(-)

diff --git a/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java 
b/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java
index 
b3e447cfca49951fe78f6b4896652921ffc43406..f95c98174a06dba9ebf3e43238e566be2e6b5594
 100644
--- a/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java
+++ b/base/server/cms/src/com/netscape/cms/authorization/AAclAuthz.java
@@ -30,6 +30,9 @@ import com.netscape.certsrv.acls.IACL;
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.authentication.IAuthToken;
 import com.netscape.certsrv.authorization.AuthzToken;
+import com.netscape.certsrv.authorization.EAuthzAccessDenied;
+import com.netscape.certsrv.authorization.EAuthzInternalError;
+import com.netscape.certsrv.authorization.IAuthzManager;
 import com.netscape.certsrv.base.EBaseException;
 import com.netscape.certsrv.base.IConfigStore;
 import com.netscape.certsrv.evaluators.IAccessEvaluator;
@@ -61,7 +64,7 @@ import com.netscape.cmsutil.util.Utils;
  * @version $Revision$, $Date$
  * @see http://developer.netscape.com/library/documentation/enterprise/admnunix/aclfiles.htm;>ACL
 Files
  */
-public abstract class AAclAuthz {
+public abstract class AAclAuthz implements IAuthzManager {
 
 protected static final String PROP_CLASS = "class";
 protected static final String PROP_IMPL = "impl";
@@ -69,6 +72,12 @@ public abstract class AAclAuthz {
 
 protected static final String ACLS_ATTR = "aclResources";
 
+/* name of this authorization manager instance */
+private String mName = null;
+
+/* name of the authorization manager plugin */
+private String mImplName = null;
+
 private IConfigStore mConfig = null;
 
 private Hashtable<String, ACL> mACLs = new Hashtable<String, ACL>();
@@ -93,14 +102,14 @@ public abstract class AAclAuthz {
 /**
  * Initializes
  */
-protected void init(IConfigStore config)
+public void init(String name, String implName, IConfigStore config)
 throws EBaseException {
-
+mName = name;
+mImplName = implName;
+mConfig = config;
 mLogger = CMS.getLogger();
 CMS.debug("AAclAuthz: init begins");
 
-mConfig = config;
-
 // load access evaluators specified in the config file
 IConfigStore mainConfig = CMS.getConfigStore();
 IConfigStore evalConfig = mainConfig.getSubStore(PROP_EVAL);
@@ -144,6 +153,20 @@ public abstract class AAclAuthz {
 }
 
 /**
+ * gets the name of this authorization manager instance
+ */
+public String getName() {
+return mName;
+}
+
+/**
+ * gets the plugin name of this authorization manager.
+ */
+public String getImplName() {
+return mImplName;
+}
+
+/**
  * Parse ACL resource attributes, then update the ACLs memory store
  * This is intended to be used if storing ACLs on ldap is not desired,
  * and the caller is expected to call this method to add resource
@@ -818,7 +841,7 @@ public abstract class AAclAuthz {
 }
 }
 
-private void log(int level, String msg) {
+protected void log(int level, String msg) {
 if (mLogger == null)
 return;
 mLogger.log(ILogger.EV_SYSTEM, null, ILogger.S_AUTHORIZATION,
@@ -830,24 +853,58 @@ public abstract class AAclAuthz {
  **/
 
 /**
- * update acls. called after memory upate is done to flush to permanent
- * storage.
- * 
- */
-protected abstract void flushResourceACLs() throws EACLsException;
-
-/**
- * an abstract class that enforces implementation of the
- * authorize() method that will authorize an operation on a
- * particular resource
+ * check the authorization permissio

[Pki-devel] [PATCH] 0138 Move AuthToken key constants to IAuthToken

[Fraser Tweedale]

The attached patch moves some string constants from AuthToken to
IAuthToken.  External authentication support will bring a new
implementation of IAuthToken so moving these to the interface
simplifies things.

Thanks,
Fraser
From 8118f83cc7691e48c63111a050540c9180fd29e5 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 29 Nov 2016 16:10:58 +1000
Subject: [PATCH 138/141] Move AuthToken key constants to IAuthToken

Part of: https://fedorahosted.org/pki/ticket/1359
---
 .../netscape/certsrv/authentication/AuthToken.java | 34 --
 .../certsrv/authentication/IAuthToken.java | 34 ++
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/base/common/src/com/netscape/certsrv/authentication/AuthToken.java 
b/base/common/src/com/netscape/certsrv/authentication/AuthToken.java
index 
0febf87727d2ebde9dbcacbd5059f9b9afa13701..53959b131f2d9a99e6b9b65640f8546e84468c66
 100644
--- a/base/common/src/com/netscape/certsrv/authentication/AuthToken.java
+++ b/base/common/src/com/netscape/certsrv/authentication/AuthToken.java
@@ -51,40 +51,6 @@ import com.netscape.certsrv.usrgrp.Certificates;
 public class AuthToken implements IAuthToken {
 protected Hashtable<String, Object> mAttrs = null;
 
-/* Subject name of the certificate in the authenticating entry */
-public static final String TOKEN_CERT_SUBJECT = "tokenCertSubject";
-
-/* NotBefore value of the certificate in the authenticating entry */
-public static final String TOKEN_CERT_NOTBEFORE = "tokenCertNotBefore";
-
-/* NotAfter value of the certificate in the authenticating entry */
-public static final String TOKEN_CERT_NOTAFTER = "tokenCertNotAfter";
-
-/* Cert Extentions value of the certificate in the authenticating entry */
-public static final String TOKEN_CERT_EXTENSIONS = "tokenCertExts";
-
-/* Serial number of the certificate in the authenticating entry */
-public static final String TOKEN_CERT_SERIALNUM = "certSerial";
-
-/**
- * Certificate to be renewed
- */
-public static final String TOKEN_CERT = "tokenCert";
-
-/* Certificate to be revoked */
-public static final String TOKEN_CERT_TO_REVOKE = "tokenCertToRevoke";
-
-/**
- * Name of the authentication manager that created the AuthToken
- * as a string.
- */
-public static final String TOKEN_AUTHMGR_INST_NAME = "authMgrInstName";
-
-/**
- * Time of authentication as a java.util.Date
- */
-public static final String TOKEN_AUTHTIME = "authTime";
-
 /**
  * Constructs an instance of a authentication token.
  * The token by default contains the following attributes: 
diff --git 
a/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java 
b/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
index 
a71432446edcf6b5d838f1115df16b26acd01dce..a3f240e9c35987462eb2f176de650a769df1005c
 100644
--- a/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
+++ b/base/common/src/com/netscape/certsrv/authentication/IAuthToken.java
@@ -41,6 +41,40 @@ public interface IAuthToken {
 public static final String UID = "uid";
 public static final String GROUPS = "groups";
 
+/* Subject name of the certificate in the authenticating entry */
+public static final String TOKEN_CERT_SUBJECT = "tokenCertSubject";
+
+/* NotBefore value of the certificate in the authenticating entry */
+public static final String TOKEN_CERT_NOTBEFORE = "tokenCertNotBefore";
+
+/* NotAfter value of the certificate in the authenticating entry */
+public static final String TOKEN_CERT_NOTAFTER = "tokenCertNotAfter";
+
+/* Cert Extentions value of the certificate in the authenticating entry */
+public static final String TOKEN_CERT_EXTENSIONS = "tokenCertExts";
+
+/* Serial number of the certificate in the authenticating entry */
+public static final String TOKEN_CERT_SERIALNUM = "certSerial";
+
+/**
+ * Certificate to be renewed
+ */
+public static final String TOKEN_CERT = "tokenCert";
+
+/* Certificate to be revoked */
+public static final String TOKEN_CERT_TO_REVOKE = "tokenCertToRevoke";
+
+/**
+ * Name of the authentication manager that created the AuthToken
+ * as a string.
+ */
+public static final String TOKEN_AUTHMGR_INST_NAME = "authMgrInstName";
+
+/**
+ * Time of authentication as a java.util.Date
+ */
+public static final String TOKEN_AUTHTIME = "authTime";
+
 /**
  * Sets an attribute value within this AttrSet.
  *
-- 
2.7.4

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0137 Remove unused member

[Fraser Tweedale]

Just a drive-by removal of an unused class member.  Pushed under
one-liner rule.

Thanks,
Fraser
From e613f485e9ed08b9b5e6b2ad568a0953b742b0e5 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 28 Nov 2016 14:52:11 +1000
Subject: [PATCH] Remove unused member

---
 base/server/cms/src/com/netscape/cms/profile/common/BasicProfile.java | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/base/server/cms/src/com/netscape/cms/profile/common/BasicProfile.java 
b/base/server/cms/src/com/netscape/cms/profile/common/BasicProfile.java
index 
ea5108445356e848ecb9520c7147a75181c11c51..ff97bfa6ce395fcf70ff9e39b0cd47f9416e2493
 100644
--- a/base/server/cms/src/com/netscape/cms/profile/common/BasicProfile.java
+++ b/base/server/cms/src/com/netscape/cms/profile/common/BasicProfile.java
@@ -89,7 +89,6 @@ public abstract class BasicProfile implements IProfile {
 protected Vector mOutputIds = new Vector();
 protected Hashtable<String, IProfileUpdater> mUpdaters = new 
Hashtable<String, IProfileUpdater>();
 protected Vector mUpdaterIds = new Vector();
-protected IProfileAuthenticator mAuthenticator = null;
 protected String mAuthInstanceId = null;
 protected String mId = null;
 protected String mAuthzAcl = "";
-- 
2.7.4

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0135 Do not attempt LWCA key retrieval for host authority

[Fraser Tweedale]

Hi team,

Please review the attached patch which fixes a regression in
two-step externally-signed CA installation.  It is destined for 10.3
branch as well as master.

https://fedorahosted.org/pki/ticket/2466

Cheers,
Fraser
From fca5fd053434d112998c814bc6d9424b6a5bac98 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 21 Sep 2016 20:18:37 +1000
Subject: [PATCH] Do not attempt LWCA key retrieval for host authority

During two-step installation of externally-signed CA, installation
can fail because host authority's private key cannot be located (a
temporary condition), causing LWCA key replication to fire, which
throws NullPointerException because the host authority's AuthorityID
has not been set yet.

Do not start key retrieval if the CA's AuthorityID is null (a
condition which implies that the CA is the host authority).

Fixes: https://fedorahosted.org/pki/ticket/2466
---
 base/ca/src/com/netscape/ca/CertificateAuthority.java | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java 
b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 
1f77fd81fc850af9996329dbec7d6a973ba62942..a4f102435ae7a1f2ab1e27814a52b5689639d0f7
 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -1569,7 +1569,12 @@ public class CertificateAuthority
 CMS.debug("CA signing key and cert not (yet) present in 
NSSDB");
 signingUnitException = e;
 if (retrieveKeys == true) {
-if (!keyRetrieverThreads.containsKey(authorityID)) {
+if (authorityID == null) {
+// Only the host authority should ever see a
+// null authorityID, e.g. during two-step
+// installation of externally-signed CA.
+CMS.debug("null authorityID -> host authority; not 
starting KeyRetriever");
+} else if (!keyRetrieverThreads.containsKey(authorityID)) {
 CMS.debug("Starting KeyRetrieverRunner thread");
 Thread t = new Thread(
 new KeyRetrieverRunner(authorityID, mNickname, 
authorityKeyHosts),
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0134 Block reads during reload of LDAP-based profiles

[Fraser Tweedale]

On Wed, Sep 14, 2016 at 07:16:32PM -0500, Endi Sukma Dewata wrote:
> On 9/14/2016 7:14 AM, Fraser Tweedale wrote:
> > Hi team,
> > 
> > The attached patch fixes (yet another) race condition in
> > LDAPProfileSubsystem.
> > 
> > https://fedorahosted.org/pki/ticket/2453
> > 
> > Additional context: https://fedorahosted.org/freeipa/ticket/6274
> > 
> > Thanks,
> > Fraser
> 
> The patch looks fine, but probably it can be simplified like this:
> 
> class LDAPProfileSubsystem {
> 
> void init() {
> 
> // load initial profiles
> repository = new LDAPProfileRepository();
> repository.load();
> 
> // monitor profile changes in the background
> monitor = new Thread(repository);
> monitor.start();
> }
> 
> IProfile getProfile(id) {
> return repository.getProfile(id);
> }
> }
> 
> class LDAPProfileRepository {
> 
> LinkedHashMap profiles = ...
> 
> void synchronized load() {
> 
> // create persistent search
> conn = dbFactory.getConn();
> results = conn.search(...);
> 
> // get number of profiles
> entry = results.next();
> numProfiles = entry.getAttribute("numSubordinates");
> 
> for (i=0; i<numProfiles; i++) {
> // read profile
> entry = results.next();
> readProfile(entry);
> }
> }
> 
> void synchronized readProfile() {
> ...
> }
> 
> IProfile synchronized getProfile(id) {
> return profiles.get(id);
> }
> 
> void run() {
> 
> while (true) {
> try {
> // process profile changes
> while (results.hasMoreElements()) {
> entry = results.next();
> ...
> }
> } catch (...) {
> // reconnect
> load();
> }
> }
> }
> }
> 
> So the load() will block during initialization and will also block readers
> during reload after reconnect. We probably can replace "synchronized" with
> ReadWriteLock to allow concurrent readers.
> 
Yep, that's a good approach.

> Feel free to push the patch as is (assuming it's well tested). We can make
> further improvements later on.
> 
> One thing though, I highly suggest that we fix this issue on both Fedora and
> RHEL/CentOS platforms. The patch is non-trivial, so the behavior could be
> different if not applied consistently. Since PKI is developed mainly on
> Fedora but used on different platforms, it would be much easier to
> troubleshoot issues by keeping the behavior consistent across platforms,
> especially on anything related to concurrency.
> 
> We don't need to create new builds for all platforms at the same time, but
> we should at least push this patch to all 10.3 branches so it can be picked
> up in the next 10.3 build of the corresponding platform.
> 
The patch is (at this stage) not destined for 10.3 at all.  I'd
prefer to push it to master to be included in Fedora when 10.4 gets
released, and other platforms' builds whenever they rebase.

I might go ahead and implement your suggested change before merging,
too, although probably as a second patch.

Thanks for reviewing!

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0134 Block reads during reload of LDAP-based profiles

[Fraser Tweedale]

Hi team,

The attached patch fixes (yet another) race condition in
LDAPProfileSubsystem.

https://fedorahosted.org/pki/ticket/2453

Additional context: https://fedorahosted.org/freeipa/ticket/6274

Thanks,
Fraser
From 24a5ad6f84387055468e0125df90fea6635da484 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 14 Sep 2016 19:39:36 +1000
Subject: [PATCH] Block reads during reload of LDAP-based profiles

LDAP disconnect (e.g. due to DS restart) causes LDAPProfileSubsystem
to drop all its profiles and reload them.  If a profile is read
during this time, e.g. to issue a certificate, it might not have
been reloaded thus causing the operation to fail.

Introduce the AsyncLoader class which allows a consumer to await the
completion of a (re)load, if one is happening.  Update the
getProfile and getProfileIds method to use it.

The existing 'initialLoadDone' CountDownLatch for blocking
LDAPProfileSubsystem init until the inital load of profiles is
completed was subsumed by AsyncLoader.

Fixes: https://fedorahosted.org/pki/ticket/2453
---
 .../src/com/netscape/certsrv/util/AsyncLoader.java | 86 ++
 .../cmscore/profile/LDAPProfileSubsystem.java  | 59 ++-
 2 files changed, 127 insertions(+), 18 deletions(-)
 create mode 100644 base/common/src/com/netscape/certsrv/util/AsyncLoader.java

diff --git a/base/common/src/com/netscape/certsrv/util/AsyncLoader.java 
b/base/common/src/com/netscape/certsrv/util/AsyncLoader.java
new file mode 100644
index 
..39f8efd3272607ed6ac219b1b42bf9a4cb076a80
--- /dev/null
+++ b/base/common/src/com/netscape/certsrv/util/AsyncLoader.java
@@ -0,0 +1,86 @@
+// --- BEGIN COPYRIGHT BLOCK ---
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of the GNU General Public License as published by
+// the Free Software Foundation; version 2 of the License.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this program; if not, write to the Free Software Foundation, Inc.,
+// 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+//
+// (C) 2016  Red Hat, Inc.
+// All rights reserved.
+// --- END COPYRIGHT BLOCK ---
+
+package com.netscape.certsrv.util;
+
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.locks.ReentrantLock;
+
+/** A locking mechanism for loading or reloading an initially
+ * unknown number of items.
+ *
+ * The "producer" is the thread that loads items, informing the
+ * Loader when each item is loaded and how many items there are
+ * (when that fact becomes known).
+ *
+ * Other threads can await the completion of a (re)loading
+ * process.
+ */
+public class AsyncLoader {
+private CountDownLatch producerInitialised = new CountDownLatch(1);
+private ReentrantLock loadingLock = new ReentrantLock();
+private Integer numItems = null;
+private int numItemsLoaded = 0;
+
+/**
+ * Acquire the lock as a producer.
+ */
+public void startLoading() {
+numItems = null;
+numItemsLoaded = 0;
+loadingLock.lock();
+producerInitialised.countDown();
+}
+
+/**
+ * Increment the number of items loaded by 1.  If the number
+ * of items is known and that many items have been loaded,
+ * unlock the loader.
+ */
+public void increment() {
+numItemsLoaded += 1;
+checkLoadDone();
+}
+
+/**
+ * Set the number of items.  If the number of items already
+ * loaded is equal to or greater than the number, unlock the
+ * loader.
+ */
+public void setNumItems(Integer n) {
+numItems = n;
+checkLoadDone();
+}
+
+private void checkLoadDone() {
+if (numItems != null && numItemsLoaded >= numItems) {
+while (loadingLock.isHeldByCurrentThread())
+loadingLock.unlock();
+}
+}
+
+public void awaitLoadDone() throws InterruptedException {
+/* A consumer may await upon the Loader immediately after
+ * starting the producer.  To ensure that the producer
+ * has time to acquire the lock, we use a CountDownLatch.
+ */
+producerInitialised.await();
+loadingLock.lock();
+loadingLock.unlock();
+}
+}
diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
 
b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
index 
6dea1a0d88beaefeea489ea58ad9ad13d2da8bd7..fd5aa64eed8385ad18a307b6addaee6222d9f9cf
 100644
--- 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
+++ 
b/base/server/cmsco

[Pki-devel] [PATCH] 0130 Prevent deletion of host CA cert and key from NSSDB

[Fraser Tweedale]

Hi,

Attached patch fixes https://fedorahosted.org/pki/ticket/2443.

Thanks,
Fraser
From e0a546113b65d57e4b00b495f4ef50616ad744c1 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 24 Aug 2016 14:40:46 +1000
Subject: [PATCH] Prevent deletion of host CA cert and key from NSSDB

If authorityMonitor observes the deletion of the host CA's authority
entry, it will treat it the same as any other lightweight CA and
delete the signing cert AND KEY from the NSSDB. Because the database
is replicated, the change would be observed and deletion immediately
effected on all running clones.  Unless the main CA private key is
backed up somewhere there is no way to recover from this.

Although this scenario does not arise in normal operation, the
impact is severe so add a check that prevents cert and key deletion
for host authority.

Fixes: https://fedorahosted.org/pki/ticket/2443
---
 base/ca/src/com/netscape/ca/CertificateAuthority.java | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java 
b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 
a5397da0c0dcea654a15f16e5becc5c430a1bb29..6276100a079ff32757bf2de8540f6e6efa1d1cae
 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -2991,6 +2991,13 @@ public class CertificateAuthority
 /** Delete keys and certs of this authority from NSSDB.
  */
 private void deleteAuthorityNSSDB() throws ECAException {
+if (isHostAuthority()) {
+String msg = "Attempt to delete host authority signing key; not 
proceeding";
+log(ILogger.LL_WARN, msg);
+CMS.debug(msg);
+return;
+}
+
 CryptoManager cryptoManager;
 try {
 cryptoManager = CryptoManager.getInstance();
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] JSS/NSS

[Fraser Tweedale]

On Fri, Aug 05, 2016 at 10:10:22AM -0700, George Wash wrote:
> Are there any plans on the dogtag roadmap to ever migrate away from using
> JSS/NSS?
> 
Hi George,

I dont't think there are any such plans.  Why do you ask?

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0128 Fix CA OCSP responder when LWCA's are not in use

[Fraser Tweedale]

Hi team,

The attached patch fixes https://fedorahosted.org/pki/ticket/2420.

Thanks,
Fraser
From 86030eb0c231734a3020b201a9be60e84d023e75 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 26 Jul 2016 14:07:10 +1000
Subject: [PATCH] Fix CA OCSP responder when LWCAs are not in use

The CA subsystem OCSP responder was updated to handle dispatching
OCSP requests to the relevant CertificateAuthority instance,
according to the issuer of the certificates identified in the
request.  Unfortunately, the updated routine assumes that the
database updates that enable lightweight CAs have occurred.  If they
have not, the OCSP responder always fails.

Fix the issue by inferring that if 'caMap' is empty, lightweight CAs
are not in use, the current instance is the one and only CA, and
proceed straight to validation.

Fixes: https://fedorahosted.org/pki/ticket/2420
---
 base/ca/src/com/netscape/ca/CertificateAuthority.java | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java 
b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 
502ab1856352fb26ed480a3a54d59ffca5facdb3..a5397da0c0dcea654a15f16e5becc5c430a1bb29
 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -2240,6 +2240,10 @@ public class CertificateAuthority
  * employ some heuristic to deal with this case. Our
  * heuristic is:
  *
+ * 0. If caMap contains no CAs, then lightweight CAs are not
+ *enabled.  There is only one CA, and 'this' is it.  Go
+ *straight to validation.
+ *
  * 1. Find the issuer of the cert identified by the first
  *CertID in the request.
  *
@@ -2254,7 +2258,7 @@ public class CertificateAuthority
  *aggregate OCSP response.
  */
 ICertificateAuthority ocspCA = this;
-if (tbsReq.getRequestCount() > 0) {
+if (caMap.size() > 0 && tbsReq.getRequestCount() > 0) {
 com.netscape.cmsutil.ocsp.Request req = tbsReq.getRequestAt(0);
 BigInteger serialNo = req.getCertID().getSerialNumber();
 X509CertImpl cert = mCertRepot.getX509Certificate(serialNo);
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Added fix for pki-server for db-update

[Fraser Tweedale]

On Thu, Jul 14, 2016 at 03:51:18PM +0530, Geetika Kapoor wrote:
> 
> 
> On 07/14/2016 03:02 PM, Geetika Kapoor wrote:
> >
> > On 07/14/2016 01:53 PM, Fraser Tweedale wrote:
> >> On Thu, Jul 14, 2016 at 06:01:51PM +1000, Fraser Tweedale wrote:
> >>> On Thu, Jul 14, 2016 at 01:05:18PM +0530, Geetika Kapoor wrote:
> >>>> On 07/14/2016 11:38 AM, Geetika Kapoor wrote:
> >>>>> On 07/14/2016 10:06 AM, Fraser Tweedale wrote:
> >>>>>> On Wed, Jul 13, 2016 at 04:36:26PM +0530, Geetika Kapoor wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Please review this patch.Below is a small summary about this fix and
> >>>>>>> what we are trying to achieve.
> >>>>>>>
> >>>>>>> CLI :  pki-server db-upgrade
> >>>>>>>
> >>>>>>> what it should be doing is if it sees that issuerName doesn't 
> >>>>>>> exist,NULL
> >>>>>>> it will add it itself.
> >>>>>>>
> >>>>>>> Operation 1 : Search for the empty cn value for issuerName
> >>>>>>> ---
> >>>>>>>
> >>>>>>> Current :   '(&(objectclass=certificateRecord)(issuerName=*))  -- I
> >>>>>>> tried this it didn't show data even if i have record with empty 
> >>>>>>> issuerName
> >>>>>>>
> >>>>>> Hi Geetika,
> >>>>>>
> >>>>>> The current filter is actually:
> >>>>>>
> >>>>>>   '(&(objectclass=certificateRecord)(!(issuerName=*)))',
> >>>>>>
> >>>>>> This should match entries missing the issuerName attribute.  You
> >>>>>> talk about an entry with "empty issuerName" but empty strings are
> >>>>>> not allowed for the Directory String attribute type.  Could you
> >>>>>> please clarify exactly what data is in the offending entry/entries
> >>>>>> and how it got there?
> >>>>> Hi Fraser,
> >>>>>
> >>>>> If we disable syntax check in ldap dse.ldif , it will accept empty
> >>>>> data as well.So if a end user disable syntax check,issuerName can be
> >>>>> empty in that case.(a test case that i tried)
> >>>>> So in that case db-update will never happen because that condition is
> >>>>> not considered.This scenario can be reproduced using below ldif file.
> >>>>>
> >>>>> 
> >>>>>
> >>>>> dn: cn=106,ou=certificateRepository,ou=ca,o=pkitest-CA
> >>>>> objectClass: certificateRecord
> >>>>> objectClass: top
> >>>>> cn: 106
> >>>>> algorithmId: 1.2.840.113549.1.1.1
> >>>>> autoRenew: ENABLED
> >>>>> certStatus: VALID
> >>>>> dateOfCreate: 20160712084443Z
> >>>>> dateOfModify: 20160712084443Z
> >>>>> duration: 113153600
> >>>>> issuedBy:   geetika20
> >>>>> *issuerName: *  
> >>>>> metaInfo: requestId:100
> >>>>> notAfter: 20170712084205Z
> >>>>> notBefore: 20160712084205Z
> >>>>> publicKeyData::
> >>>>> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu0Hlk6SdMnyr0Igq
> >>>>> serialno: 100
> >>>>> signingAlgorithmId: 1.2.840.113549.1.1.11
> >>>>> subjectName: CN=CS Administrator,C=US
> >>>>> userCertificate;binary::
> >>>>> MIIC6DCCAdCgAwIBAgIBBzANBgkqhkiG9w0BAQsFADBHMSQwIgY
> >>>>> version: 2
> >>>>>
> >>>>> 
> >>>>>
> >>>>> So in such a case using
> >>>>> '(&(objectclass=certificateRecord)(!(issuerName=*)))',will not able to
> >>>>> search for such entries.I tried and it gives me empty data .I believe
> >>>>> using (&(objectclass=certificateRecord)
> >>>>> (!(issuerName=*))(!(issuerName=cn*))) can solve that purpose.
> >>>>>
> >>>>> Thanks
> >>>>> Geetika
> >>>> Hi Frazer,
> >>>>
> >>>> I just did one quick round of testing .If we have
> >>>> '(&(objectclass=certificateRecord)(!(issuerName=cn*)))', it will work in
> >>>> both cases :
> >>>>
> >>>> 1. When issuerName doesn't exist.
> >>>> 2. When issuserName field exist but has empty value.
> >>>>
> >>>> Thanks
> >>>> Geetika
> >>>>
> >>> I still disagree that it is the right approach, because it may do
> >>> unnecessary work for records that already have an issuerName that
> >>> does not start with "cn".
> >>>
> >>> Is it even necessary to support cases where customer has disabled
> >>> syntax checking?  Nevertheless, let me disable syntax checking on
> >>> one of my instances and see if I can find a better filter.
> >>>
> >> Please try this filter:
> >>
> >> (&(objectclass=certificaterecord)(|(!(issuername=*))(issuername=)))
> >>
> >> It will find only certificates with missing or empty issuername
> >> attribute.  Does it work as expected for you, Geetika?
> > Let me try Frazer..
> >
> > Thanks
> 
> Thanks Frazer for helping in giving a better solution .
>
You're welcome.  ACK, and pushed to master:

c3ff087bd07cde4cd272defad499fd4d8367e5c1

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Added fix for pki-server for db-update

[Fraser Tweedale]

On Wed, Jul 13, 2016 at 04:36:26PM +0530, Geetika Kapoor wrote:
> Hi,
> 
> Please review this patch.Below is a small summary about this fix and
> what we are trying to achieve.
> 
> CLI :  pki-server db-upgrade
> 
> what it should be doing is if it sees that issuerName doesn't exist,NULL
> it will add it itself.
> 
> Operation 1 : Search for the empty cn value for issuerName
> ---
> 
> Current :   '(&(objectclass=certificateRecord)(issuerName=*))  -- I
> tried this it didn't show data even if i have record with empty issuerName
> 
Hi Geetika,

The current filter is actually:

  '(&(objectclass=certificateRecord)(!(issuerName=*)))',

This should match entries missing the issuerName attribute.  You
talk about an entry with "empty issuerName" but empty strings are
not allowed for the Directory String attribute type.  Could you
please clarify exactly what data is in the offending entry/entries
and how it got there?

> Modified :  (&(objectclass=certificateRecord)(!(issuerName=cn*)))'   --
> This solves the purpose as it shows all the certs without issuerName
> 
This filter is wrong - it does match entries without issuerName (as
intended), but also matches entries with issuerName set but not
starting with "cn".

> 
> Operation 2 : If we see a empty cn value , we are replacing it with
> value we get from code
> --
> < code>
> 
> cert = nss.Certificate(bytearray(attr_cert[0]))
> issuer_name = str(cert.issuer)
> 
> 
> 
> Current : we are updating the list it the format as mentioned 
> 'issuerName': ['', 'CN=CA Signing Certificate,O=example.com Security
> Domain']
> 
> Do we want to keep this behavior or we want to overwrite it in first
> place? I believe in place of we do it MOD_REPLACE.
> 
>  conn.ldap.modify_s(dn, [(ldap.MOD_ADD, 'issuerName',
> issuer_name)])
> >
> 
> Modified : onn.ldap.modify_s(dn, [(ldap.MOD_REPLACE, 'issuerName',
> issuer_name)])
> 
This change is OK.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 781 Added instance and subsystem validation for pki-server ca-* commands.

[Fraser Tweedale]

On Thu, Jun 30, 2016 at 08:38:57PM -0500, Endi Sukma Dewata wrote:
> The pki-server ca-* commands have been modified to validate
> the instance and the CA subsystem before proceeding with the
> operation.
> 
> The usage() methods and invocations have been renamed into
> print_help() for consistency.
> 
> https://fedorahosted.org/pki/ticket/2364
> 
> -- 
> Endi S. Dewata
>
ACK; pushed to master (f8310a4ff306d28cf25ec71693a2e89c5323564d).

There are still lots of pki-server commands that fail if invalid
subsystem given, e.g.:

# pki-server subsystem-cert-find kra

AttributeError: 'NoneType' object has no attribute 'find_system_certs'

But that can be addressed separately in future patch.

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 780 Fixed pki-server subsystem-cert-update.

[Fraser Tweedale]

On Wed, Jun 29, 2016 at 11:19:46AM -0500, Endi Sukma Dewata wrote:
> The pki-server subsystem-cert-update is supposed to restore the
> system certificate data and requests into CS.cfg. The command was
> broken since the CASubsystem class that contains the code to find
> the certificate requests from database was not loaded correctly.
> To fix the problem the CASubsystem class has been moved into the
> pki/server/__init__.py.
> 
> All pki-server subsystem-* commands have been modified to check
> the validity of the instance.
> 
> An option has been added to the pki-server subsystem-cert-show
> command to display the data and request of a particular system
> certificate.
> 
> The redundant output of the pki-server subsystem-cert-update has
> been removed. The updated certificate data and request can be
> obtained using the pki-server subsystem-cert-show command.
> 
> https://fedorahosted.org/pki/ticket/2385
> 
ACK; pushed to master (67bbdc5edd1404f89e638037599b4231f50490f8).

Thanks,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0124 Add profiles container to LDAP if missing

[Fraser Tweedale]

On Thu, Jun 30, 2016 at 10:10:32AM -0500, Endi Sukma Dewata wrote:
> On 6/22/2016 4:53 AM, Fraser Tweedale wrote:
> > The attached patch fixes https://fedorahosted.org/pki/ticket/2285.
> > See commit message and bz1323400[1] for full history and details.
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1323400
> > 
> > The fix should be merged to master and DOGTAG_10_2_BRANCH, and a new
> > 10.2.x release cut for f23.
> > 
> > I have an f23 COPR build containing the fix for anyone wishing to
> > test:
> > https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/packages/
> > 
> > Huge props to Adam Williamson for doing a lot of legwork in tracking
> > down the cause of this issue.
> > 
> > Thanks,
> > Fraser
> 
> ACK. When we have a proper database upgrade method we should consider
> converting this code into an upgrade script.
> 
Thanks; pushed:

master  2dea243d51765e3a8f01f7680592143c842921ce
DOGTAG_10_2_BRANCH  c34d326712940524419d65c6cb6cc9653221362b
DOGTAG_10_2_6_BRANCHf0d036feb9604cc656b3b8ae46c822bec14e6ac8

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0126 Respond 400 if lightweight CA cert issuance fails

[Fraser Tweedale]

On Thu, Jun 30, 2016 at 10:49:12AM -0500, Endi Sukma Dewata wrote:
> On 6/27/2016 9:52 PM, Fraser Tweedale wrote:
> > The attached patch fixes https://fedorahosted.org/pki/ticket/2388.
> > Wanted for 10.3.4.
> > 
> > Thanks,
> > Fraser
> 
> Two things:
> 
> 1. I don't think the patch author is correct :)
> 
Hah, yikes!  I think I accidentally squashed something and didn't
notice the author had changed after I fixed it up :)

> 2. Existing issue, but while you're there could you chain the original
> exception to the ECAException?
> 
Yep, done.  Pushed to master
(c7f9e6c4e0711dfafc81d201dcfadee3e0efa335)

Cheers,
Fraser

> Assuming they're addressed, ACK.
>

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0126 Respond 400 if lightweight CA cert issuance fails

[Fraser Tweedale]

The attached patch fixes https://fedorahosted.org/pki/ticket/2388.
Wanted for 10.3.4.

Thanks,
Fraser
From 3ad777d8009f025f1aac1159910dd0a4d327bd13 Mon Sep 17 00:00:00 2001
From: "Endi S. Dewata" 
Date: Sat, 25 Jun 2016 00:14:11 +0200
Subject: [PATCH] Respond 400 if lightweight CA cert issuance fails

If certificate issuance fails during lightweight CA creation (e.g.
due to a profile constraint violation such as Subject DN not
matching pattern) the API responds with status 500.

Raise BadRequestDataException if cert issuance fails in a way that
indicates bad or invalid CSR data, and catch it to respond with
status 400.

Fixes: https://fedorahosted.org/pki/ticket/2388
---
 base/ca/src/com/netscape/ca/CertificateAuthority.java  | 18 +++---
 .../org/dogtagpki/server/ca/rest/AuthorityService.java |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java 
b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 
e501380c8dd6d2d6fc400ad9f43677bfae7e258e..9f6445c56369f00cd857890fe63b577b6db81350
 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -74,6 +74,7 @@ import org.mozilla.jss.pkix.primitive.Name;
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.authentication.IAuthToken;
 import com.netscape.certsrv.authority.ICertAuthority;
+import com.netscape.certsrv.base.BadRequestDataException;
 import com.netscape.certsrv.base.EBaseException;
 import com.netscape.certsrv.base.EPropertyNotFound;
 import com.netscape.certsrv.base.IConfigStore;
@@ -2680,8 +2681,16 @@ public class CertificateAuthority
 if (result != null && !result.equals(IRequest.RES_SUCCESS))
 throw new EBaseException("createSubCA: certificate request 
submission resulted in error: " + result);
 RequestStatus requestStatus = request.getRequestStatus();
-if (requestStatus != RequestStatus.COMPLETE)
-throw new EBaseException("createSubCA: certificate request did 
not complete; status: " + requestStatus);
+if (requestStatus != RequestStatus.COMPLETE) {
+// The request did not complete.  Inference: something
+// incorrect in the request (e.g. profile constraint
+// violated).
+String msg = "Failed to issue CA certificate. Final status: " 
+ requestStatus + ".";
+String errorMsg = request.getExtDataInString(IRequest.ERROR);
+if (errorMsg != null)
+msg += " Additional info: " + errorMsg;
+throw new BadRequestDataException(msg);
+}
 
 // Add certificate to nssdb
 cert = 
request.getExtDataInCert(IEnrollProfile.REQUEST_ISSUED_CERT);
@@ -2697,7 +2706,10 @@ public class CertificateAuthority
 // log this error.
 CMS.debug("Error deleting new authority entry after failure 
during certificate generation: " + e2);
 }
-throw new ECAException("Error creating lightweight CA certificate: 
" + e);
+if (e instanceof BadRequestDataException)
+throw (BadRequestDataException) e;  // re-throw
+else
+throw new ECAException("Error creating lightweight CA 
certificate: " + e);
 }
 
 CertificateAuthority ca = new CertificateAuthority(
diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java 
b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
index 
5ecabacd9a84a4d06e529ca0099f561155f7d791..7bca10fa1dfbfe7dbae5b5c0288c4c59c1075cf9
 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
@@ -38,6 +38,7 @@ import javax.ws.rs.core.UriInfo;
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.authority.AuthorityData;
 import com.netscape.certsrv.authority.AuthorityResource;
+import com.netscape.certsrv.base.BadRequestDataException;
 import com.netscape.certsrv.base.BadRequestException;
 import com.netscape.certsrv.base.ConflictingOperationException;
 import com.netscape.certsrv.base.EBaseException;
@@ -207,7 +208,7 @@ public class AuthorityService extends PKIService implements 
AuthorityResource {
 audit(ILogger.SUCCESS, OpDef.OP_ADD,
 subCA.getAuthorityID().toString(), auditParams);
 return createOKResponse(readAuthorityData(subCA));
-} catch (IllegalArgumentException e) {
+} catch (IllegalArgumentException | BadRequestDataException e) {
 throw new BadRequestException(e.toString());
 } catch (CANotFoundException e) {
 throw new ResourceNotFoundException(e.toString());
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com

[Pki-devel] [PATCH] 0124 Add profiles container to LDAP if missing

[Fraser Tweedale]

The attached patch fixes https://fedorahosted.org/pki/ticket/2285.
See commit message and bz1323400[1] for full history and details.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1323400

The fix should be merged to master and DOGTAG_10_2_BRANCH, and a new
10.2.x release cut for f23.

I have an f23 COPR build containing the fix for anyone wishing to
test:
https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/packages/

Huge props to Adam Williamson for doing a lot of legwork in tracking
down the cause of this issue.

Thanks,
Fraser
From 4cbaf297690bf95fffc864cb109bdd6ae49c9dc3 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 22 Jun 2016 13:34:01 +1000
Subject: [PATCH] Add profiles container to LDAP if missing

CMS startup was changed a while back to wait for
LDAPProfileSubsystem initialisation, while LDAPProfileSubsystem
initialisation waits for all known profiles to be loaded by the LDAP
persistent search thread.  If the ou=certificateProfiles container
object does not exist, startup hangs.

This can cause a race condition in FreeIPA upgrade.  FreeIPA
switches the Dogtag instance to the LDAPProfileSubsystem and
restarts it.  The restart fails because the container object does
not get added until after the restart.

Update LDAPProfileSubsystem to add the container object itself, if
it is missing, before commencing the persistent search.

Fixes: https://fedorahosted.org/pki/ticket/2285
---
 .../cmscore/profile/LDAPProfileSubsystem.java | 19 +++
 1 file changed, 19 insertions(+)

diff --git 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
 
b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
index 
28b34cda889cc6c2eba4fc3392863df36717fa14..6dea1a0d88beaefeea489ea58ad9ad13d2da8bd7
 100644
--- 
a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
+++ 
b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java
@@ -27,6 +27,7 @@ import java.util.TreeSet;
 import java.util.concurrent.CountDownLatch;
 
 import netscape.ldap.LDAPAttribute;
+import netscape.ldap.LDAPAttributeSet;
 import netscape.ldap.LDAPConnection;
 import netscape.ldap.LDAPDN;
 import netscape.ldap.LDAPEntry;
@@ -400,6 +401,23 @@ public class LDAPProfileSubsystem
 initialLoadDone.countDown();
 }
 
+private void ensureProfilesOU(LDAPConnection conn) throws LDAPException {
+try {
+conn.search(dn, LDAPConnection.SCOPE_BASE, "(objectclass=*)", 
null, false);
+} catch (LDAPException e) {
+if (e.getLDAPResultCode() == LDAPException.NO_SUCH_OBJECT) {
+CMS.debug("Adding LDAP certificate profiles container");
+LDAPAttribute[] attrs = {
+new LDAPAttribute("objectClass", "organizationalUnit"),
+new LDAPAttribute("ou", "certificateProfiles")
+};
+LDAPAttributeSet attrSet = new LDAPAttributeSet(attrs);
+LDAPEntry entry = new LDAPEntry(dn, attrSet);
+conn.add(entry);
+}
+}
+}
+
 public void run() {
 int op = LDAPPersistSearchControl.ADD
 | LDAPPersistSearchControl.MODIFY
@@ -416,6 +434,7 @@ public class LDAPProfileSubsystem
 forgetAllProfiles();
 try {
 conn = dbFactory.getConn();
+ensureProfilesOU(conn);
 LDAPSearchConstraints cons = conn.getSearchConstraints();
 cons.setServerControls(persistCtrl);
 cons.setBatchSize(1);
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal

[Fraser Tweedale]

On Tue, Jun 21, 2016 at 07:29:22AM +0200, Jan Cholasta wrote:
> On 18.6.2016 02:38, Fraser Tweedale wrote:
> > On Fri, Jun 17, 2016 at 03:21:07PM +0200, Jan Cholasta wrote:
> > > On 17.6.2016 09:34, Fraser Tweedale wrote:
> > > > On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote:
> > > > > Hi,
> > > > > 
> > > > > On 6.5.2016 08:01, Fraser Tweedale wrote:
> > > > > > Hullo all,
> > > > > > 
> > > > > > FreeIPA Lightweight CAs implementation is progressing well.  The
> > > > > > remaining big unknown in the design is how to do renewal.  I have
> > > > > > put my ideas into the design page[1] and would appreciate any and
> > > > > > all feedback!
> > > > > > 
> > > > > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal
> > > > > > 
> > > > > > Some brief commentary on the options:
> > > > > > 
> > > > > > I intend to implement approach (1) as a baseline.  Apart from
> > > > > > implementing machinery in Dogtag to actually perform the renewal -
> > > > > > which is required for all the approaches - it's not much work and
> > > > > > gets us over the "lightweight CAs can be renewed easily" line, even
> > > > > > if it is a manual process.
> > > > > > 
> > > > > > For automatic renewal, I am leaning towards approach (2).  Dogtag
> > > > > > owns the lightweight CAs so I think it makes sense to give Dogtag
> > > > > > the ability to renew them automatically (if configured to do so),
> > > > > > without relying on external tools i.e. Certmonger.  But as you will
> > > > > > see from the outlines, each approach has its upside and downside.
> > > > > 
> > > > > I would prefer (3), as I would very much like to avoid duplicating
> > > > > certmonger's functionality in Dogtag.
> > > > > 
> > > > > Some comments on the disadvantages:
> > > > > 
> > > > >   * "Proliferation of Certmonger tracking requests; one for each
> > > > > FreeIPA-managed lightweight CA."
> > > > > 
> > > > > I don't think this is an actual issue, as it's purely cosmetic.
> > > > > 
> > > > >   * "Either lightweight CA creation is restricted to the renewal 
> > > > > master, or
> > > > > the renewal master must observe the creation of new lightweight CAs 
> > > > > and
> > > > > start tracking their certificate."
> > > > > 
> > > > > IMO this doesn't have to be done automatically in the initial
> > > > > implementation. You could extend ipa-certupdate to set up certmonger 
> > > > > for
> > > > > lightweight CAs and have admins run it manually on masters after 
> > > > > adding a
> > > > > new lightweight CA. They will have to run it anyway to get the new
> > > > > lightweight CA certificate installed in the system, so it should be 
> > > > > fine to
> > > > > do it this way.
> > > > > 
> > > > I have updated the renew_ca_cert post-save script to perform the
> > > > database update necessary for CA replicas to pick up the new cert.
> > > > What remains is the command to tell certmonger to track the CA.
> > > > 
> > > > You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a
> > > > better fit, e.g.:
> > > > 
> > > > ipa-cacert-manage track 
> > > > 
> > > > It would look up the necessary info (basically just the CA-ID) and
> > > > set up the certmonger tracking.
> > > 
> > > No. ipa-cacert-manage updates global configuration in LDAP, whereas
> > > ipa-certupdate applies the global configuration on the local system.
> > > Updating certmonger configuration is the latter, hence it should be done 
> > > in
> > > ipa-certupdate.
> > > 
> > > Also, I don't think we should expose (un)tracking certificates by CA ID to
> > > users, as all our CA certificates should always be tracked.
> > > 
> > OK, so ipa-certupdate just gets run without arguments on a CA
> > master, and it ensures that all CA certificates are tracked by
> > Certmonger.
> 
> Right.
> 
> > 
> > Makes s

Re: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal

[Fraser Tweedale]

On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote:
> Hi,
> 
> On 6.5.2016 08:01, Fraser Tweedale wrote:
> > Hullo all,
> > 
> > FreeIPA Lightweight CAs implementation is progressing well.  The
> > remaining big unknown in the design is how to do renewal.  I have
> > put my ideas into the design page[1] and would appreciate any and
> > all feedback!
> > 
> > [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal
> > 
> > Some brief commentary on the options:
> > 
> > I intend to implement approach (1) as a baseline.  Apart from
> > implementing machinery in Dogtag to actually perform the renewal -
> > which is required for all the approaches - it's not much work and
> > gets us over the "lightweight CAs can be renewed easily" line, even
> > if it is a manual process.
> > 
> > For automatic renewal, I am leaning towards approach (2).  Dogtag
> > owns the lightweight CAs so I think it makes sense to give Dogtag
> > the ability to renew them automatically (if configured to do so),
> > without relying on external tools i.e. Certmonger.  But as you will
> > see from the outlines, each approach has its upside and downside.
> 
> I would prefer (3), as I would very much like to avoid duplicating
> certmonger's functionality in Dogtag.
> 
> Some comments on the disadvantages:
> 
>   * "Proliferation of Certmonger tracking requests; one for each
> FreeIPA-managed lightweight CA."
> 
> I don't think this is an actual issue, as it's purely cosmetic.
> 
>   * "Either lightweight CA creation is restricted to the renewal master, or
> the renewal master must observe the creation of new lightweight CAs and
> start tracking their certificate."
> 
> IMO this doesn't have to be done automatically in the initial
> implementation. You could extend ipa-certupdate to set up certmonger for
> lightweight CAs and have admins run it manually on masters after adding a
> new lightweight CA. They will have to run it anyway to get the new
> lightweight CA certificate installed in the system, so it should be fine to
> do it this way.
> 
I have updated the renew_ca_cert post-save script to perform the
database update necessary for CA replicas to pick up the new cert.
What remains is the command to tell certmonger to track the CA.

You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a
better fit, e.g.:

ipa-cacert-manage track 

It would look up the necessary info (basically just the CA-ID) and
set up the certmonger tracking.

It could be an error to run the command on other than the renewal
master.

An untrack command could also be provided.

Thoughts?

>   * "Development of new Certmonger renewal helpers solely for lightweight CA
> renewal."
> 
> It would be easier to extend the existing helpers. I don't think there
> is anything preventing them from being used for lighweight CAs, except not
> conveying the CA name, which should be easy to implement.
> 
> 
> I would also avoid starting with (1), I don't believe it adds any real
> value. IMHO the first thing that should be done is implement lightweight CA
> support in certmonger (add new 'request' / 'start-tracking' option for CA
> name, store it in tracking requests, pass it to CA helpers in a new
> environment variable).
> 
> 
> Honza
> 
> -- 
> Jan Cholasta

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 772 Updated instructions to customize TPS token lifecycle.

[Fraser Tweedale]

On Wed, Jun 15, 2016 at 11:36:28AM -0500, Endi Sukma Dewata wrote:
> The TPS's CS.cfg and token-states.properties have been updated
> to include instructions to customize token state transitions and
> labels.
> 
> https://fedorahosted.org/pki/ticket/2300
> 
ACK

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 768 Added pki pkcs12-cert-mod command.

[Fraser Tweedale]

On Mon, Jun 13, 2016 at 07:24:01PM -0500, Endi Sukma Dewata wrote:
> A new CLI has been added to update the certificate trust flags in
> PKCS #12 file which will be useful to import OpenSSL certificates.
> 
Tested; does what it says on the tin.
ACK.

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 767 Fixed VLV usage in TPS token and activity services.

[Fraser Tweedale]

On Fri, Jun 10, 2016 at 10:29:51AM -0500, Endi Sukma Dewata wrote:
> The TPS token and activity services have been modified to use VLV
> only when the search filter matches the VLV, which is the default
> filter when there is no search keyword/attributes specified by
> the client. In other cases the services will use a normal search.
> 
> https://fedorahosted.org/pki/ticket/2342
> 
> -- 
> Endi S. Dewata
>
Code changes look good.  Might be nice to construct the
(Token|Activity)Collection objects inside the find* methods rather
than constructing it at call side and passing it in to be populated.
Just a nit, though.

Searching/filtering continues to work as expected.

ACK.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0123 Do not attempt cert update unless signing key is present

[Fraser Tweedale]

On Tue, Jun 14, 2016 at 07:40:12PM -0500, Endi Sukma Dewata wrote:
> On 6/13/2016 9:38 PM, Fraser Tweedale wrote:
> > Hi all,
> > 
> > The attached patch fixes https://fedorahosted.org/pki/ticket/2359.
> > Please review for inclusion in 10.3.3.
> > 
> > Thanks,
> > Fraser
> 
> It looks like the initSignUnit() is only called with retrieveKeys=true in
> init(). So the code that starts the key retriever thread probably can be
> moved out, becoming something like this:
> 
>   initDefCaAttrs();
> 
>   try {
>   initSignUnit();
>   checkForNewerCert();
> 
>   } catch (CAMissingCertException | CAMissingKeyException e) {
>   // start key retriever thread
> 
>   } catch (EBaseException e) {
>   ...
>   }
> 
> I think it would clarify a little bit how the missing cert/key is handled.
> 
Yes, that will be a nice refactor.  I may send a patch for that soon.

> So if I understand correctly if the cert/key is missing the LWCA object will
> still be created and registered, but it will be disabled (hasKeys=false)?
> 
> When the key retriever thread is complete, will it automatically
> reinitialize and enable the LWCA object?
> 
Yes to both question.  The bug was that an exception could be thrown
when constructing the LWCA object (thus it was not registered).
Key retrieval had been initiated and successfully retrieved the key,
but there was no LWCA object to reinitialise.

> Regardless, feel free to push the patch as is.
> 
Thanks, pushed to master (41aef5254c20301851716ef46b614d185b33a87b)

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0122 Modify ExternalProcessKeyRetriever to read JSON

[Fraser Tweedale]

Hi Endi et al,

Attached patch changes ExternalProcessKeyRetriever to read JSON data
(https://fedorahosted.org/pki/ticket/2351).  Would be nice to get
this into 10.2.2 because it will simplify IPA custodia retrieval
helper.

I am using Jackson for JSON parsing.  This is already an implicit
dependency, but should I also add it spec file as explicit
dependency?

Cheers,
Fraser
From 7183cece34b766b5e1db6837291151b4d58aa9c9 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Sat, 4 Jun 2016 20:49:38 +1000
Subject: [PATCH] Modify ExternalProcessKeyRetriever to read JSON

The ExternalProcessKeyRetriever currently uses a hackish format
where the certificate and PKIArchiveOptions data are separated by a
null byte.  Update the code to expect JSON instead.

No backwards compatibility is provided because at time of writing
the ExternalProcessKeyRetriever is only used in a FreeIPA feature
still under development.

Fixes: https://fedorahosted.org/pki/ticket/2351
---
 base/ca/src/CMakeLists.txt | 15 +
 .../netscape/ca/ExternalProcessKeyRetriever.java   | 37 +-
 2 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/base/ca/src/CMakeLists.txt b/base/ca/src/CMakeLists.txt
index 
1817dacfbacaeb2635db2550e32ff62c26d628ef..2a43c8dbb4f88c22df244bb752ea963b2f0d646c
 100644
--- a/base/ca/src/CMakeLists.txt
+++ b/base/ca/src/CMakeLists.txt
@@ -38,6 +38,20 @@ find_file(COMMONS_LANG_JAR
 /usr/share/java
 )
 
+find_file(JACKSON_CORE_JAR
+NAMES
+jackson-core-asl.jar
+PATHS
+/usr/share/java/jackson
+)
+
+find_file(JACKSON_MAPPER_JAR
+NAMES
+jackson-mapper-asl.jar
+PATHS
+/usr/share/java/jackson
+)
+
 find_file(JAXRS_API_JAR
 NAMES
 jaxrs-api.jar
@@ -81,6 +95,7 @@ javac(pki-ca-classes
 org/dogtagpki/server/ca/*.java
 CLASSPATH
 ${COMMONS_CODEC_JAR} ${COMMONS_IO_JAR} ${COMMONS_LANG_JAR}
+${JACKSON_CORE_JAR} ${JACKSON_MAPPER_JAR}
 ${JSS_JAR} ${SYMKEY_JAR}
 ${LDAPJDK_JAR}
 ${SERVLET_JAR} ${TOMCAT_CATALINA_JAR}
diff --git a/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java 
b/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java
index 
6aee9716e1e5953018ed4c3f3316c9b7d4c88a45..a1b77485284d699bbb524bfc64b3c348663c4c1e
 100644
--- a/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java
+++ b/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java
@@ -18,6 +18,8 @@
 
 package com.netscape.ca;
 
+import java.io.IOException;
+import java.io.InputStream;
 import java.lang.Process;
 import java.lang.ProcessBuilder;
 import java.util.Collection;
@@ -26,6 +28,9 @@ import java.util.Stack;
 import org.apache.commons.io.IOUtils;
 import org.apache.commons.lang.ArrayUtils;
 
+import org.codehaus.jackson.map.ObjectMapper;
+import org.codehaus.jackson.JsonNode;
+
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.base.EBaseException;
 import com.netscape.certsrv.base.EPropertyNotFound;
@@ -65,21 +70,7 @@ public class ExternalProcessKeyRetriever implements 
KeyRetriever {
 int exitValue = p.waitFor();
 if (exitValue != 0)
 continue;
-
-/* Read a PEM-encoded certificate and a base64-encoded
- * PKIArchiveOptions containing the wrapped private key,
- * separated by a null byte.
- */
-byte[] output = IOUtils.toByteArray(p.getInputStream());
-int splitIndex = ArrayUtils.indexOf(output, (byte) 0);
-if (splitIndex == ArrayUtils.INDEX_NOT_FOUND) {
-CMS.debug("Invalid output: null byte not found");
-continue;
-}
-return new Result(
-ArrayUtils.subarray(output, 0, splitIndex),
-ArrayUtils.subarray(output, splitIndex + 1, output.length)
-);
+return parseResult(p.getInputStream());
 } catch (Throwable e) {
 CMS.debug("Caught exception while executing command: " + e);
 } finally {
@@ -89,4 +80,20 @@ public class ExternalProcessKeyRetriever implements 
KeyRetriever {
 CMS.debug("Failed to retrieve key from any host.");
 return null;
 }
+
+/* Read a PEM-encoded certificate and a base64-encoded
+ * PKIArchiveOptions containing the wrapped private key.
+ * Data is expected to be a JSON object with keys "certificate"
+ * and "wrapped_key".
+ */
+private Result parseResult(InputStream in) throws IOException {
+JsonNode root = (new ObjectMapper()).readTree(in);
+String cert = root.path("certificate").getTextValue();
+byte[] pao = root.path("wrapped_key").getBinaryValue();
+if (cert == null)
+throw new RuntimeException(&q

Re: [Pki-devel] [PATCH] 0120..0121 Remove pki-ipa-retrieve-key script

[Fraser Tweedale]

On Thu, Jun 02, 2016 at 11:45:43PM -0500, Endi Sukma Dewata wrote:
> On 5/31/2016 11:45 PM, Fraser Tweedale wrote:
> > G'day comrades,
> > 
> > Please review the attached two patches, which...
> > 
> > (Patch 0120)
> > 
> > - provide for passing of configuration (from CS.cfg) to KeyRetriever
> >   implementations
> > 
> > - generalise IPACustodiaKeyRetriever to ExternalProcessKeyRetriever,
> >   which executes a configured executable rather than a hardcoded one
> > 
> > (Patch 0121)
> > 
> > - remove pki-ipa-retrieve-key script; it is being moved to FreeIPA
> >   repo
> > 
> > Cheers,
> > Fraser
> 
> ACK.
> 
> Separate issue. Instead of returning multiple binary attributes delimited
> with 0 byte through standard output, it might be better to use JSON file
> instead. So the command can be defined something like this:
> 
> features.authority.keyRetrieverConfig.exec=/usr/libexec/pki-ipa-retrieve-key
> -o {output}
> 
> The ExternalProcessKeyRetriever will replace the {output} with a temporary
> file, then later parse the result from that file.
> 
Thanks Endi; pushed to master:

419ca3000142c60f176aabc68a2c5c3a1a3c1ea9 Lightweight CAs: remove 
pki-ipa-retrieve-key script
f11e0b372e3a0736050dd9e2858fce3178171ee6 Lightweight CAs: generalise 
subprocess-based key retrieval

I agree with the JSON enhancement, but not with using a temporary
file; we can just send the JSON through stdout.  I filed ticket:
https://fedorahosted.org/pki/ticket/2351

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0112 Return 410 Gone if target CA of request has been deleted

[Fraser Tweedale]

On Thu, Jun 02, 2016 at 08:02:35PM -0500, Endi Sukma Dewata wrote:
> On 5/17/2016 12:20 AM, Fraser Tweedale wrote:
> > Hi all,
> > attached patch fixes https://fedorahosted.org/pki/ticket/2332
> > 
> > Cheers,
> > Fraser
> 
> Assuming an identical CA cannot be created to replace the old one, HTTP 410
> Gone is fine. If it's possible, it should be HTTP 404 Not Found. ACK.
>
Authority IDs are random UUIDs, so I think we can safely say that
Gone means Gone :)

Thanks for reviewing!
Pushed to master (443ad5e35e106f84b5439ee7d2861ccd5d6245f3)

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0116 Fix LDAP schema violation when instance name contains '_'

[Fraser Tweedale]

On Tue, May 31, 2016 at 11:07:51AM -0500, Endi Sukma Dewata wrote:
> On 5/29/2016 10:25 PM, Fraser Tweedale wrote:
> > The attached patch fixes https://fedorahosted.org/pki/ticket/2343
> > 
> > Cheers,
> > Fraser
> 
> ACK.
> 
Thanks Endi!  Pushed to master
(a40139d5f21139d31b62d3c35002b454131245f1)

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0116 Fix LDAP schema violation when instance name contains '_'

[Fraser Tweedale]

The attached patch fixes https://fedorahosted.org/pki/ticket/2343

Cheers,
Fraser
From a40139d5f21139d31b62d3c35002b454131245f1 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 30 May 2016 12:17:12 +1000
Subject: [PATCH] Fix LDAP schema violation when instance name contains '_'

The instance name is used in NSSDB key nicknames, which are stored
in the authorityKeyNickname attribute for mapping lightweight CAs to
their keys.  The schema was PrintableString, which does not permit
'_', causing LDAP syntax errors if the instance name contains '_'.

To avoid this issue, change the attribute syntax to IA5String.
Existing instances should be largely unaffected.  The schema update
can be successfully applied even for existing attributes, because
PrintableString and IA5String share the same underlying
representation in 389DS.

Fixes: https://fedorahosted.org/pki/ticket/2343
---
 base/server/share/conf/schema-authority.ldif | 2 +-
 base/server/share/conf/schema.ldif   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/base/server/share/conf/schema-authority.ldif 
b/base/server/share/conf/schema-authority.ldif
index 
fd3c4fa225b036142a9aa4e99c65697365160dfd..1102b53378be55181c4d5dd5f073cbede34bc974
 100644
--- a/base/server/share/conf/schema-authority.ldif
+++ b/base/server/share/conf/schema-authority.ldif
@@ -1,6 +1,6 @@
 dn: cn=schema
 attributeTypes: ( authorityID-oid NAME 'authorityID' DESC 'Authority ID' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE X-ORIGIN 'user defined' )
-attributeTypes: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 
'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE 
X-ORIGIN 'user-defined' )
+attributeTypes: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 
'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE 
X-ORIGIN 'user-defined' )
 attributeTypes: ( authorityParentID-oid NAME 'authorityParentID' DESC 
'Authority Parent ID' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE 
X-ORIGIN 'user defined' )
 attributeTypes: ( authorityEnabled-oid NAME 'authorityEnabled' DESC 'Authority 
Enabled' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'user 
defined' )
 attributeTypes: ( authorityDN-oid NAME 'authorityDN' DESC 'Authority DN' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'user defined' )
diff --git a/base/server/share/conf/schema.ldif 
b/base/server/share/conf/schema.ldif
index 
2fbc86bf181d81a2b2b32f0130543124c33607ae..828d94b31afe54a97dd1c8a416afeb41ad4ca432
 100644
--- a/base/server/share/conf/schema.ldif
+++ b/base/server/share/conf/schema.ldif
@@ -677,7 +677,7 @@ dn: cn=schema
 changetype: modify
 add: attributeTypes
 attributeTypes: ( authorityID-oid NAME 'authorityID' DESC 'Authority ID' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE X-ORIGIN 'user defined' )
-attributeTypes: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 
'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE 
X-ORIGIN 'user-defined' )
+attributeTypes: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 
'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE 
X-ORIGIN 'user-defined' )
 attributeTypes: ( authorityParentID-oid NAME 'authorityParentID' DESC 
'Authority Parent ID' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE 
X-ORIGIN 'user defined' )
 attributeTypes: ( authorityEnabled-oid NAME 'authorityEnabled' DESC 'Authority 
Enabled' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'user 
defined' )
 attributeTypes: ( authorityDN-oid NAME 'authorityDN' DESC 'Authority DN' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'user defined' )
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0112 Return 410 Gone if target CA of request has been deleted

[Fraser Tweedale]

Hi all,
attached patch fixes https://fedorahosted.org/pki/ticket/2332

Cheers,
Fraser
From baf904216848a5d775948853764d2657ea6405e9 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 17 May 2016 14:47:11 +1000
Subject: [PATCH] Return 410 Gone if target CA of request has been deleted

When processing a request whose target CA has been deleted in
between request submission and request approval, the server does not
handle the CANotFoundException, resulting in response status 500.

Catch the CANotFoundException and respond with status 410 Gone.

Fixes: https://fedorahosted.org/pki/ticket/2332
---
 base/ca/src/org/dogtagpki/server/ca/rest/CertRequestService.java | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/CertRequestService.java 
b/base/ca/src/org/dogtagpki/server/ca/rest/CertRequestService.java
index 
80aaf6f7899d92675c15c6f944b7a3a491784145..d154e8eec31c3c74883e606d95eaa2094f36ff2f
 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/CertRequestService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/CertRequestService.java
@@ -41,6 +41,7 @@ import com.netscape.certsrv.base.BadRequestDataException;
 import com.netscape.certsrv.base.BadRequestException;
 import com.netscape.certsrv.base.ConflictingOperationException;
 import com.netscape.certsrv.base.EBaseException;
+import com.netscape.certsrv.base.HTTPGoneException;
 import com.netscape.certsrv.base.PKIException;
 import com.netscape.certsrv.base.ResourceNotFoundException;
 import com.netscape.certsrv.base.ServiceUnavailableException;
@@ -49,6 +50,7 @@ import com.netscape.certsrv.ca.AuthorityID;
 import com.netscape.certsrv.ca.CADisabledException;
 import com.netscape.certsrv.ca.CAMissingCertException;
 import com.netscape.certsrv.ca.CAMissingKeyException;
+import com.netscape.certsrv.ca.CANotFoundException;
 import com.netscape.certsrv.ca.ICertificateAuthority;
 import com.netscape.certsrv.cert.CertEnrollmentRequest;
 import com.netscape.certsrv.cert.CertRequestInfo;
@@ -252,6 +254,11 @@ public class CertRequestService extends PKIService 
implements CertRequestResourc
 } catch (BadRequestDataException e) {
 CMS.debug("changeRequestState: bad request data: " + e);
 throw new BadRequestException(e.toString());
+} catch (CANotFoundException e) {
+// The target CA does not exist (deleted between
+// request submission and approval).
+CMS.debug("changeRequestState: CA not found: " + e);
+throw new HTTPGoneException(e.toString());
 } catch (CADisabledException e) {
 CMS.debug("changeRequestState: CA disabled: " + e);
 throw new ConflictingOperationException(e.toString());
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0111 Lightweight CAs: remove NSSDB material when processing deletion

[Fraser Tweedale]

The attached patch makes clones delete lightweight CA keys/certs
from local NSSDB when processing LWCA deletion.

Ticket: https://fedorahosted.org/pki/ticket/2328

Thanks,
Fraser
From 96079be3caea27ab1ecd5e6486a31c5c3629 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 16 May 2016 12:20:21 +1000
Subject: [PATCH] Lightweight CAs: remove NSSDB material when processing
 deletion

When processing a CA deletion that occurred on another clone, remove
the CA's certificate and key from the local NSSDB.

Fixes: https://fedorahosted.org/pki/ticket/2328
---
 base/ca/src/com/netscape/ca/CertificateAuthority.java | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java 
b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 
8ef6fd4b6dc97b9108f470a38f45eec864f24015..9dc3ad060f78512bba3786a641b62182d9122553
 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -2850,9 +2850,13 @@ public class CertificateAuthority
 
 shutdown();
 
-// delete ldap entry
 deleteAuthorityEntry(authorityID);
+deleteAuthorityNSSDB();
+}
 
+/** Delete keys and certs of this authority from NSSDB.
+ */
+private void deleteAuthorityNSSDB() throws ECAException {
 CryptoManager cryptoManager;
 try {
 cryptoManager = CryptoManager.getInstance();
@@ -3146,6 +3150,18 @@ public class CertificateAuthority
 attr = entry.getAttribute("authorityID");
 if (attr != null) {
 aid = new AuthorityID(attr.getStringValueArray()[0]);
+CertificateAuthority ca = (CertificateAuthority) getCA(aid);
+if (ca == null)
+return;  // shouldn't happen
+
+try {
+ca.deleteAuthorityNSSDB();
+} catch (ECAException e) {
+// log and carry on
+CMS.debug(
+"Caught exception attempting to delete NSSDB material "
++ "for authority '" + aid + "': " + e);
+}
 forgetAuthority(aid);
 }
 }
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0105 Add pki-server ca-cert-db-upgrade command

[Fraser Tweedale]

On Tue, May 10, 2016 at 02:42:52PM -0400, Ade Lee wrote:
> The patch itself is fine.
> 
> I'm just struggling with where this script should exist.
> 
> pki-server ca-cert-db-upgrade seems like an awfully generic description
> for this operation - which basically provides a very specific db
> migration.  For that matter, why not ca-db-upgrade?
> 
My thinking was that, in the future, whatever DB upgrades are needed
for a subsystem could be added to the command.

So on that, I take your point re "ca-db-upgrade" and will cut a new
patch with that command name.

> What happens the next time someone needs to do a CA DB upgrade?
> I'm almost wondering if a separate pki-db tool is needed.
> 
I think having it as part of pki-server(1) is a satisfactory fit.

> For that matter though, its possible that the database is quite large
> so attempting to do this automatically during upgrade is probably not
> advisable.
> 
We can leave it as a manual step for now (for Dogtag itself).

ipa-server-install may need to run it.  In the future, to avoid
unnecessary work, we can track which "steps" have been run (either
on disk or, preferably, in LDAP itself).  Updates themselves should
be idempotent.

> Opening up for others to chime in ..
> 
> Ade
> 
> On Tue, 2016-05-10 at 08:32 +1000, Fraser Tweedale wrote:
> > On Mon, May 09, 2016 at 04:06:46PM -0400, Ade Lee wrote:
> > > Isn't all this predicated on a schema change that adds the issuer
> > > as an
> > > optional field for the certRecord?
> > > 
> > The schema already exists but was unused.
> > 
> > > Ade
> > > 
> > > On Mon, 2016-05-09 at 17:15 +1000, Fraser Tweedale wrote:
> > > > Hi all,
> > > > 
> > > > The following patch adds a pki-server subcommand for updating
> > > > certificate records to add the issuerName attribute.
> > > > 
> > > > It is for #1667 (Database upgrade script to add issuerName
> > > > attribute
> > > > to all cert entries).
> > > > 
> > > > Follow-up question: should I (and if so, how should I) also add
> > > > an
> > > > upgrade scriptlet to perform the upgrade for Dogtag CA subsystem
> > > > on
> > > > the host?  Is there a precedent for invoking pki-server (or
> > > > subroutines thereof) from pki-server-upgrade scriptlets?
> > > > 
> > > > Cheers,
> > > > Fraser
> > > > ___
> > > > Pki-devel mailing list
> > > > Pki-devel@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0108 Lightweight CAs: add issuer DN and serial to AuthorityData

[Fraser Tweedale]

Hi team,

Attached patch implements https://fedorahosted.org/pki/ticket/1618
(Lightweight CAs: include Issuer DN and Serial in AuthorityData).

If ACKed and we want to kick off builds of 10.3.0, please go ahead
and merge it, otherwise I'll merge it on Monday morning.

Cheers,
Fraser
From 913fced6709f30da2ac05e5367fcfc05e1698a75 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 13 May 2016 14:22:08 +1000
Subject: [PATCH] Lightweight CAs: add issuer DN and serial to AuthorityData

Add issuer DN and serial number to the AuthorityData object, as
read-only attributes.  Values are displayed in the CLI, when present
in the response data.

Fixes: https://fedorahosted.org/pki/ticket/1618
---
 .../dogtagpki/server/ca/rest/AuthorityService.java | 18 +++---
 .../netscape/certsrv/authority/AuthorityData.java  | 22 ++
 .../netscape/cmstools/authority/AuthorityCLI.java  | 14 +-
 .../cmstools/authority/AuthorityCreateCLI.java |  2 +-
 .../cmstools/authority/AuthorityDisableCLI.java|  2 +-
 .../cmstools/authority/AuthorityEnableCLI.java |  2 +-
 6 files changed, 53 insertions(+), 7 deletions(-)

diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java 
b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
index 
29b7f78434a433360f34e9f821e6166ed19c604c..199ebef1a30c0cb946731ba448320f33611b3605
 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
@@ -20,6 +20,7 @@ package org.dogtagpki.server.ca.rest;
 
 import java.io.ByteArrayOutputStream;
 import java.io.IOException;
+import java.math.BigInteger;
 import java.security.cert.CertificateEncodingException;
 import java.util.ArrayList;
 import java.util.LinkedHashMap;
@@ -270,14 +271,14 @@ public class AuthorityService extends PKIService 
implements AuthorityResource {
 public Response enableCA(String aidString) {
 return modifyCA(
 aidString,
-new AuthorityData(null, null, null, null, true, null, null));
+new AuthorityData(null, null, null, null, null, null, true, null, 
null));
 }
 
 @Override
 public Response disableCA(String aidString) {
 return modifyCA(
 aidString,
-new AuthorityData(null, null, null, null, false, null, null));
+new AuthorityData(null, null, null, null, null, null, false, null, 
null));
 }
 
 @Override
@@ -321,7 +322,16 @@ public class AuthorityService extends PKIService 
implements AuthorityResource {
 try {
 dn = ca.getX500Name().toLdapDNString();
 } catch (IOException e) {
-throw new PKIException("Error reading CA data: could not determine 
Issuer DN");
+throw new PKIException("Error reading CA data: could not determine 
subject DN");
+}
+
+String issuerDN;
+BigInteger serial;
+try {
+issuerDN = ca.getCACert().getIssuerDN().toString();
+serial = ca.getCACert().getSerialNumber();
+} catch (EBaseException e) {
+throw new PKIException("Error reading CA data: missing CA cert", 
e);
 }
 
 AuthorityID parentAID = ca.getAuthorityParentID();
@@ -330,6 +340,8 @@ public class AuthorityService extends PKIService implements 
AuthorityResource {
 dn,
 ca.getAuthorityID().toString(),
 parentAID != null ? parentAID.toString() : null,
+issuerDN,
+serial,
 ca.getAuthorityEnabled(),
 ca.getAuthorityDescription(),
 ca.isReady()
diff --git a/base/common/src/com/netscape/certsrv/authority/AuthorityData.java 
b/base/common/src/com/netscape/certsrv/authority/AuthorityData.java
index 
84679567eb527cbf9fedd21705a72ca9c1a34a93..7d74caf97366ab79e14f9afce94041e17cea341a
 100644
--- a/base/common/src/com/netscape/certsrv/authority/AuthorityData.java
+++ b/base/common/src/com/netscape/certsrv/authority/AuthorityData.java
@@ -21,6 +21,8 @@
  */
 package com.netscape.certsrv.authority;
 
+import java.math.BigInteger;
+
 import javax.xml.bind.JAXBContext;
 import javax.xml.bind.Marshaller;
 import javax.xml.bind.Unmarshaller;
@@ -70,6 +72,23 @@ public class AuthorityData {
 return parentID;
 }
 
+/* Read-only for existing CAs */
+@XmlAttribute
+protected String issuerDN;
+
+public String getIssuerDN() {
+return issuerDN;
+}
+
+
+/* Read-only attribute */
+@XmlAttribute
+protected BigInteger serial;
+
+public BigInteger getSerial() {
+return serial;
+}
+
 
 @XmlAttribute
 protected String dn;
@@ -124,12 +143,15 @@ public class AuthorityData {
 public AuthorityData(
 Boolean isHostAuthority,
 String dn, String id, String parentID,
+String issuerDN, BigInteger serial,

Re: [Pki-devel] [PATCH] 0103 Reject cert request if resultant subject DN is invalid

[Fraser Tweedale]

On Mon, May 09, 2016 at 01:19:50PM +1000, Fraser Tweedale wrote:
> The attached patch fixes https://fedorahosted.org/pki/ticket/2317.
> It will result in better error messages and help users to diagnose
> bad profile configurations (especially with IPA).
> 
> Thanks,
> Fraser
>
Acked by alee (thanks!); pushed to master
(54c18d85a778775c86bcddab4eee929719ac4d23)

> From ff7ff61c6cc97f695f3db2058bf3639014278299 Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Mon, 9 May 2016 12:57:32 +1000
> Subject: [PATCH] Reject cert request if resultant subject DN is invalid
> 
> An unparseable subject DN is ignored, causing NPE in subsequent
> processing becaues the subject DN was not set.  Throw
> ERejectException if the subject DN is invalid, to ensure that a
> useful response can be returned to the requestor.
> 
> Fixes: https://fedorahosted.org/pki/ticket/2317
> ---
>  .../com/netscape/certsrv/profile/ERejectException.java   |  8 
>  .../com/netscape/cms/profile/def/SubjectNameDefault.java | 16 
> ++--
>  2 files changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git 
> a/base/common/src/com/netscape/certsrv/profile/ERejectException.java 
> b/base/common/src/com/netscape/certsrv/profile/ERejectException.java
> index 
> cceeb12ab8354b05dec0d0212d7a0f04de9e6184..1ada1c4ebca50ed79a443e2e47b3251a7303ff37
>  100644
> --- a/base/common/src/com/netscape/certsrv/profile/ERejectException.java
> +++ b/base/common/src/com/netscape/certsrv/profile/ERejectException.java
> @@ -43,4 +43,12 @@ public class ERejectException extends EProfileException {
>  public ERejectException(String msg) {
>  super(msg);
>  }
> +
> +public ERejectException(String msg, Throwable cause) {
> +super(msg, cause);
> +}
> +
> +public ERejectException(Throwable cause) {
> +super(cause.getMessage(), cause);
> +}
>  }
> diff --git 
> a/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java 
> b/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java
> index 
> 31aee6dd6d9299438fb62493f61879f9a01dd9ed..629f4bcc10869518ff890a96fa6657565df00abe
>  100644
> --- a/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java
> +++ b/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java
> @@ -27,6 +27,7 @@ import netscape.security.x509.X509CertInfo;
>  import com.netscape.certsrv.apps.CMS;
>  import com.netscape.certsrv.base.IConfigStore;
>  import com.netscape.certsrv.profile.EProfileException;
> +import com.netscape.certsrv.profile.ERejectException;
>  import com.netscape.certsrv.profile.IProfile;
>  import com.netscape.certsrv.property.Descriptor;
>  import com.netscape.certsrv.property.EPropertyException;
> @@ -166,19 +167,14 @@ public class SubjectNameDefault extends EnrollDefault {
>  return;
>  try {
>  name = new X500Name(subjectName);
> -} catch (IOException e) {
> -// failed to build x500 name
> -CMS.debug("SubjectNameDefault: populate " + e.toString());
> -}
> -if (name == null) {
> -// failed to build x500 name
> -}
> -try {
>  info.set(X509CertInfo.SUBJECT,
>  new CertificateSubjectName(name));
>  } catch (Exception e) {
> -// failed to insert subject name
> -CMS.debug("SubjectNameDefault: populate " + e.toString());
> +CMS.debug("SubjectNameDefault: failed to populate: " + e);
> +throw new ERejectException(CMS.getUserMessage(
> +getLocale(request),
> +"CMS_PROFILE_INVALID_SUBJECT_NAME",
> +subjectName), e);
>  }
>  }
>  }
> -- 
> 2.5.5
> 

> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0106..0107 Add issuer DN to cert search params/result

[Fraser Tweedale]

On Tue, May 10, 2016 at 01:29:17PM -0400, Ade Lee wrote:
> ACK.
> 
Thanks Ade; pushed to master:

502db07ee8ef3e9f6b4bc2b030b29e8db639bc69 Include issuer DN in CertDataInfo
70d751e837cbf375ebd068169e591cd4a971f472 Support certificate search by issuer 
DN.

> Is the new search parameter added to the CLI (either python or Java?)
> or displayed in cert info results from the CLI?
> 
> How are these changes tested?
> 
I've enhanced `ipa cert-find' to use the new search param and
display the IssuerDN in the result.

I've filed #2324 for the Dogtag CLI part; targeting 10.3.2 but if
you feel it should be brought forward let's discuss.

https://fedorahosted.org/pki/ticket/2324

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0105 Add pki-server ca-cert-db-upgrade command

[Fraser Tweedale]

On Mon, May 09, 2016 at 04:06:46PM -0400, Ade Lee wrote:
> Isn't all this predicated on a schema change that adds the issuer as an
> optional field for the certRecord?
> 
The schema already exists but was unused.

> Ade
> 
> On Mon, 2016-05-09 at 17:15 +1000, Fraser Tweedale wrote:
> > Hi all,
> > 
> > The following patch adds a pki-server subcommand for updating
> > certificate records to add the issuerName attribute.
> > 
> > It is for #1667 (Database upgrade script to add issuerName attribute
> > to all cert entries).
> > 
> > Follow-up question: should I (and if so, how should I) also add an
> > upgrade scriptlet to perform the upgrade for Dogtag CA subsystem on
> > the host?  Is there a precedent for invoking pki-server (or
> > subroutines thereof) from pki-server-upgrade scriptlets?
> > 
> > Cheers,
> > Fraser
> > ___
> > Pki-devel mailing list
> > Pki-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0105 Add pki-server ca-cert-db-upgrade command

[Fraser Tweedale]

Hi all,

The following patch adds a pki-server subcommand for updating
certificate records to add the issuerName attribute.

It is for #1667 (Database upgrade script to add issuerName attribute
to all cert entries).

Follow-up question: should I (and if so, how should I) also add an
upgrade scriptlet to perform the upgrade for Dogtag CA subsystem on
the host?  Is there a precedent for invoking pki-server (or
subroutines thereof) from pki-server-upgrade scriptlets?

Cheers,
Fraser
From 9d994fe2c4e31c3d4212673f1dd3a0c8e84c40a3 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 9 May 2016 17:00:54 +1000
Subject: [PATCH] Add pki-server ca-cert-db-upgrade command

Add the 'ca-cert-db-upgrade' command to 'pki-server', which updates
certificate records to add the issuerName attribute where missing.

Part of: https://fedorahosted.org/pki/ticket/1667
---
 base/server/python/pki/server/cli/ca.py | 81 +
 1 file changed, 81 insertions(+)

diff --git a/base/server/python/pki/server/cli/ca.py 
b/base/server/python/pki/server/cli/ca.py
index 
dbf8239f4f548714beb0c68d7bca2c84f6c0fb74..b76a8f8834cc0c7d802b38b83d3a8ce99fbb0d84
 100644
--- a/base/server/python/pki/server/cli/ca.py
+++ b/base/server/python/pki/server/cli/ca.py
@@ -22,6 +22,8 @@ from __future__ import absolute_import
 from __future__ import print_function
 import getopt
 import io
+import ldap
+import nss.nss as nss
 import os
 import shutil
 import sys
@@ -48,6 +50,7 @@ class CACertCLI(pki.cli.CLI):
 
 self.add_module(CACertChainCLI())
 self.add_module(CACertRequestCLI())
+self.add_module(CACertDBUpgrade())
 
 
 class CACertChainCLI(pki.cli.CLI):
@@ -407,3 +410,81 @@ class CAClonePrepareCLI(pki.cli.CLI):
 
 finally:
 shutil.rmtree(tmpdir)
+
+
+class CACertDBUpgrade(pki.cli.CLI):
+def __init__(self):
+super(CACertDBUpgrade, self).__init__(
+'db-upgrade', 'Upgrade certificate records')
+
+def usage(self):
+print('Usage: pki-server ca-cert-db-upgrade [OPTIONS]')
+print()
+print('  -i, --instanceInstance ID (default: 
pki-tomcat).')
+print('  -v, --verbose  Run in verbose mode.')
+print('  --help Show help message.')
+print()
+
+def execute(self, args):
+try:
+opts, _ = getopt.gnu_getopt(
+args, 'i:v', ['instance=', 'verbose', 'help'])
+
+except getopt.GetoptError as e:
+print('ERROR: ' + str(e))
+self.usage()
+sys.exit(1)
+
+instance_name = 'pki-tomcat'
+
+for o, a in opts:
+if o in ('-i', '--instance'):
+instance_name = a
+
+elif o in ('-v', '--verbose'):
+self.set_verbose(True)
+
+elif o == '--help':
+self.print_help()
+sys.exit()
+
+else:
+print('ERROR: unknown option ' + o)
+self.usage()
+sys.exit(1)
+
+nss.nss_init_nodb()
+
+instance = pki.server.PKIInstance(instance_name)
+instance.load()
+
+subsystem = instance.get_subsystem('ca')
+base_dn = subsystem.config['internaldb.basedn']
+conn = subsystem.open_database()
+try:
+entries = conn.ldap.search_s(
+'ou=certificateRepository,ou=ca,%s' % base_dn,
+ldap.SCOPE_ONELEVEL,
+'(&(objectclass=certificateRecord)(!(issuerName=*)))',
+None)
+for entry in entries:
+self.__add_issuer(conn, entry)
+finally:
+conn.close()
+
+@staticmethod
+def __add_issuer(conn, entry):
+dn, attrs = entry
+attr_cert = attrs.get('userCertificate;binary')
+if not attr_cert:
+return  # shouldn't happen, but nothing we can do if it does
+
+cert = nss.Certificate(bytearray(attr_cert[0]))
+issuer_name = str(cert.issuer)
+
+try:
+conn.ldap.modify_s(dn, [(ldap.MOD_ADD, 'issuerName', issuer_name)])
+except ldap.LDAPError as e:
+print(
+'Failed to add issuerName to certificate {}: {}'
+.format(attrs.get('cn', [''])[0], e))
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0104 Lightweight CAs: fix bad import in key retriever script

[Fraser Tweedale]

Attached patch fixes a typo in the LWCA key retrieval Python helper
script.

Pushed to master (e75be5dcbce6aecf08ea7ff0b027222d0b6bbd4f) under
one-liner rule.

Cheers,
Fraser
From e75be5dcbce6aecf08ea7ff0b027222d0b6bbd4f Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 3 May 2016 16:24:16 +1000
Subject: [PATCH] Lightweight CAs: fix bad import in key retriever script

Part of: https://fedorahosted.org/pki/ticket/1625
---
 base/server/libexec/pki-ipa-retrieve-key | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/base/server/libexec/pki-ipa-retrieve-key 
b/base/server/libexec/pki-ipa-retrieve-key
index 
8098e534e54670c3a5d8776fe934f1f13037b373..301f818b859577ef1a861bc7a855b6103a6f3af8
 100755
--- a/base/server/libexec/pki-ipa-retrieve-key
+++ b/base/server/libexec/pki-ipa-retrieve-key
@@ -9,7 +9,7 @@ import sys
 
 from jwcrypto.common import json_decode
 
-from ipalib.constants import constants
+from ipalib import constants
 from ipaplatform.paths import paths
 from ipapython.secrets.client import CustodiaClient
 
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0103 Reject cert request if resultant subject DN is invalid

[Fraser Tweedale]

The attached patch fixes https://fedorahosted.org/pki/ticket/2317.
It will result in better error messages and help users to diagnose
bad profile configurations (especially with IPA).

Thanks,
Fraser
From ff7ff61c6cc97f695f3db2058bf3639014278299 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 9 May 2016 12:57:32 +1000
Subject: [PATCH] Reject cert request if resultant subject DN is invalid

An unparseable subject DN is ignored, causing NPE in subsequent
processing becaues the subject DN was not set.  Throw
ERejectException if the subject DN is invalid, to ensure that a
useful response can be returned to the requestor.

Fixes: https://fedorahosted.org/pki/ticket/2317
---
 .../com/netscape/certsrv/profile/ERejectException.java   |  8 
 .../com/netscape/cms/profile/def/SubjectNameDefault.java | 16 ++--
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/base/common/src/com/netscape/certsrv/profile/ERejectException.java 
b/base/common/src/com/netscape/certsrv/profile/ERejectException.java
index 
cceeb12ab8354b05dec0d0212d7a0f04de9e6184..1ada1c4ebca50ed79a443e2e47b3251a7303ff37
 100644
--- a/base/common/src/com/netscape/certsrv/profile/ERejectException.java
+++ b/base/common/src/com/netscape/certsrv/profile/ERejectException.java
@@ -43,4 +43,12 @@ public class ERejectException extends EProfileException {
 public ERejectException(String msg) {
 super(msg);
 }
+
+public ERejectException(String msg, Throwable cause) {
+super(msg, cause);
+}
+
+public ERejectException(Throwable cause) {
+super(cause.getMessage(), cause);
+}
 }
diff --git 
a/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java 
b/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java
index 
31aee6dd6d9299438fb62493f61879f9a01dd9ed..629f4bcc10869518ff890a96fa6657565df00abe
 100644
--- a/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java
+++ b/base/server/cms/src/com/netscape/cms/profile/def/SubjectNameDefault.java
@@ -27,6 +27,7 @@ import netscape.security.x509.X509CertInfo;
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.base.IConfigStore;
 import com.netscape.certsrv.profile.EProfileException;
+import com.netscape.certsrv.profile.ERejectException;
 import com.netscape.certsrv.profile.IProfile;
 import com.netscape.certsrv.property.Descriptor;
 import com.netscape.certsrv.property.EPropertyException;
@@ -166,19 +167,14 @@ public class SubjectNameDefault extends EnrollDefault {
 return;
 try {
 name = new X500Name(subjectName);
-} catch (IOException e) {
-// failed to build x500 name
-CMS.debug("SubjectNameDefault: populate " + e.toString());
-}
-if (name == null) {
-// failed to build x500 name
-}
-try {
 info.set(X509CertInfo.SUBJECT,
 new CertificateSubjectName(name));
 } catch (Exception e) {
-// failed to insert subject name
-CMS.debug("SubjectNameDefault: populate " + e.toString());
+CMS.debug("SubjectNameDefault: failed to populate: " + e);
+throw new ERejectException(CMS.getUserMessage(
+getLocale(request),
+"CMS_PROFILE_INVALID_SUBJECT_NAME",
+subjectName), e);
 }
 }
 }
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0101 Lightweight CAs: accept "host-authority" as valid parent

[Fraser Tweedale]

On Fri, May 06, 2016 at 09:31:07PM -0500, Endi Sukma Dewata wrote:
> On 5/5/2016 1:54 AM, Fraser Tweedale wrote:
> >The attached patch allows "host-authority" to be used as valid
> >reference to the host authority when creating a LWCA.  It makes life
> >easier for me one the FreeIPA side :)
> >
> >Cheers,
> >Fraser
> 
> ACK. Just one thing, could you chain the original exception to
> BadRequestException?
> 
Thanks; made the change and pushed to master
(bdd9ceca09d570f9ac976bed6bc980e6527d92b5)

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0102 Lightweight CAs: allow specifying authority via ProfileSubmitServlet

[Fraser Tweedale]

Attached patch does what it says on the tin ;)

Cheers, and have a good weekend y'all.
Fraser
From cabae0a050fb752b290ece28d5dac927f01b3c01 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 6 May 2016 16:03:57 +1000
Subject: [PATCH] Lightweight CAs: allow specifying authority via
 ProfileSubmitServlet

Lightweight CAs were supported in REST-based request submission, but
not via ProfileSubmitServlet, however, FreeIPA currently uses
ProfileSubmitServlet, so make it possible to use lightweight CAs.

Part of: https://fedorahosted.org/pki/ticket/1625
---
 .../cms/servlet/profile/ProfileSubmitServlet.java| 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git 
a/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileSubmitServlet.java
 
b/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileSubmitServlet.java
index 
f7b08ece99e11f1e1633e0d67fb4646a27417d80..4096d0aecfc1eb71481d446a5809631516bc5d27
 100644
--- 
a/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileSubmitServlet.java
+++ 
b/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileSubmitServlet.java
@@ -33,6 +33,9 @@ import com.netscape.certsrv.authentication.EAuthException;
 import com.netscape.certsrv.authorization.EAuthzException;
 import com.netscape.certsrv.base.BadRequestDataException;
 import com.netscape.certsrv.base.EBaseException;
+import com.netscape.certsrv.ca.AuthorityID;
+import com.netscape.certsrv.ca.CANotFoundException;
+import com.netscape.certsrv.ca.ICertificateAuthority;
 import com.netscape.certsrv.cert.CertEnrollmentRequest;
 import com.netscape.certsrv.profile.EProfileException;
 import com.netscape.certsrv.profile.IEnrollProfile;
@@ -220,8 +223,23 @@ public class ProfileSubmitServlet extends ProfileServlet {
 CMSTemplate.escapeJavaScriptStringHTML(profileId)));
 }
 
+String aidString = request.getParameter("authorityId");
+AuthorityID aid = null;
+if (aidString != null && !aidString.isEmpty()) {
+try {
+aid = new AuthorityID(aidString);
+} catch (IllegalArgumentException e) {
+throw new BadRequestDataException("invalid AuthorityID: " + 
aidString);
+}
+ICertificateAuthority ca = (ICertificateAuthority)
+CMS.getSubsystem(CMS.SUBSYSTEM_CA);
+ca = ca.getCA(aid);
+if (ca == null)
+throw new CANotFoundException("CA not found: " + aidString);
+}
+
 CertEnrollmentRequest data = 
CertEnrollmentRequestFactory.create(cmsReq, profile, locale);
-return processor.processEnrollment(data, request, null, null);
+return processor.processEnrollment(data, request, aid, null);
 }
 
 public HashMap<String, Object> processRenewal(CMSRequest cmsReq) throws 
EBaseException {
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [DESIGN] Lightweight CA renewal

[Fraser Tweedale]

Hullo all,

FreeIPA Lightweight CAs implementation is progressing well.  The
remaining big unknown in the design is how to do renewal.  I have
put my ideas into the design page[1] and would appreciate any and
all feedback!

[1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal

Some brief commentary on the options:

I intend to implement approach (1) as a baseline.  Apart from
implementing machinery in Dogtag to actually perform the renewal -
which is required for all the approaches - it's not much work and
gets us over the "lightweight CAs can be renewed easily" line, even
if it is a manual process.

For automatic renewal, I am leaning towards approach (2).  Dogtag
owns the lightweight CAs so I think it makes sense to give Dogtag
the ability to renew them automatically (if configured to do so),
without relying on external tools i.e. Certmonger.  But as you will
see from the outlines, each approach has its upside and downside.

Cheers,
Fraser

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] 0101 Lightweight CAs: accept "host-authority" as valid parent

[Fraser Tweedale]

The attached patch allows "host-authority" to be used as valid
reference to the host authority when creating a LWCA.  It makes life
easier for me one the FreeIPA side :)

Cheers,
Fraser
From f1860c2315f13d458a33521f78327b8c3a84a246 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 5 May 2016 16:33:52 +1000
Subject: [PATCH] Lightweight CAs: accept "host-authority" as valid parent

Accept the string "host-authority" as a valid reference to the host
authority when creating a sub-CA.  This is a convenience for users,
and for systems that do not know (and do not want to look up) the ID
of the host authority.

Part of: https://fedorahosted.org/pki/ticket/1625
---
 .../src/org/dogtagpki/server/ca/rest/AuthorityService.java   | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java 
b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
index 
582248d4cf284fb759c5c483810da87683862c1f..29e9a470f59b725ffbfd3cc3079d736d2b7b906a
 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java
@@ -179,10 +179,14 @@ public class AuthorityService extends PKIService 
implements AuthorityResource {
 public Response createCA(AuthorityData data) {
 String parentAIDString = data.getParentID();
 AuthorityID parentAID = null;
-try {
-parentAID = new AuthorityID(parentAIDString);
-} catch (IllegalArgumentException e) {
-throw new BadRequestException("Bad Authority ID: " + 
parentAIDString);
+if (AuthorityResource.HOST_AUTHORITY.equals(parentAIDString)) {
+parentAID = hostCA.getAuthorityID();
+} else {
+try {
+parentAID = new AuthorityID(parentAIDString);
+} catch (IllegalArgumentException e) {
+throw new BadRequestException("Bad Authority ID: " + 
parentAIDString);
+}
 }
 
 PKIPrincipal principal =
-- 
2.5.5

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel