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/08/23 06:45]
Dindar Öz
+++ en:esya:sertifika:dogrulama-kutuphane [2013/08/23 12:49] (mevcut)
Dindar Öz
@@ Satır 50: / Satır 50: @@
 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.
-Th list of all checkers defined in ESYA Certificate Validation API is shown in [[en:esya:sertifika:dogrulama-politikası| Table 1]]
+The list of all checkers defined in ESYA Certificate Validation API is shown in [[en:esya:sertifika:dogrulama-politikası| Table 1]]
 ===== 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:
 ==== 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.
 ==== 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.
 ==== CRL Finders ====
-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 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 ====
-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 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 =====
-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.
+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:
-Esya Sertifika Doğrulama Kütüphanesinde tanımlı bulucular şu şekilde gruplanabilir.
 ==== Certificate Matchers ====
-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.
+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 ====
-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.
+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 ====
-Sertifika ile OCSP cevabını eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir
+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 ====
-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
+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 ====
-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.
 ===== 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]]
 ===== 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.
 A sample validation policy
@@ Satır 236: / Satır 243: @@
 ==== 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 ====
-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.
+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]]
 ===== Local Certificate Store =====
-Sertifika deposu, güvenilir olduğu kabul edilen yayıncı sertifikalarının saklanabileceği bir kök sertifika deposu olarak geliştirilmiştir.
+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 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.
+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 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 Certificate Validation API trusts the certificates that are defined as trusted rood certificates in the certificate store.
-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 268: / 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 276: / 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 286: / 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 292: / 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