Approved

On Feb 12, 2018 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.
>
>    <?xml version="1.0" encoding="ISO-8859-1"?>
>
>    <CertificateValidation xmlns="http://wso2.org/project
>    s/carbon/certificate-validation.xml
>    <http://wso2.org/projects/carbon/certificate-validation.xml>">
>
>    …….
>
>    <TrustStores>
>
>       *<TrustStore truststoreFile="/path/to/truststore.jks"
>    truststorePass="cacertspassword" type="JKS"/>*
>
>    </TrustStores>
>
>    </CertificateValidation>
>
>
>    - 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>/<Certificate Serial Num>*
>
> 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 *
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>
> <CertificateValidation xmlns="http://wso2.org/project
> s/carbon/certificate-validation.xml">
>
> <Validators>
>
>     <Validator 
> name="org.wso2.carbon.identity.x509Certificate.validation.validator.CRLValidator"
> displayName="CRLValidator" enable="false">
>
>               <Parameter name="priority">1</Parameter>
>
>                *<Parameter name="fullChainValidation">true</Parameter>*
>
>
>     </Validator>
>
>     <Validator 
> name="org.wso2.carbon.identity.x509Certificate.validation.validator.OCSPValidator"
> displayName="OCSPValidator" enable="true">
>
>               <Parameter name="priority">2</Parameter>
>
>                <Parameter name="fullChainValidation">true</Parameter>
>
>     </Validator>
>
> </Validators>
>
> </CertificateValidation>
>
>    - *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 specified path before giving up.
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>
> <CertificateValidation xmlns="http://wso2.org/project
> s/carbon/certificate-validation.xml">
>
> <Validators>
>
>     <Validator 
> name="org.wso2.carbon.identity.x509Certificate.validation.validator.CRLValidator"
> displayName="CRLValidator" enable="true">
> <Parameter name="priority">1</Parameter>
>
>                 *<Parameter name="retryCount">2</Parameter>*
>
>
>     </Validator>
>
> </Validators>
>
> </CertificateValidation>
>
>
>
> [1] Mail Thread : "[Dev] Illegal Characters for Registry Resource Path"
>
> Thanks and Regards
>
>
> On Wed, Jan 10, 2018 at 12:41 PM, Indunil Upeksha Rathnayake <
> indu...@wso2.com> wrote:
>
>> 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 <as...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana <
>>>> darsh...@wso2.com> 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 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    indu...@wso2.com
>>>>>> Mobile   0772182255 <077%20218%202255>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>>
>>>>>
>>>>> *Darshana Gunawardana*Technical Lead
>>>>> WSO2 Inc.; http://wso2.com
>>>>>
>>>>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>*
>>>>> *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    indu...@wso2.com
>>> Mobile   0772182255 <077%20218%202255>
>>>
>>
>>
>>
>> --
>> Indunil Upeksha Rathnayake
>> Software Engineer | WSO2 Inc
>> Email    indu...@wso2.com
>> Mobile   0772182255 <077%20218%202255>
>>
>
>
>
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Email    indu...@wso2.com
> Mobile   0772182255 <077%20218%202255>
>



-- 
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    indu...@wso2.com
Mobile   0772182255 <077%20218%202255>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to