Hi, Thanks a lot for your valuable feedbacks. Please find the current implementation details as follows.
- Certificate validators can be configured in <IS_HOME>/repository/conf/security/certificate-validators.xml as follows with configured priorities. This will be added to tenant registry in /_system/governance/repository/security/certificate/validator on tenant activation. There will be separate resources for each validator with properties as name, enable and priority. <Validators xmlns=" http://wso2.org/projects/carbon/certificate-validators.xml";> <Validator name="org.wso2.carbon.identity.x509Certificate.validation.crl.CRLValidator" displayName="CRLValidator" enable="true"> <Priority>1</Priority> </Validator> <Validator name="org.wso2.carbon.identity.x509Certificate.validation.ocsp.OCSPValidator" displayName="OCSPValidator" enable="false"> <Priority>2</Priority> </Validator> </Validators> - An OSGI service which will be exposed to verify the certification revocation. In there, all the validator configs will be loaded from the registry and based on the enability and priority, corresponding validators will get invoked. - CRL Validator has been implemented as follows. - Extract the certificate extension value for CRL Distribution points. - Retrieve CRL URLs from the CRL Distribution points. - Download X509CRL from the CRL URLs (If one fails check with the other) or retrieve from the cache and check the revocation status. - Client certificate will be validated in X509CertificateAuthenticator when processing authentication response. If the given X509 Certificate is revoked by its Issuer, will be throwing an exception. In there, when a certificate has been revoked, if already a user certificate exists which matches with the cert in request, will be deleting the certificate from user claims. Thanks and Regards On Tue, Dec 19, 2017 at 7:32 AM, Johann Nallathamby <joh...@wso2.com> wrote: > Hi Indunil, > > On Fri, Dec 15, 2017 at 7:32 AM, Indunil Upeksha Rathnayake < > indu...@wso2.com> wrote: > >> Hi, >> >> At the time, a certificate is issued by a Certificate Authority (CA), it >> is expected to be in use for its entire validity period. However, various >> circumstances may cause a certificate to become invalid, prior to the >> expiration of the validity period (Ex: compromise or suspected compromise >> of the corresponding private key). Under such circumstances, the issuing CA >> needs to revoke the certificate before their scheduled expiration date and >> should no longer be trusted. >> >> CRL(Certificate Revocation List) and OCSP (Online Certificate Status >> Protocol) are two protocols used to check whether a given X509 Certificate >> is revoked by its Issuer. >> >> 1. *Certificate Revocation List (CRL) :* a list of digital >> certificates that have been revoked by the issuing CA >> 2. *Online Certificate Status Protocol (OCSP) : *an Internet protocol >> used for obtaining the revocation status of an X.509 digital certificate >> using the certificate serial number >> >> >> Proposed implementation is to include certificate validation with CRL and >> OCSP, in X509 authenticator which is for client X.509 certificate >> authentication. So that at the verification phase of SSL handshake, >> OCSP/CRL certificate verification process, is used to contact the relevant >> Certificate Authority(CA) to verify the validity of the given certificate. >> If the response says that the certificate is revoked, it means that the >> certificate is no longer trusted by the CA, in which case the SSL >> connection to the peer is terminated. >> >> >> >> Please find the following architectural considerations for the proposed >> implementation. >> >> *APIs or Services for CRL/OCSP Validation :* >> Certificate Revocation Verification should be exposed as an OSGI service >> in a matter where we can include validation methods additionally via >> extensions. >> >> *Get CRL and OCSP URLs :* >> >> - When a CA signs a certificate, it will normally encode the CRL and >> OCSP location/s into the certificate using "CRL Distribution Point" and >> "Authority Information Access" extensions respectively. >> >> >> - If CRL and OCSP location/s are not specified in the certificate or >> administrator wants to override that with a predefined locations in the >> server, we are planning to maintain a list of trusted CAs with CRL and >> OCSP >> location/s in registry. >> >> *Registry Structure* : Two registry resources as follows and comma >> separated CRL/OCSP URls as property values mapping with the CA issuer name. >> /_system/config/certificate/crl >> /_system/config/certificate/ocsp >> >> *Trusted CA List *: Consider the issuers in the default >> client-truststore of WSO2 products. >> > > Here I think we need to have a separate trust store for x509 user > authentication. The client-truststore.jks is mainly used TLS trust. Using > the same for X509 also will be pointless, because the whole purpose of > having this trust store is to limit certificates we trust. If we have only > one trust store for both TLS, and X509 user authentication we can't have > separate set of CAs for these. > > Regards, > Johann. > > >> *Caching Layer :* >> >> - Downloaded CRL from CRL URL or OCSP response from OCSP URL will be >> cached. >> >> >> - CA provides a CRL that is valid for a limited amount of time and >> specifies the lifetime validity of the CRL in the "Next Update" CRL field. >> >> This field indicates the date by which the next CRL will be issued. As >> mentioned in [1], the next CRL could be issued before the indicated date, >> but it will not be issued any later than the indicated date. >> >> So we should consider this property and validated the returned CRL from >> cache, since a certificate in the CRL can be temporary invalidated (Hold) >> rather a irreversibly revoked certificate and use of an outdated CRL >> creates security exposures. >> >> *Preference for CRL and OCSP :* >> >> - Able to disable one or both methods and to define preference >> between CRL and OCSP - this will be through file based configuration >> - If both methods has enabled, verified with OCSP first, followed by >> CRL >> - By default (if not configured), verified with OCSP >> >> *Other Considerations :* >> >> - Validate CRL returned from the CRL URL >> - CRL should signed by the issuer, so validate the issuer domain >> name. >> - Validate the signature of CRL with the issuer public certificate. >> - Validate the CRL "next update" date field for outdated CRLs. >> >> >> Appreciate your suggestions/comments. >> >> [1] https://tools.ietf.org/html/rfc5280 >> [2] https://tools.ietf.org/html/rfc6960 >> >> Thanks and Regards >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email indu...@wso2.com >> Mobile 0772182255 >> > > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email indu...@wso2.com Mobile 0772182255
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
