Adding Azeez

On Mon, Feb 12, 2018 at 10:28 AM, Maheshika Goonetilleke <mahesh...@wso2.com
> 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.
>>>
>>>    <?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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Indunil Upeksha Rathnayake
>>>> Software Engineer | WSO2 Inc
>>>> Email    indu...@wso2.com
>>>> Mobile   0772182255
>>>>
>>>
>>>
>>>
>>> --
>>> Indunil Upeksha Rathnayake
>>> Software Engineer | WSO2 Inc
>>> Email    indu...@wso2.com
>>> Mobile   0772182255
>>>
>>
>>
>>
>> --
>> Indunil Upeksha Rathnayake
>> Software Engineer | WSO2 Inc
>> Email    indu...@wso2.com
>> Mobile   0772182255
>>
>
>
>
> --
>
> Thanks & Best Regards,
>
> Maheshika Goonetilleke
> Senior Engineering Process Coordinator
>
> *WSO2 Inc*
> *email   : mahesh...@wso2.com <mahesh...@wso2.com>*
> *mobile : +94 773 596707 <+94%2077%20359%206707>*
> *www: :http://wso2.com <http://wso2.com/>*lean . enterprise . middleware
>
>
>
>
>


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

Reply via email to