Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

Hi,

On Wed, Jan 3, 2018 at 6:05 PM, Asela Pathberiya  wrote:

>
>
> On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana 
> 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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Maheshika Goonetilleke]

Hi Indunil

Created the repo, please check.

On Wed, Feb 14, 2018 at 2:01 PM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> 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  wrote:
>>
>>> Approved
>>>
>>> On Feb 12, 2018 10:26 AM, "Indunil Upeksha Rathnayake" 
>>> 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.



http://wso2.org/project
s/carbon/certificate-validation.xml
">

…….



   *>>>truststorePass="cacertspassword" type="JKS"/>*






- 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/>>> Issuer DN>/*

 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 *

 

 http://wso2.org/project
 s/carbon/certificate-validation.xml">

 

 >>> displayName="CRLValidator" enable="false">

   1

*true*


 

 >>> displayName="OCSPValidator" enable="true">

   2

true

 

 

 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

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 
wrote:

> Hi Indunil
>
> Please provide the maven group id for this repo.
>
> On Wed, Feb 14, 2018 at 1:11 PM, Afkham Azeez  wrote:
>
>> Approved
>>
>> On Feb 12, 2018 10:26 AM, "Indunil Upeksha Rathnayake" 
>> 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.
>>>
>>>
>>>
>>>http://wso2.org/project
>>>s/carbon/certificate-validation.xml
>>>">
>>>
>>>…….
>>>
>>>
>>>
>>>   *>>truststorePass="cacertspassword" type="JKS"/>*
>>>
>>>
>>>
>>>
>>>
>>>
>>>- 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/>> Issuer DN>/*
>>>
>>> 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 *
>>>
>>> 
>>>
>>> http://wso2.org/project
>>> s/carbon/certificate-validation.xml">
>>>
>>> 
>>>
>>> >> displayName="CRLValidator" enable="false">
>>>
>>>   1
>>>
>>>*true*
>>>
>>>
>>> 
>>>
>>> >> displayName="OCSPValidator" enable="true">
>>>
>>>   2
>>>
>>>true
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>>- *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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Maheshika Goonetilleke]

Hi Indunil

Please provide the maven group id for this repo.

On Wed, Feb 14, 2018 at 1:11 PM, Afkham Azeez  wrote:

> Approved
>
> On Feb 12, 2018 10:26 AM, "Indunil Upeksha Rathnayake" 
> 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.
>>
>>
>>
>>http://wso2.org/project
>>s/carbon/certificate-validation.xml
>>">
>>
>>…….
>>
>>
>>
>>   *>truststorePass="cacertspassword" type="JKS"/>*
>>
>>
>>
>>
>>
>>
>>- 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/> Issuer DN>/*
>>
>> 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 *
>>
>> 
>>
>> http://wso2.org/project
>> s/carbon/certificate-validation.xml">
>>
>> 
>>
>> > displayName="CRLValidator" enable="false">
>>
>>   1
>>
>>*true*
>>
>>
>> 
>>
>> > displayName="OCSPValidator" enable="true">
>>
>>   2
>>
>>true
>>
>> 
>>
>> 
>>
>> 
>>
>>- *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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Afkham Azeez]

Approved

On Feb 12, 2018 10:26 AM, "Indunil Upeksha Rathnayake" 
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.
>
>
>
>http://wso2.org/project
>s/carbon/certificate-validation.xml
>">
>
>…….
>
>
>
>   *truststorePass="cacertspassword" type="JKS"/>*
>
>
>
>
>
>
>- 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/ Issuer DN>/*
>
> 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 *
>
> 
>
> http://wso2.org/project
> s/carbon/certificate-validation.xml">
>
> 
>
>  name="org.wso2.carbon.identity.x509Certificate.validation.validator.CRLValidator"
> displayName="CRLValidator" enable="false">
>
>   1
>
>*true*
>
>
> 
>
>  name="org.wso2.carbon.identity.x509Certificate.validation.validator.OCSPValidator"
> displayName="OCSPValidator" enable="true">
>
>   2
>
>true
>
> 
>
> 
>
> 
>
>- *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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

Adding Azeez

On Mon, Feb 12, 2018 at 10:28 AM, Maheshika Goonetilleke  wrote:

> hi Azeez
>
> Please confirm.
>
> On Mon, Feb 12, 2018 at 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.
>>>
>>>
>>>
>>>http://wso2.org/project
>>>s/carbon/certificate-validation.xml
>>>">
>>>
>>>…….
>>>
>>>
>>>
>>>   *>>truststorePass="cacertspassword" type="JKS"/>*
>>>
>>>
>>>
>>>
>>>
>>>
>>>- 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/>> Issuer DN>/*
>>>
>>> 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 *
>>>
>>> 
>>>
>>> http://wso2.org/project
>>> s/carbon/certificate-validation.xml">
>>>
>>> 
>>>
>>> >> displayName="CRLValidator" enable="false">
>>>
>>>   1
>>>
>>>*true*
>>>
>>>
>>> 
>>>
>>> >> displayName="OCSPValidator" enable="true">
>>>
>>>   2
>>>
>>>true
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>>- *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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Maheshika Goonetilleke]

hi Azeez

Please confirm.

On Mon, Feb 12, 2018 at 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.
>>
>>
>>
>>http://wso2.org/project
>>s/carbon/certificate-validation.xml
>>">
>>
>>…….
>>
>>
>>
>>   *>truststorePass="cacertspassword" type="JKS"/>*
>>
>>
>>
>>
>>
>>
>>- 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/> Issuer DN>/*
>>
>> 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 *
>>
>> 
>>
>> http://wso2.org/project
>> s/carbon/certificate-validation.xml">
>>
>> 
>>
>> > name="org.wso2.carbon.identity.x509Certificate.validation.validator.CRLValidator"
>> displayName="CRLValidator" enable="false">
>>
>>   1
>>
>>*true*
>>
>>
>> 
>>
>> > name="org.wso2.carbon.identity.x509Certificate.validation.validator.OCSPValidator"
>> displayName="OCSPValidator" enable="true">
>>
>>   2
>>
>>true
>>
>> 
>>
>> 
>>
>> 
>>
>>- *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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

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.
>
>
>
>http://wso2.org/
>projects/carbon/certificate-validation.xml
>">
>
>…….
>
>
>
>   *truststorePass="cacertspassword" type="JKS"/>*
>
>
>
>
>
>
>- 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/ Issuer DN>/*
>
> 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 *
>
> 
>
> http://wso2.org/projects/carbon/certificate-
> validation.xml">
>
> 
>
>  enable="false">
>
>   1
>
>*true*
>
>
> 
>
>  enable="true">
>
>   2
>
>true
>
> 
>
> 
>
> 
>
>- *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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

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.

   

   http://wso2.org/projects/carbon/certificate-validation.xml;>

   …….

   

  **

   

   


   - 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 : 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 *



http://wso2.org/projects/carbon/certificate-validation.xml;>





  1

   *true*






  2

   true







   - *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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

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  wrote:
>
>>
>>
>> On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana > > 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 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

Hi,

Thanks a lot for your valuable feedbacks. Please find the current
implementation details as follows.

   - Certificate validators can be configured in
   /repository/conf/security/certificate-validators.xml as follows
   with configured priorities. This will be added to tenant registry in
   /_system/governance/repository/security/certificate/validator on tenant
   activation. There will be separate resources for each validator with
   properties as name, enable and priority.

http://wso2.org/projects/carbon/certificate-validators.xml;>

1


2




   - An OSGI service which will be exposed to verify the certification
   revocation. In there, all the validator configs will be loaded from the
   registry and based on the enability and priority, corresponding validators
   will get invoked.


   - CRL Validator has been implemented as follows.


   - Extract the certificate extension value for CRL Distribution points.
  - Retrieve CRL URLs from the CRL Distribution points.
  - Download X509CRL from the CRL URLs (If one fails check with the
  other) or retrieve from the cache and check the revocation status.


   - Client certificate will be validated in X509CertificateAuthenticator
   when processing authentication response. If the given X509 Certificate is
   revoked by its Issuer, will be throwing an exception. In there, when a
   certificate has been revoked, if already a user certificate exists which
   matches with the cert in request, will be deleting the certificate from
   user claims.


Thanks and Regards

On Tue, Dec 19, 2017 at 7:32 AM, Johann Nallathamby  wrote:

> Hi Indunil,
>
> On Fri, Dec 15, 2017 at 7:32 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.
>>
>> *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.
>>
>
> Here I think we need to have a separate trust store for x509 user
> authentication. The client-truststore.jks is mainly used TLS trust. Using
> the same for X509 also will be pointless, because the whole purpose of
> having this trust store is to limit certificates we trust. If we have only
> one trust store for both TLS, and X509 user authentication we can't have
> separate set of CAs for these.
>
> Regards,
> Johann.
>
>
>> *Caching Layer :*
>>
>>- Downloaded CRL from 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Johann Nallathamby]

Hi Indunil,

On Fri, Dec 15, 2017 at 7:32 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.
>
> *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.
>

Here I think we need to have a separate trust store for x509 user
authentication. The client-truststore.jks is mainly used TLS trust. Using
the same for X509 also will be pointless, because the whole purpose of
having this trust store is to limit certificates we trust. If we have only
one trust store for both TLS, and X509 user authentication we can't have
separate set of CAs for these.

Regards,
Johann.


> *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
>- If both methods has enabled, verified with OCSP first, followed by
>CRL
>- By default (if not configured), verified with OCSP
>
> *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
> Emailindu...@wso2.com
> Mobile   0772182255
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Darshana Gunawardana]

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.


> *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
> Emailindu...@wso2.com
> 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Johann Nallathamby]

Hi Indunil,

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.
>

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)
> 

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Prasanna Dangalla]

Hi Indunil,

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.
>
> *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
>
In this scenario for a two node cluster setup do you have two separate
certificates for two nodes? I believe its the same certificate. If its the
same, you can have a config mount and inlcude the certificates in a cluster
setup.

>
> *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
>- If both methods has enabled, verified with OCSP first, followed by
>CRL
>- By default (if not configured), verified with OCSP
>
> *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
> Emailindu...@wso2.com
> Mobile   0772182255
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture