Hi Indunil

Please provide the maven group id for this repo.

On Wed, Feb 14, 2018 at 1:11 PM, Afkham Azeez <az...@wso2.com> wrote:

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


-- 

Thanks & Best Regards,

Maheshika Goonetilleke
Senior Engineering Process Coordinator

*WSO2 Inc*
*email   : mahesh...@wso2.com <mahesh...@wso2.com>*
*mobile : +94 773 596707*
*www: :http://wso2.com <http://wso2.com/>*lean . enterprise . middleware
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to