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