Hi Indunil, 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. > The implementation should not just think of X509 authentication. The implementation should be a generic utility service that can be engaged in any component that use certificates. Good example is the TLS layer of our server. Once this component is done, ideally it should be like a simple effort to engage the same for certificate validation during TLS handshake as well. So the component has to be a independent component from X509 authenticator. > > > > > 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. > > *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 > 1. I think managing the list of CAs is a matter of organization governance more than product configuration, hence should go to governance space. Also if the component is to be used across multiple products it has to be in governance space so that we can mount across all the products. 2. "certificate" doesn't seem to be a good name. Shall we make it "certificate-authorities"? 3. Why are we restricting the extensibility and manageability of the structure so much by reducing it to just two resources? I suggest we have something like following. Under "certificate-authorities" (in your structure "certificate") we can have a collection for each CA. Thereafter I am thinking we can have the certificates listed as resources under each CA collection. A CA can have multiple certificates if needed. For each certificate we can have two properties. One is the OCSP and other is the CRL. If there are multiple URLs, we can use some either comma separated form, or naming convention such as URL_1, URL_2, and so on. Better get advice for registry experts as to the pros and cons of these two forms when searching, indexing, etc. > *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. > > *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 > > Please make this also another property in the registry, since it has to be configured per tenant. Not need to splay configurations in registry and file system. > > - If both methods has enabled, verified with OCSP first, followed by > CRL > > Did you come to this conclusion by reading up on any recommendations? > > - By default (if not configured), verified with OCSP > > Did you come to this conclusion by reading up on any recommendations? Regards, Johann. > > - > > *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 > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
