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