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