Bu sayfa salt okunur. Kaynağı görebilirsiniz ama değiştiremezsiniz. Bunun yanlış olduğunu düşünüyorsanız yöneticiye danışın.
ESYA Certificate Validation API uses path building and path validation algorithms. Briefly, when a certficate is to be validated, a certificate chain ending at a trusted root certificat is created first and then the chain is tried to be validated.Until a valid chain is found,these steps are repeated for all possible certificate chains.
ESYA Certificate validation API performs validation steps taking place in structural validation and chain validation within the certificate processing step. The details of the certificate processing can be seen in the figure above.
Certificate Processing consists of some groups of validation steps which can be configured by the certificate validation policy file at run-time. The structure of the policy file takes place in certificate validation policy section. The validation steps are designed and organized to be atomic and for each atomic step a (Checker) class is defined. Checker classes , when performing the defined check operation, may need some resources like certificate, crl, or OCSP response which are found by Finder classes. The resources founded by Finders must be matched if they are the correct ones. For this purpose, Matcher classes are defined. The check operations to be performed (Checkers), the locations and methods for resources that are searched for (Finders) and the methods for resource matching (Matchers) are defined by the validation policy file at run-time. Upon validation, the policy file is read and the corresponding objects of Checker, Finder, Matcher classes are created.
Checker classes check the compatibility of the structural characteristics of the certificate and crls and the chain relation to the standards. The details of these classes are out of the scope of the document. Certificate validation policy files determines which checkers are used in validation. The check operations performed by the checkers and defined in RFC 5280 are organized as follows:
Structural Control Operations includes validity checks of the information taking place in the certificate or crl both structurally and contextually. These operations are:
Chain Relation Validation includes the controls validating the relation between the certificte or crl and the issuer certificate.
These controls are related with the revocation status of the certificate.
The subject field of the certificate can only take certain values according to the rules included in the name constraints extension in the issuer certicate. These rules are denoted in RFC 5480 in detail. Name controls check if the certificate is compatible with these rules.
The policy information in the certificate can only take certain values according to the rules included in the policy constraints extension in the issuer certicate. These rules are denoted in RFC 5480 in detail. Policy controls check if the certificate is compatible with these rules.
The list of all checkers defined in ESYA Certificate Validation API is shown in Table 1
Checker classes may need some external data when performing their jobs. These data may be a crl info, an OCSP query response, or an issuer certificate. In general, those external data needed during certificate validaton is found and retrieved by finder classes. When a certificate, crl or OCSP Response is searched for, the finders are operated in the order defined by the validation policy until the demanded data is found. Therefore the order of the Finders is very important for performance. For example, if the Local Certificate Store Finder class is placed before the Remote (HTTP, LDAP, etc.)Certificate Finder class in the policy file, then certificate validation does not search for the certificate at remote places if it is found in the local certificate store which can provides significant performance gain.
Finder classes are orgainzed as follows:
These classes find the CA certificates trusted by the Validation API.
Certificate finders are responsible for finding CA certificates. For example, CertificateFinderFromAIA finds the issuer certificate of a certificate by looking at the authority information access (AIA) extension in the certificate. The certificate finder class finding the certificate at a specied http address is another example.
CRL finders are responsible for finding CRL for revocation control. For example CRLFinderFromCDP finds the crl for a certificate, by looking at the crl distribution points (CDP) extension in the certificate. The crl finder class finding the crl at a specied LDAP address is another example.
OCSP Response finders are responsible for finding or retrieving OCSP response for revocation control. For example, OCSPResponseFinderFromAIA , retrieves the OCSP response for a certificate by querying at the OCSP server whose address is taking place in the authority information access (AIA) extension in the certificate. The ocsp response finder class finding the ocsp response in the local certificate store is another example.
The list of all finders defined in ESYA Certificate Validation API is shown in Table 3
The certificates, crls and OCSP responses that Finders have found, must be matched according to certain criteria in order to guarantee that they are the correct ones. Matchers perform these matching operations according to the rules defined in RFC 5280. Matcher classes are organized as follows:
Certificate matchers decides if a certificate and an issuer certificate are related with issuer-subject relation. For example, RFC 5280 states that the issuer filed in the certificate must be the same as the subject field in the issuer certificate. In the Validation API, there is a certificate matcher class , named IssuerSubjectMatcher, that checks this relation between a certificate and an issuer certificate. Issuer certificates are not added to the certificate chain if they are not matched by the certificate matchers defined in the validation policy.
CRL matchers decides if a certificate matches with the crl found by CRL Finders. For example RFC 5280 states that unless indirec crl is being used, the issuer field in the crl must matched with the issuer field in the certificate for which the crl is published. In the Validation API, there is a crl matcher class , named CRLIssuerMatcher, that checks this relation between a certificate and a crl. CRLs are not used in revocation control of a certificate if they are not matched by the crl matcher classes defined in the validation policy.
OCSP Response matchers decides if a certificate matches with the OCSP Response found by OCSP Response Finders. The basic operational logic is very similar to certificate and crl matchers.
Delta CRL matchers decides if a base CRL matches with the delta CRL found by Delta CRL Finders. The basic operational logic is very similar to certificate and crl matchers.
Cross Certificate matchers decides if a CA certificate matches with another CA certificate found by certificate finders. The basic operational logic is very similar to certificate and crl matchers..
Esya Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm eşleştiricilerin listesi Table 2’de yer almaktadır.
Esya Sertifika Doğrulama API'si doğrulama sırasında bulduğu sertifika ve SİL'leri yerel depoya kaydeder. Bu işlemi kaydediciler (Saver) gerçekleştirir ve yine politika dosyası aracılığıyla hangi kaydedicilerin çalışacağı tanımlanabilir. Örneğin istenildiği kadar kaydedici tanımlanarak doğrulama sırasında bulunan ve doğrulanan bütün sertifikalar istenilen yerlere kaydedilirler.
The list of all matchers defined in ESYA Certificate Validation API is shown in Table 4
Sertifika doğrulama işlemi bir çok kontrol işleminin arka arkaya yapılmasından oluşan bir süreçtir. Bu kontrol işlemlerinin hangilerinin yapılıp hangilerinin yapılmayacağını ve bu kontroller sırasında kullanılan bir takım parametrelerin çalışma zamanında belirlenebilmesi için XML formatında bir doğrulama politikası dosyası kullanılmaktadır. Bu XML dosyasında yer alan her bir “class” elemanı bir sınıfı temsil eder ve bu sınıflar doğrulamada kullanılacak kontrol, bulma ve eşleştirme sınıflarıdır. Bu dosya, doğrulama işleminin başında okunarak doğrulama politikası nesnesi oluşur ve bütün doğrulama adımları bu politikada belirtilen yapılandırma bilgileri doğrultusunda gerçekleştirilir. Doğrulamada kullanılacak kontrol, bulma ve eşleştirme sınıfları, sertifika politikası kontrolleri ile ilgili ayarlar bu yapılandırma bilgilerinden bazılarıdır.
A sample validation policy
< !--Dosyayı xml olarak kaydediniz--> < ?xml version="1.0" encoding="UTF-8"?> < policy> <find> <trustedcertificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromECertStore"> <param name="securitylevel" value="legal,organizational"/> </class> <!--class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromFileSystem"> <param name="dizin" value="path\to\trusted certificates"/> </class--> </trustedcertificate> <certificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromECertStore"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromHTTP"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromLDAP"/> </certificate> <deltacrl/> </find> <match> <certificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.match.certificate.IssuerSubjectMatcher"/> </certificate> <crl> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.match.crl.CRLIssuerMatcher"/> </crl> <deltacrl> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.BaseCRLNumberMatcher"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.CRLNumberMatcher"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.DeltaCRLIssuerMatcher"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.ScopeMatcher"/> </deltacrl> <ocsp> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.ocsp.CertIDOCSPResponseMatcher"/> </ocsp> </match> <save> <crl> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.save.CertStoreCRLSaver"/> </crl> <!--ocsp> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.save.CertStoreOCSPResponseSaver"/> </ocsp> <certificate> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.save.CertStoreCertificateSaver"/> </certificate--> </save> <validate> <certificate> <self> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.SignatureAlgConsistencyChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.PositiveSerialNumberChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.CertificateDateChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.CertificateExtensionChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.VersionChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.QualifiedCertificateChecker"> <param name="statementoids" value="(0.4.0.1862.1.1 AND 2.16.792.1.61.0.1.5070.1.1)"/> </class> </self> <trustedcertificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.SelfSignatureChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.CertificateDateChecker"/> </trustedcertificate> <issuer> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.BasicConstraintCAChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.PathLenConstraintChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.KeyIdentifierChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.CertificateKeyUsageChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.CertificateNameChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.CertificateSignatureChecker"/> </issuer> <revocation> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.revocation.RevocationFromOCSPChecker"> <param name ="devam" value="false"/> <find> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.ocsp.OCSPResponseFinderFromAIA"/> <!--class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.ocsp.OCSPResponseFinderFromECertStore"/--> </find> </class> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.revocation.RevocationFromCRLChecker"> <param name ="cevrimdisicalis" value="false"/> <param name ="checkallcrls" value="false"/> <param name ="devam" value="false"/> <find> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderFromECertStore"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderFromECertStore"> <param name = "getactivecrl" value="true"/> </class> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderFromHTTP"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderfromLDAP"/> </find> </class> </revocation> </certificate> <crl> <crlself> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.self.CRLDateChecker"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.self.CRLExtensionChecker"/> </crlself> <crlissuer> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.issuer.CRLSignatureChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.issuer.CRLKeyUsageChecker"/> </crlissuer> </crl> <ocsp> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.OCSPResponseDateChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.ResponseStatusChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.SigningCertificateChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.OCSPSignatureChecker"/> </ocsp> </validate> <parameters> <UserPolicySet value="2.5.29.32.0"/> <InitialExplicitPolicy value="false"/> <InitialAnyPolicyInhibit value="false"/> <InitialPolicyMappingInhibit value="false"/> </parameters> < /policy>
Politika dosyası, sertifika doğrulama sırasında kullanılacak verilerin nasıl bulunacağını (find), doğru verilerin bulunup bulunmadığının kontrolü için nasıl eşleştirme yapılacağını (match) ve doğrulama sırasında hangi kontrollerin yapılacağını (validate) belirten sınıfları bulunduran dosyadır.
Politika dosyasının değiştirilememesi imza doğrulama için hayati önem taşır. Politika dosyasında hangi kontrollerin yapılacağı ve hangi sertifikalara güvenileceği bilgisi yer almaktadır. Kötü niyetli kişiler politika dosyasını değiştirerek, kötü niyetle yaratılmış imzaların doğrulanmasını sağlayabilirler. Politika dosyası için aşağıdaki güvenlik önlemleri uygulanabilir;
</class> Yine xml depodan sertifika bulucu aşağıdaki şekilde tanımlanır: <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromXml"> <param name="storepath" value="http:www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/> </class> </sxh> XML depodan güvenilir sertifika bulucu parametre olarak bir URL almaktadır. Performans arttırmak için yerel ağlarda bu dosyanın bir kopyasını bulundurmak ve onunla çalışmak faydalı olur. Bunun yanında xml sertifika deposu sadece ESYA sertifika doğrulama kütüphanesi ile kullanılmalıdır. Aksi taktirde man-in-the-midle saldırısına kapı açılmış olur. ESYA Kütüphanesi bu dosyadaki güvenilir sertifikalar için imza kontrolü yapmaktadır. Bir diğer göz önünde bulundurulması gereken konu performanstır. Yerel sertifika deposu kullanılırken imza doğrulamada kullanılan iptal listeleri depoya kaydedilip tekrar kullanılabilirken, xml sertifika deposu sadece okuma özellikli olduğu için bu avantajdan mahrumdur. Bu yüzden iptal listeleri her doğrulamada tekrar indirilmek zorunda kalınacaktır. Bu da ciddi performans kaybına yol açar.