Re: [Pki-devel] SSO

[Alex Scheel]

Sure, but what you'd have to do is similar in both cases:

 - Extend Dogtag's user model to include external authentication sources,
 - Allow Dogtag to lookup users based on Tomcat's auth handler.

In both GSS-API and OIDC, you need a way of mapping users to Dogtag's ACL
model, that doesn't currently exist for anything but Dogtag's internal users
and cert-auth capability.

- A

- Original Message -
> From: "Pascal Jakobi" 
> To: "Alex Scheel" 
> Sent: Thursday, July 2, 2020 11:39:32 AM
> Subject: Re: [Pki-devel] SSO
> 
> GSS support was a good idea before.
> 
> Now the real solution for web SSO is OIDC, I believe.
> 
> Le 02/07/2020 à 17:35, Alex Scheel a écrit :
> > 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.
> >
> >
> >
> > 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
> --
> *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

[Alex Scheel]

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.



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] CVEs in RHEL 7

[Alex Scheel]

Hey Amy,

Matt asked about our CVE response in RHEL 7.

As far as I know, we have the following CVEs (grouped below by
category).

Third Party:

 - CVE-2016-10735 (bootstrap) XSS Moderate
 - CVE-2018-14040 (bootstrap) XSS Moderate
 - CVE-2018-14042 (bootstrap) XSS Moderate
 - CVE-2019-8331 (bootstrap) XSS Moderate
 - CVE-2019-11358 (js-jquery) XSS/DoS Moderate
 - CVE-2015-9251 (js-jquery) XSS Moderate

These I'd recommend CLOSE->WONTFIX ; all are more work than they are worth
in the last RHEL 7 release.  It requires updating our dependencies and then
re-testing the entire web UIs. They're not stored XSS and I'm not sure
there's actually a viable way to exploit these in a RHCS environment. They're
mostly about a way for a third-party site to inject content run in a trusted
execution environment on a RHCS instance. That requires substantial theme
customization (and/or changes to the server-side code to load elements from
a third-party site) to enable and is well outside the scope of our support.
Additionally, all operations are audited in our customer's deployments, so
tracking down _who_ did this would be possible. I think it is safe to close
these in RHEL 7. 


I'd like to fix all of these in RHEL 8 eventually, but again, that requires
significant work and validation that we didn't break anything. All of these
third-party dependencies (Bootstrap, jquery, ...) are severely out of date,
and updating them is likely to break stuff. Doable, but not fun. :-)



First Party

 - CVE-2019-10178 (TPS UI) XSS Moderate
 - CVE-2019-10179 (KRA UI) XSS Moderate
 - CVE-2019-10180 (TPS UI) XSS Low
 - CVE-2020-1696 (TPS UI) XSS Moderate
 - CVE-2020-1721 (KRA UI) XSS Low
 - CVE-2019-10146 (CA UI) XSS Low

We don't have fixes for these in RHEL 8 yet. I think we should fix them in
RHEL 8 and close them in RHEL 7. Testing these is significantly easier, and
backporting would be easier. In all cases, I believe our QE team was the
reporter. 

Someone familiar with this UI should probably fix them (Endi? Jack? Christina?
I'm not sure). I think the changes should probably be server-side sanitation
coupled with better front-end injection to prevent XSS. I can review, but I
wouldn't know where to start to fix them.

I wouldn't consider backporting them until someone (Amy? the customer?) is
concerned and we've fixed them.

However, my same argument about third-party ones stands here too: access is
audited so it should be easy to find out who did this. 



My 2c., but I think they should be RHEL 8.3 candidates and not RHEL 7.9.

If fixes are required/requested by the customer, we can always add them in a
batch update.


Thanks,

- Alex

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

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

[Alex Scheel]

Hi Sarath,


I think a X509 Certificate with "digital signature" key usage would
suffice based on what I can tell:

 - https://helpx.adobe.com/acrobat/using/certificate-based-signatures.html
 - https://tools.ietf.org/html/rfc5280#section-4.2.1.3
 - 
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html/administration_guide/standard_x.509_v3_certificate_extensions

Per a digicert article on the subject, you might want timestamping as
an extended key usage as well:

 - https://www.digicert.com/document-signing/how-to-sign-a-pdf.htm
 - 
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html/administration_guide/Standard_X.509_v3_Certificate_Extensions#Discussion-PKIX_Extended_Key_Usage_Extension_Uses

Details are kinda sparse about what else you'd need, or if those
are sufficient. You might try reading Section 12.7.4.5 "Signature
Fields", Section 12.8 "Digital Signatures", and in particular,
Section 12.8.3.3 "PKCS#7 Signatures as used in ISO 32000" of the
PDF 1.7 specification for more information:

 - https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf


You'd probably want to create a certificate profile with this
information at any rate:

 - 
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html/administration_guide/certificate_profiles


Hope that helps,

- Alex

- Original Message -
> From: "Sharath" 
> To: "Fraser Tweedale" 
> Cc: pki-us...@redhat.com, pki-devel@redhat.com
> Sent: Monday, November 4, 2019 2:09:54 AM
> Subject: Re: [Pki-users] [Pki-devel] How to generate the certificate in pkcs 
> #12 format using Dogtag PKI
> 
> HI Fraser,
> 
> I have use case like need to certify the PDF document with "handwritten
> user signature with associated certificate and it should be validate
> with the password" ??
> 
> How can we achieve this using Dogtag PKI??
> 
> Thanks,
> 
> Sharath
> 
> On 04/11/19 9:59 AM, Fraser Tweedale wrote:
> > 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-users mailing list
> pki-us...@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-users
> 

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