Hi Indunil Created the repo, please check.
On Wed, Feb 14, 2018 at 2:01 PM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > Hi Maheshika, > > Please use following as the parent group ID. > org.wso2.carbon.extension.identity.x509certificate.revocation > > Thanks and Regards > > On Wed, Feb 14, 2018 at 1:46 PM, Maheshika Goonetilleke < > mahesh...@wso2.com> wrote: > >> Hi Indunil >> >> Please provide the maven group id for this repo. >> >> On Wed, Feb 14, 2018 at 1:11 PM, Afkham Azeez <az...@wso2.com> wrote: >> >>> Approved >>> >>> On Feb 12, 2018 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 <077%20218%202255> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 <077%20218%202255> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Indunil Upeksha Rathnayake >>>>> Software Engineer | WSO2 Inc >>>>> Email indu...@wso2.com >>>>> Mobile 0772182255 <077%20218%202255> >>>>> >>>> >>>> >>>> >>>> -- >>>> Indunil Upeksha Rathnayake >>>> Software Engineer | WSO2 Inc >>>> Email indu...@wso2.com >>>> Mobile 0772182255 <077%20218%202255> >>>> >>> >>> >>> >>> -- >>> Indunil Upeksha Rathnayake >>> Software Engineer | WSO2 Inc >>> Email indu...@wso2.com >>> Mobile 0772182255 <077%20218%202255> >>> >>> >>> >> >> >> -- >> >> Thanks & Best Regards, >> >> Maheshika Goonetilleke >> Senior Engineering Process Coordinator >> >> *WSO2 Inc* >> *email : mahesh...@wso2.com <mahesh...@wso2.com>* >> *mobile : +94 773 596707 <+94%2077%20359%206707>* >> *www: :http://wso2.com <http://wso2.com/>*lean . enterprise . middleware >> >> >> >> >> > > > -- > 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
