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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
