CA's included that do not support PIV/CAC/PIV-I #91
Comments
|
I wanted to add some more info after looking through the CA certificates that are in the config: The config directory appears to contain a lot of certificates that are part of the Federal PKI. Within the FPKI Playbook there is an open issue to maintain a list of certificates (and CRLs, OCSP, AIA/SIA, etc): I've been working on the same thing, to provide an open source method of tracking certificates (and associated metadata) for the Production Federal PKI, as well as the CITE environment: I.e., For all PEM CA certs that are part of production FPKI:
For all PEM CA certs that are part of CITE:
|
|
Thanks for the feedback! I'm comfortable with the team removing the certs that you identified as not being used to issue PIV certs. There's an item in the roadmap/backlog to restrict allowed certificates to containing certain policy OIDs. This will help in situations where a particular issuing cert is used for more than PIV/CAC certs. The general approach I'd feel comfortable with once the policy OID restrictions are added is to keep certificates when in doubt, but be free to remove them if an authority from the component issuing the certificate says that the certificate is not used for PIV/CAC certs. |
|
Howdy! Will Fiscal CA 3 and 4 be removed soon? Also, any luck on processing LOA via policy object identifiers? |
|
The Senate PIV-I issuing CA appears to not have any corresponding certificate policies that this implementation is willing to accept. CertificatePolicies assertedAsserted OID ARC within this repohttps://github.com/18F/identity-pki/search?q=2.16.840.1.113733.1.7.23.3.1 |
|
As a federal employee, when I try to authenticate with my PIV credential, I receive a certificate selection dialog that suggest the login.gov mTLS servers to not serve a hint list. I.e., even self signed certificates in my CNG store are an option.
As a Treasury employee authenticating to Treasury SSO via https://piv.treasury.gov/, I see a filtered list in the certificate selection dialog:
As an entity with a PIV/PIV-I/CAC credential accessing https://iiq.fiscal.treasury.gov/ via a PIV credential, I see similar results to Treasury SSO (though All FPKI is honored, and mTLS leverages TLS 1.3):
|
|
Follow-up on this issue, we have an authoritative list of PIV and PIV-I issuers used in the federal government, including all branches. If judicial and legislative branches are customers/users of login.gov, the allowed authenticator's list should include PIV-I. https://playbooks.idmanagement.gov/fpki/pivcas-and-agencies/ |
|
If I understand how this works (and I probably do not), the config/application.yml builds the certs using a static root list and required policies. The allowed policies already include medium hardware from Entrust and Identrust, but not PIV-I. It may be as simple as including the PIV-I policies in this required policies list. Referencing this page to map OIDS
Here is a first pass at improving the list of required policies (if this is how it the script works) @grandamp, did I miss any or should it also include any federally-issued hardware certificate and any PIV-I? What list do you use?
Consider Removing
|
|
Thank you for following up on this and the links to the references! I can try to explain the "Required Policies" a bit. My understanding is we currently require that any of the certs in the chain have one of the listed policies, which is why the Senate PIV-I certificate mentioned previously is usable. I will discuss internally a bit and review the links to add/remove OIDs as needed! Regarding the initial issue with the certificates that do not support PIV/CAC/PIV-I, those are now removed (though it was due to expiration). |
|
Since this issue is still open, have you observed the following non-PIV certificate? |
Looking at the config, there are some CA's included that do not support PIV/CAC/PIV-I:
i.e., All CA's with this Subject and Issuer:
Suggest removing the following CA certificates:
Fiscal Service CA #1
Fiscal Service CA #2
Fiscal Service CA #3
Fiscal Service CA #4
The text was updated successfully, but these errors were encountered: