hi Azeez Please confirm.
On Mon, Feb 12, 2018 at 10:26 AM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > 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 < > indu...@wso2.com> 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/project >> s/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/project >> s/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/project >> s/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 < >> indu...@wso2.com> wrote: >> >>> Hi, >>> >>> >>> On Wed, Jan 10, 2018 at 12:24 PM, Indunil Upeksha Rathnayake < >>> indu...@wso2.com> wrote: >>> >>>> Hi, >>>> >>>> On Wed, Jan 3, 2018 at 6:05 PM, Asela Pathberiya <as...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana < >>>>> darsh...@wso2.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 15, 2017 at 9:02 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. >>>>>>> >>>>>> >>>>>> +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 indu...@wso2.com >>>>>>> Mobile 0772182255 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> >>>>>> *Darshana Gunawardana*Technical Lead >>>>>> WSO2 Inc.; http://wso2.com >>>>>> >>>>>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>* >>>>>> *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 indu...@wso2.com >>>> Mobile 0772182255 >>>> >>> >>> >>> >>> -- >>> Indunil Upeksha Rathnayake >>> Software Engineer | WSO2 Inc >>> Email indu...@wso2.com >>> Mobile 0772182255 >>> >> >> >> >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email indu...@wso2.com >> Mobile 0772182255 >> > > > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email indu...@wso2.com > Mobile 0772182255 > -- Thanks & Best Regards, Maheshika Goonetilleke Senior Engineering Process Coordinator *WSO2 Inc* *email : mahesh...@wso2.com <mahesh...@wso2.com>* *mobile : +94 773 596707* *www: :http://wso2.com <http://wso2.com/>*lean . enterprise . middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
