Farklar

Bu sayfanın seçili sürümü ile mevcut sürümü arasındaki farkları gösterir.

--- en:esya:sertifika:dogrulama-kutuphane [2013/07/29 12:15]
Dindar Öz created
+++ en:esya:sertifika:dogrulama-kutuphane [2013/08/23 12:49] (mevcut)
Dindar Öz
@@ Satır 1: / Satır 1: @@
-====== Sertifika Doğrulama Kütüphanesi Bileşenleri ======
+====== Certificate Validation API Components ======
-Esya Sertifika Doğrulama API'si [[esya:sertifika:sertifika-dogrulama-aracları|zincir oluşturma ve  zincir doğrulama]]   algoritmalarını kullanır. Özetle bir sertifika ya da SİL için doğrulama isteğinde bulunulduğunda , önce güvenilir bir kök sertifikada sonlanan bir sertifika zinciri oluşturulur ve bu zincir doğrulanmaya çalışılır. Geçerli bir zincir bulununcaya kadar bu işlem tekrarlanır.
+ESYA Certificate Validation API uses [[en:esya:sertifika:sertifika-dogrulama-aracları|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:sertifika:15.png |Şekil 15 Esya Sertifika Doğrulama API - Sertifika İşleme Aktivite Diyagramı}}
+{{ :esya:sertifika:15.png |Figure 15 ESYA Certificate Validation API - Activity Diagram of Certificate Processing}}
-Esya Sertifika Doğrulama API'si zincir doğrulama sırasında gerçekleştirilen yapısal doğrulama ve zincir ilişkisinin doğrulanması ile ilgili kontrolleri [[esya:sertifika:sertifika-dogrulama-aracları|diyagramda]]   yer alan Sertifika İşleme adımında gerçekleştirir. Sertifika İşleme adımının detayları yukarıdaki şekilde görüntülenmektedir.
+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.
-Bu aktivite gruplara ayrılmış bir takım kontrol işlemlerinden oluşur ve bu kontrol işlemleri bir sertifika doğrulama politika dosyasında çalışma zamanında yapılandırılabilir. Bu politika dosyasının yapısı [[esya:sertifika:dogrulama-politikası|bu bölümde]] yer almaktadır. Bu kontrol işlemleri atomik olarak ayrı ayrı tanımlanmış ve her bir atomik kontrol için bir kontrolcü (Checker) sınıf tanımlanmıştır. Kontrolcü sınıflarının kontrol işlemlerini yaparken ihtiyaç duyduğu sertifika , SİL, OCSP cevabı gibi kaynakları çeşitli yollarla ve çeşitli yerlerden bulmak için bulucu (Finder) sınıfları tanımlanmıştır. Bulucuların bulduğu kaynakların doğru kaynaklar olup olmadığının test edilmesi gerekmektedir ve bu amaçla eşleştirici (Matcher) sınıfları oluşturulmuştur. Esya Sertifika Doğrulama Kütüphanesi hangi kontrollerin yapılacağını yani hangi kontrolcü sınıflarının kullanılacağını, ihtiyaç duyulan kaynaklar için nerelere bakılacağını yani hangi bulucu sınıflarının kullanılacağını ve bulunan kaynakların nasıl eşleştirileceğini yani hangi eşleştirici sınıflarının kullanılacağını belirlemek amacıyla çalışma zamanında işlemek üzere doğrulama politikası dosyasını kullanır. Doğrulama işleminin öncesinde bu politika dosyası okunarak gerekli kontrolcü, bulucu, ve eşleştirici alt sınıfları oluşturulur.
+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 [[en:esya:sertifika:dogrulama-politikası|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.
-===== Kontrolcüler =====
+===== Checkers =====
-Sertifika ve SİL'lerin yapısal özelliklerinin ve sertifika zincir ilişkisinin standartlara uygunluğunu kontrol eden sınıflardır. Bu sınıfların detayları bu dökümanın kapsamı dışındadır. Bu kontrolcülerin hangilerinin çalışacağı, doğrulama politika dosyası aracılığıyla belirlenir.  Sertifika doğrulama işleminde gerçekleştirilen ve RFC 5280'de tanımlanan kontrolcüler temel olarak şunlardır;
+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:
-==== Yapısal Kontroller ====
+==== Structural Control Operations ====
-Yapısal kontroller, sertifikanın ve SİL'in üzerindeki bilgilerin içerik ve biçimsel olarak geçerliliğinin kontrollerini kapsar. Temel olarak aşağıdaki gibi listelenebilir
+Structural Control Operations includes validity checks of the information taking place in the certificate or crl both structurally and contextually. These operations are:
-    * Seri Numarası Kontrolü : Sertifika üzerindeki seri numarasının pozitif bir tamsayı olduğunun kontrolü.
+    * Serial Numer Control : To check if the certificate serial number is a poisitive integer.
-    * Sertifika Geçerlilik Tarihi Kontrolü :Sertifika üzerindeki geçerlilik tarihlerinin doğrulama zamanını kapsadığının kontrolü.
+    * Certificate Date Control : To check if the validity period of the certificate covers the validation date.
-    * Versiyon Kontrolü : Sertifika üzerindeki versiyon bilgisinin geçerliliğinin kontrolü.
+    * Version Control : To check if the version information is valid.
-    * Eklenti Kontrolü :Sertifika üzerindeki eklentilerin geçerliliğinin kontrolü.
+    * Extension Control: To check if the extensions of the certificate are valid.
-    * İmza Algoritması Kontrolü :Sertifika üzerinde yazan imza algoritmasının imzalanmış imza algoritması bilgisiyle aynı olması kontrolü.
+    * Signature Algorithm Control: To check if the signature algorithm defined in the certificate matches with the the one used in the signature of the certificate.
-==== Zincir İlişkisi Kontrolleri ====
+==== Chain Relation Validation ====
-Zincir İlişkisi kontrolleri, sertifika veya SİL ile bu seritifika veya SİL'i yayınlayan yetkili makam sertifikası arasındaki ilişkiyi inceleyen kontrolleri içerir.
+Chain Relation Validation includes the controls validating the relation between the certificte or crl and the issuer certificate.
-    * İsim Kontrolü:Sertifika veya SİL üzerindeki yayıncı(issuer) alanı ile  yayıncı sertifikası üzerindeki özne(subject) alanının aynı olduğunun kontrolü.
+    * Name Control:To check if the issuer field of the certificate or the crl matches with the subject field of the issuer certificate.
-    * İmza Kontrolü :Sertifika veya SİL üzerindeki imzanın yayınlayan sertifikasındaki açık anahtar ile kriptografik olarak doğrulanması.
+    * Signature Control : To verify the signature in the certificate or the crl by using the public key of the iissuer certificate.
-    * Temel Kısıtlar Kontrolü :Yayıncı sertifikası üzerinde Temel Kısıtlar (Basic Constraints) eklentisinin bulunduğu ve bu eklentideki yayıncı işaretçisinin RFC 5280'de belirtildiği şekilde yer aldığı kontrolü.
+    * Basic Constraints Control : To check if the issuer certificate has Basic Constraints extension and this extension contains issuer flag as defined in RFC 5280.
-    * Anahtar Tanımlayıcısı Kontrolü :Sertifika veya SİL üzerindeki yetkili anahtar tanımlayıcısı (Authorithy Key Identifier) eklentisindeki değer ile yayıncı sertifikasındaki anahtar tanımlayıcısı değerinin uyuşması kontrolü.
+    * Key Identifier Control : To check if the authority key identifier field extensionin the certificate or the crl matches with the subject key identifier extension in the issuer certificate.
-    * Yol Uzunluğu Kontrolü:Sertifika zincirinin uzunluğunun, yayıncı sertifikasındaki yol uzunluğu eklentisinde yer alan değerden uzun olmaması kontrolü.
+    * Path Length Control:To check if the length of the certificate chain does not exceed the value taking place in the issuer certificate
-    * Anahtar Kullanımı Kontrolü:Yayıncı sertifikasındaki anahtar kullanımı (Key Usage) eklentisinde sertifika imzalama özelliğinin bulunması kontrolü.
+    * Key Usage Control: To check if the key usage of the issuer certificate includes certificate signing usage.
-==== İptal Kontrolleri ====
+==== Revocation Controls ====
-Sertifikanın iptal durumu kontrollerini içerir.
+These controls are related with the revocation status of the certificate.
-    * SİL'den İptal Durumu Kontrolü :Sertifikaya ilişkin SİL'den sertifikanın iptal durumunun kontrolü.
+    * Revocation Control From CRL :To check revocation status of the certificate by using its CRL.
-    * OCSP'den İptal Durumu Kontrolü :Sertifikaya ilişkin OCSP cevabından sertifikanın iptal durumunun kontrolü.
+    * Revocation Control From OCSP :To check revocation status of the certificate by using its OCSP.
-==== İsim Kontrolleri ====
+==== Name Controls ====
-Sertifika'daki özne bilgisi yayıncı sertifikasında yer alan isim kısıtlamaları eklentisinde tanımlı bir takım kurallara göre değerler alabilir. Bu detaylar RFC 5280'de belirtilmiştir ve isim kontrolleri kapsamında bu kurallara uyulup uyulmadığı kontrol edilmektedir.
+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.
-==== Politika Kontrolleri =====
+==== Policy Controls =====
-Sertifikadaki politika bilgileri eklentisinde yer alan politika bilgileri, yayıncı sertifikasındaki isim kısıtlamaları eklentisinde tanımlı bir takım kurallara göre değerler alabilir. Bu detaylar RFC 5280'de belirtilmiştir ve politika kontrolleri kapsamında bu kurallara uyulup uyulmadığı kontrol edilmektedir.
+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.
-Esya  Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm kontrolcülerin listesi [[esya:sertifika:dogrulama-politikası| Table 1'de]] yer almaktadır.
+The list of all checkers defined in ESYA Certificate Validation API is shown in [[en:esya:sertifika:dogrulama-politikası| Table 1]]
-===== Bulucular =====
+===== Finders =====
-Kontrolcü sınıflar çalışırken bir takım dış verilere ihtiyaç duyabilirler. Bunlar SİL bilgisi , OCSP sorgusu ya da SM sertifikası olabilir. Yine zincir oluşturma sırasında SM sertifikalarının çeşitli yerlerden (http adresi, yerel seritifika deposu vb.) bulunması gerekebilir. Genel olarak sertifika doğrulama sırasında dışarıdan bulunması gereken sertifika , SİL, OCSP Cevabı verilerini bulma işlemini bulucu sınıflar gerçekleştirir. Bir sertifika , SİL ya da OCSP cevabı bulunurken politika dosyasında tanımlı Bulucular sırayla çalıştırılır ve aranılan veri bulunduğunda bulma işlemi sonlandırılır. Bu nedenle bulucuların uygun bir sırayla politika dosyasına yerleştirilmiş olması performans açısından oldukça önemlidir. Örneğin yerel depodan sertifika bulucunun uzak kaynaklardan(LDAP,HTTP vb.) sertifika bulculardan önce yerleştirilmesi sertifika arama işlemlerinin sertifika yerel depoda varsa uzak kaynaklara başvurulmadan sonuçlanmasını sağlar ve bu da ciddi performans kazanımları getirir. Sertifika Doğrulama politikası aracılığıyla hangi bulucuların hangi sırayla çalıştırılacakları bilgisi tanımlanmaktadır.
+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.
-Esya Sertifika Doğrulama Kütüphanesinde tanımlı bulucular şu şekilde gruplanabilir.
+Finder classes are orgainzed as follows:
-==== Güvenilir Sertifika Bulucular ====
+==== Trusted Certificate Finders ====
-Doğrulama kütüphanesinin güvenilir olarak tanıdığı SM sertifikalarını bulan sınıflardır.
+These classes find the CA certificates trusted by the Validation API.
-==== Sertifika Bulucular ====
+==== Certificate Finders ====
-SM sertifikası bulmaktan sorumlu sınıflardır.Bu bulucular sertifikanın üzerinde yer alan Yetkili Erişim Noktası (AIA) eklentisine bakarak SM sertifikası bulan sınıflar olabileceği gibi bir http adresinden, bir LDAP adresinden ya da dosya sistemindeki bir adresten ya da yerel sertifika deposundan sertifika bulan sınıflar olabilir.
+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.
-==== SİL Bulucular ====
-SİL bulmaktan sorumlu sınıflardır. Sertifika üzerinde yazan Sil Dağıtım Noktaları (CDP)  eklentisine bakarak SİL bulan sınıflar olabileceği gibi bir http adresinden, bir LDAP adresinden ya da dosya sistemindeki bir adresten ya da yerel sertifika deposundan SİL bulan sınıflar olabilir.
+==== CRL Finders ====
-==== OCSP Cevabı Bulucular ====
+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 cevabı bulmaktan sorumlu sınıflardır. Sertifika üzerinde yazan Yetkili Erişim Noktası (AIA) bakarak OCSP cevabı bulan sınıflar olabileceği gibi bir http adresinden, bir LDAP adresinden ya da dosya sistemindeki bir adresten ya da yerel sertifika deposundan OCSP cevabı  bulan sınıflar olabilir.
+==== OCSP Response Finders ====
+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.
-Esya  Sertifika Doğrulama API’sinde tanımlı ve politika dosyasında kullanılabilecek tüm bulucuların listesi [[esya:sertifika:dogrulama-politikası|Table 3’te]] yer almaktadır.
+The list of all finders defined in ESYA Certificate Validation API is shown in [[en:esya:sertifika:dogrulama-politikası| Table 3]]
+===== Matchers =====
+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:
-===== Eşleştiriciler =====
+==== Certificate Matchers ====
-Bulunan sertifika, SİL ya da OCSP cevabı bilgilerinin gerçekten aranılan veriler olup olmadığını anlamak için gerekli eşleştirmeden sorumlu sınıflardır.Bu eşleştirme kuralları RFC 5280'de yer almaktadır.
+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.
-Esya Sertifika Doğrulama Kütüphanesinde tanımlı bulucular şu şekilde gruplanabilir.
-==== Sertifika Eşleştiriciler ====
-Sertifika ile yayıncı sertifikasını eşleştiren sınıflardır. Örneğin RFC 5280'de bir X509 sertifikası üzerinde yazan issuer alanı ile yayıncı sertifikası üzerinde yer alan subject alanı aynı olmalıdır şeklinde bir ifade yer alır. Esya Sertifika Doğrulama kütüphanesinde bu eşleştirme işini gerçekleştiren eşleştirici (IssuerSubjectMatcher) sınıfı vardır. Eşleştiricilerin eşleştiremediği sertifikalar yayıncı sertifikası olarak sertifika zincirine eklenmezler.
+==== CRL Matchers ====
-==== SİL Eşleştiriciler ====
+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.
-Sertifika ile SİL'i  ya da SİL ile SİL yayınlayan sertifikayı eşleştiren sınıflardır. Örneğin RFC 5280'de , dolaylı SİL (indirect crl) kullanılmıyorsa, bir SİL üzerinde yazan issuer alanı ile yayıncı sertifikası üzerinde yer alan subject alanı aynı olmalıdır şeklinde bir ifade yer alır. Bir SİL'in yayıncı sertifikası olan sertifikanın bulunması için bu ifadenin doğruluğu kontrol edilir. Bu kontrol işlemi için bir eşleştirici (CRLIssuerMatcher) tanımlıdır.
+==== OCSP Response Matchers ====
-==== OCSP Cevabı Eşleştiriciler ====
+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.
-Sertifika ile OCSP cevabını eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir
+==== Delta CRL Matchers ====
-==== Delta SİL Eşleştiriciler ====
+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.
-SİL ile Delta-SİL'i eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir
-==== Çapraz Sertifika Eşleştiriciler ====
+==== Cross Certificate Matchers ====
-SM Sertifikası ile çapraz SM sertifikasını eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir.
+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 [[esya:sertifika:dogrulama-politikası|Table 2’de]] yer almaktadır.
+Esya  Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm eşleştiricilerin listesi [[en:esya:sertifika:dogrulama-politikası|Table 2]] yer almaktadır.
-===== Kaydediciler =====
+===== Savers =====
-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.
+ESYA Certificate Validation API saves the certificates and CRL's found during validation to the local certificate store. Savers are responsible for this operation. The list of savers can be specified by the validation policy file.
-Esya  Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm kaydedicilerin listesi [[esya:sertifika:dogrulama-politikası|Table 4’te]] yer almaktadır.
+The list of all savers defined in ESYA Certificate Validation API is shown in [[en:esya:sertifika:dogrulama-politikası| Table 4]]
-===== Sertifika Doğrulama Politikası =====
+===== Certificate Validation Policy =====
-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.
+Certificate validation is series of sequentially performed control steps. The list of controls steps to be performed, and some other validation parameters can be defined at run-time via an XML-based file, named as certificate validation policy file. In this file, every element named as "class" represents a class in the Certificate Validation API which is a Checker, Finder, Matcher, or Saver class. At the beginning of the validation operation, the policy file is read and policy object is created. The whole validation process is performed according the configuration information defined by this policy object.
-Örnek Sertifika Doğrulama Politikası Dosyası
+A sample validation policy
 <file xml certval-policy>
 <!--Dosyayı xml olarak kaydediniz-->
@@ Satır 232: / Satır 241: @@
 </policy>
 </file>
-==== Sertifika Doğrulama Politika Dosyasının Güvenliği ====
+==== Security Issues Concerning Certificate Validation Policy File  ====
-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.
+Policy file specifies the control steps, location and the find method of external resources, and matching criteria for those resources.Furthermore, the trusted certificates that the certificate chains must end at are also defined by certificate validation policy. Therefore it is crucial that the policy file can not be modified in an unauthorized manner. Malicious people can cause verification of signed documents which are created by invalid certificates by changing the certificate validation policy file. For the security of the policy file the measures below can be taken;
-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.
+  * The Policy file is retrieved from a server and stored in the memory. Thus, unauthorized access to the policy file  gets more difficult.
-Politika dosyası için aşağıdaki güvenlik önlemleri uygulanabilir;
+  * The hash of the policy file stored at the server-side. Upon verification at the client-side, first the hash of the policy file is calculated and matched with the one at the server-side. This prevents unauthorized modification of the policy file. Hash calculation can be performed by DigestUtil class.
+  * The Policy file is stored as password-based encrypted and decrypted in memory whenever it is used for certificate validation.
+  * The policy file can is signed and verified whenever it is used for certificate validation.For the verification of the signature of the policy file, the signing certificate must be embedded into the source code of your application. Since it is very hard to change the embedded certificate in the source code, you have to take great care for not losing the private keys corresponding to the certificate used for signing the policy file. You can use PKCS7 signatures ([[en:esya:smartcard:pkcs7|see pkcs7]])
-    * Politika dosyası  sunucudan çekilir  ve  bellekte tutulur.  Böylelikle  politika  dosyasına dışardan müdahale olasılığı azalır.
+We certainly recommend taking one or more precautions listed above for your security.
-    * Politika dosyasının özeti sunucuda tutulur. İstemcideki politika dosyasının özeti alınır ve sunucudan çekilen	özet ile karşılaştırılır. DigestUtil sınıfı ile özet işlemini gerçekleştirebilirsiniz.
-    * Politika dosyası istemcide parola tabanlı şifrelenerek  tutulur ve şifresi bellekte çözülür. Bunun nasıl yapıldığı gösteren örneği "http://www.java2s.com/Tutorial/Java/0490Security/PBEFileEncrypt.htm" adresinde bulabilirsiniz.
-    * Politika dosyası imzalı bir şekilde tutulur. Politika dosyasına karar  verildikten sonra  politika dosyası bir kere  imzalanır ve bu imzalı dosya  istemcilerde tutulur. İmzalanan politika dosyasının imzası doğrulanırsa ve imza doğru kişi tarafından atılmışsa; politika dosyasına güvenilebilir. Doğru kişi imzalamış mı kontrolünün yapılması için, kodunuzun içine imzacı sertifikasının  gömülmesi gerekmektedir. Kodunuzu, devamlı değiştiremeyeceğinizden imzalama işleminde kullandığınız  akıllı kartı veya pfx dosyasını kesinlikle kaybetmemeniz gerekmektedir. Politika dosyasını PKCS7 standardında imzalayabilirsiniz.  PKCS7 tipindeki imza için [[esya:smartcard:pkcs7|buraya]] bakabilirsiniz.
-Yukarıdaki güvenlik önlemleri birlikte veya tek olarak uygulanabilir. Politika dosyasının güvensiz bir şekilde istemcilerde durmasını kesinlikle önermiyoruz.
+==== Certificate/CRL Status Info ====
-==== Sertifika-SİL Durum Bilgisi ====
+ESYA Certificate Validation API creates an object of CertificateStatusInfo or CRLStatusInfo classes after the validation of certificate or crl accordingly. In this object, detailed validation information such as invalid certificate chains found during validation can be found. The usage of CertificateStatusInfo and CRLStatusInfo classes with sample codes can be found in [[en:esya:cades:eimza-cades-kutuphanesi|CAdES Signature API]]
-Esya Sertifika Doğrulama Kütüphanesi sertifika ve SİL doğrulama işlemi sonucunda Sertifika Durum Bilgisi (CertificateStatusInfo) ve SİL Durum Bilgisi (CRLStatusInfo) sınıflarından bir nesne oluşturur. Bu sınıf içerisinde ayrıntılı kontrol detayları , oluşturulmuş ve doğrulanmaya çalışılan farklı sertifika zincirleri doğrulanma sonuçlarıyla birlikte detaylı olarak saklanır.  Bu sınıfın nesnesinin kullanımı, örnek kodlarla birlikte [[esya:cades:eimza-cades-kutuphanesi|CAdES İmza Kütüphanesi]] bölümünde daha detaylı olarak görülebilir.
+===== Local Certificate Store =====
-===== Yerel Sertifika Deposu =====
+Certificate Store is a file-based database and designed as a storage for the certificates of the trusted issuers. It also plays a cache role for the issuer certificates, crls and OCSP Responses in the certificate validation process. Once those resources  are retrieved from a remote source then they are stored in the local certificate store and used upon further demand by other validation operations.
-Sertifika deposu, güvenilir olduğu kabul edilen yayıncı sertifikalarının saklanabileceği bir kök sertifika deposu olarak geliştirilmiştir.
+The default location of the certificate store, is the ".sertifikadeposu" folder located in the user's home directory. The default name for the certificate store file is "SertifikaDeposu.svt". If a different name and location is used for the certificate store then these parameters must be defined in the certificate validation policy file by specifying the parameter named as "storepath".
-Sertifika deposu aynı zamanda doğrulama işlemi sırasında bulunması gereken yayıncı sertifikası, SİL, OCSP cevabı gibi verilerin sürekli uzak kaynaklardan çekilmesini engellemek için bu verilerin yerelde saklanabilmesinden sorumludur.
+ESYA Certificate Validation API trusts the certificates that are defined as trusted rood certificates in the certificate store.
-Sertifika deposunun varsayılan yeri, kullanıcının ana klasörünün(user home  directory) altındaki ".sertifikadeposu" klasörünün içidir.  Varsayılan dosya  ismi ise "SertifikaDeposu.svt"dir. Eğer farklı bir dosya yolu ve dosya ismi kullanılması isteniyorsa, sertifika doğrulama politika dosyasında belirtilmelidir. Bunun için storepath parametresi kullanılmalıdır.
-Esya Sertifika Doğrulama API'si yerel sertifika deposunda güvenilir kök sertifikası olarak tanımlanmış seritikaları güvenilir olarak kabul eder ve doğrulama sırasında oluşturduğu sertifika zincirlerinin bu sertifikalardan biriyle sonlanmasını bekler. API'deki yerel sertifika deposundan sertifika ve sil bulucular kullanılarak doğrulama verileri istenildiğinde yerel depodan bulunabilir.
 <sxh xml>
@@ Satır 266: / Satır 270: @@
 </sxh>
-Test sertifikalarıyla çalışırken sertifikanın doğrulanması sırasında  PATH_VALIDATION_FAILURE hatası alabilirsiniz. Bu durumun muhtemel sebebi, test sertifikaların köklerinin sertifika deposunda güvenilir sertifika olarak tanımlanmamasıdır. Bu kök sertifikaları dosya yoluyla belirtebilirsiniz. Yalnız bu kullanım sadece test amacıyla yapılmalıdır.
+You can have PATH_VALIDATION_FAILURE error during the validation of the test certificates.Most probably the reason is that the issuer of the test certificates is not defined as trusted root in your certificate store.
+You can make this issuer certificates trusted by te API by using TrustedCertificateFinderFromFile class, which is only recommended for testing purposes.
 <sxh xml>
 <class name="("tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromFileSystem">
@@ Satır 274: / Satır 279: @@
 </sxh>
-===== XML Sertifika Deposu =====
+===== XML Certificate Store =====
-Dosya sistemine herhangi bir şekilde erişimin olmadığı durumlarda kullanılması için XML tabanlı sertifika deposu dosyası geliştirilmiştir. Bu şekilde internet üzerindeki bir depo ile çalışabilmek mümkün olmaktadır.
+In cases, where the usage of file-based certificate store is not available, an XML-based certificate store is created. Thus, you can work with a certificate store that is located on Internet.
-Sertifika doğrulama konfigürasyon dosyasında XML depodan güvenilir sertifika  bulucu aşağıdaki gibi tanımlanır:
+In the certificate validation policy file, you can define the trusted certificate finder class finding trusted certificates from an XML certificate store as follows:
 <sxh xml>
@@ Satır 284: / Satır 289: @@
 <param name="storepath" value="http://www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/>
 </class>
-Yine xml depodan sertifika bulucu aşağıdaki şekilde tanımlanır:
+A certificate finder from an XML store is also defined as follows:
 <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"/>
@@ Satır 290: / Satır 296: @@
 </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.
+TrustedCertificateFinderFromXml takes a URL parameter for the location of the XML store.To increase the performance locating the XML store on the local network should be pereferred if possible.
-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.
+Besides, XML certificate store must only be used with ESYA Certificate Validation API, which performs signature verification on the trusted certificates. Otherwise, you can not be sure that the store is not altered by any man-in-the-middle attack.
-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.
+One more thing to be mentioned is about the performance degradation caused by using XML store instead of local certificate store. This happens because you can not save the CRL files found at remote location during certificate validation if you are using XML store as XML store is a read-only source. Thus, you must repeatedly retrieve the same crls from remote locations whenever they are needed.

ESYAE-imza Kütüphaneleri

User Tools

Site Tools

Farklar

Page Tools