Hi Maheshika, Can you please create a new git repository with the name " identity-x509-revocation" under wso2-extensions, for moving this feature implementation.
Thanks and Regards On Wed, Jan 17, 2018 at 11:20 AM, Indunil Upeksha Rathnayake < [email protected]> wrote: > Hi, > > Please find the following considerations on proceeding with the CRL/OCSP > certificate validation. Appreciate your ideas and comments on this. > > *Store root CA and intermediate CA certificates in registry* > > - As per the current implementation, trust stores which are having CA > certificates that should be used for CRL and OCSP validation, can be > configured file based as follows. > > <?xml version="1.0" encoding="ISO-8859-1"?> > > <CertificateValidation xmlns="http://wso2.org/ > projects/carbon/certificate-validation.xml > <http://wso2.org/projects/carbon/certificate-validation.xml>"> > > ……. > > <TrustStores> > > *<TrustStore truststoreFile="/path/to/truststore.jks" > truststorePass="cacertspassword" type="JKS"/>* > > </TrustStores> > > </CertificateValidation> > > > - In server start up and in tenant initial activation, all the > certificates in the trust stores will added to the registry. > > Registry path : > *repository/security/certificate/certificate-authorities/<Normalized > Issuer DN>/<Certificate Serial Num>* > > Normalized Issuer DN : UTF-8 URL encoded issuer DN while replacing the "%" > with ":" in the URL encoded value, in order to support the Illegal > characters for registry resource path (Check mail in [1]). > Certificate Serial Num : Positive integer assigned by the CA to each > certificate which is unique for each certificate issued by a given CA > (i.e., the issuer name and serial number identify a unique certificate) > > Registry Content : *X509Certificate CA Certificate* > Registry Properties : > *crl - comma separated CRL URLs* > *ocsp - comma separated OCSP URLs* > > - There can be certificates of Intermediate CAs and root CAs in the > trust store (An intermediate CA is an entity that can sign certificates on > behalf of the root CA. The root CA signs the intermediate certificate, > forming a chain of trust). All those intermediate and root certificates > will be added into the registry considering following scenarios. > > > 1. Intermediate CAs have their own CRL and OCSP URLs > > Revocation of certificate is not propagated across the CA tree. Each CA > (root and intermediate) is responsible of the publication of the CRL > containing the list of only the revoked certificates that were issued by > that CA and OCSP response for only the certificates that were issued by > that CA. > > 2. Observer intermediate CA certificates in the chain > of trust > For full-chain CRL/OCSP validation as mention in below, need to have > access to intermediate CA certificates in the chain of trust to retrieve > the CRL and OCSP Urls > > > *Need of CA and intermediate CA Certificates for CRL/OCSP validation* > > - CRL Validation : > - If the CA certificate available in the registry which issued the > client certificate, retrieve the CRL URLs from the CA cert. If not use > the > URLs in the client certificate. > - In order to validate intermediate CAs when Full-chain CRL/OCSP > validation enabled, CRL URls will be extracted from corresponding root > CA. > > > - OCSP Validation : > - For OCSP validation, CA certificate which issued the client > certificate should be available in the registry. Otherwise consider as a > unsuccessful validation. > - In order to validate intermediate CAs when Full-chain CRL/OCSP > validation enabled, OCSP URLs will be extracted from corresponding root > CA. > > > > *Configure Full-chain CRL/OCSP Validation * > > <?xml version="1.0" encoding="ISO-8859-1"?> > > <CertificateValidation xmlns="http://wso2.org/projects/carbon/certificate- > validation.xml"> > > <Validators> > > <Validator name="org.wso2.carbon.identity.x509Certificate. > validation.validator.CRLValidator" displayName="CRLValidator" > enable="false"> > > <Parameter name="priority">1</Parameter> > > *<Parameter name="fullChainValidation">true</Parameter>* > > > </Validator> > > <Validator name="org.wso2.carbon.identity.x509Certificate. > validation.validator.OCSPValidator" displayName="OCSPValidator" > enable="true"> > > <Parameter name="priority">2</Parameter> > > <Parameter name="fullChainValidation">true</Parameter> > > </Validator> > > </Validators> > > </CertificateValidation> > > - *Full-chain CRL/OCSP validation disabled:* validate the client > certificate with the CRL/OCSP URLs of the issuer CA > > > - *Full-chain CRL/OCSP validation enabled*: validate with the CRL/OCSP > of every intermediate certificate within the chain of trust for the client, > except for the root CA certificate. > > Ex: Root CA (root CA CRL) Cert ==> Intermediate CA Cert(inter CA CRL) ==> > Client Cert > The intermediate CA CRL is used to verify whether the client certificate > is valid. The root CA CRL is used to verify whether Intermediate CA Cert is > valid. > > If Full-chain CRL/OCSP checking enabled, If the intermediate certificates > are not available in the registry or, if a CRL is not available in any of > the intermediate CA in the chain of trust, or the certificate is listed as > revoked in any of those CRLs, the client request is denied. > > > *Validate when both CRL and OCSP methods are enabled* > If the highest priority method returns a successful validation or status > is not "Unknown", the second method is not attempted. Method with second > and further priority is used as a backup. > > > *Validate when multiple CA certificates * > If there are CA certs more than one with same subject DN matches to issuer > DN in client certificate, will be validating through one certificate. If > validation is not successful or status is "Unknown", check with the > CRL/OCSP URLs in the other CA certificate. > > > *Validate when multiple CRL/OCSP URLs in a CA certificate/client > certificate* > Check with one URL and if only the validation is not successful or status > is "Unknown", check with the other CRL/OCSP URLs in the certificate. > > > *Number of Retries* > Configure the maximum number of times which we can attempt to download the > CRL file or get OCSP response from the specified path before giving up. > > <?xml version="1.0" encoding="ISO-8859-1"?> > > <CertificateValidation xmlns="http://wso2.org/projects/carbon/certificate- > validation.xml"> > > <Validators> > > <Validator name="org.wso2.carbon.identity.x509Certificate. > validation.validator.CRLValidator" displayName="CRLValidator" > enable="true"> > <Parameter name="priority">1</Parameter> > > *<Parameter name="retryCount">2</Parameter>* > > > </Validator> > > </Validators> > > </CertificateValidation> > > > > [1] Mail Thread : "[Dev] Illegal Characters for Registry Resource Path" > > Thanks and Regards > > > On Wed, Jan 10, 2018 at 12:41 PM, Indunil Upeksha Rathnayake < > [email protected]> wrote: > >> Hi, >> >> >> On Wed, Jan 10, 2018 at 12:24 PM, Indunil Upeksha Rathnayake < >> [email protected]> wrote: >> >>> Hi, >>> >>> On Wed, Jan 3, 2018 at 6:05 PM, Asela Pathberiya <[email protected]> wrote: >>> >>>> >>>> >>>> On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake < >>>>> [email protected]> 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. >>>>>> >>>>> >>>>> +1 There are two angels here, >>>>> >>>>> 1. This service should not be coupled with the X509 Authenticator, >>>>> any other component that have the same requirement should be able to >>>>> consume this service without an issue. >>>>> 2. Ability to plug different implementations for validations. >>>>> >>>>> >>>> Can't this be an extension to the tomcat transport & http client >>>> implementation? Then it may cover all the TLS transports >>>> >>> >> You are referring enabling OCSP/CRL validation in tomcat connector level? >> If so, I think we need to do the validation through a valve, but need to >> check whether a valve can be enabled tomcat connector wise. WDYT? >> Since, we are exposing the OCSP/CRL validation in an OSGI service, it can >> be engaged from any component. >> >> >>> >>> >>>> https://issues.apache.org/jira/browse/HTTPCLIENT-483 >>>> https://stackoverflow.com/questions/20286145/validate-client >>>> -certificate-against-certificate-revocation-list-in-tomcat-7 >>>> >>>> Did we check the pass-through transport implementation of our ESB >>>> regarding this ? >>>> >>> >> Yes checked the pass-through transport implementation for this. >> >> >>> >>> >>>> >>>> Thanks, >>>> Asela. >>>> >>>> >>>>> >>>>>> *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. >>>>>> >>>>>> *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. >>>>>> >>>>> >>>>> AFAIU, we could have ended up having invalid entries in cache, if we >>>>> rely on 'Next Update' field. So how exactly are we going to cache CRL and >>>>> OSCP? >>>>> >>>>>> >>>>>> *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 >>>>>> >>>>>> >>>>> At least we should have extensible mechanism to override these to >>>>> certificate level. ie. configuration levels would be, server -> tenant -> >>>>> sp -> certificate. >>>>> >>>>> Thanks, >>>>> >>>>>> >>>>>> - >>>>>> >>>>>> *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 [email protected] >>>>>> Mobile 0772182255 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> *Darshana Gunawardana*Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> >>>>> *E-mail: [email protected] <[email protected]>* >>>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . >>>>> Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Asela >>>> >>>> ATL >>>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>>> +358 449 228 979 >>>> >>>> http://soasecurity.org/ >>>> http://xacmlinfo.org/ >>>> >>> >>> >>> >>> -- >>> Indunil Upeksha Rathnayake >>> Software Engineer | WSO2 Inc >>> Email [email protected] >>> Mobile 0772182255 >>> >> >> >> >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email [email protected] >> Mobile 0772182255 >> > > > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email [email protected] > Mobile 0772182255 > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email [email protected] Mobile 0772182255
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
