Farklar

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

--- en:esya:sertifika:sertifika-dogrulama-aracları [2013/07/29 13:13]
Dindar Öz
+++ en:esya:sertifika:sertifika-dogrulama-aracları [2013/08/21 06:18] (mevcut)
Dindar Öz
@@ Satır 12: / Satır 12: @@
 ===== Online Certificate Status Protocol (OCSP) =====
-RFC 2560'da tanımlı protokole uygun olarak bir veya daha fazla sertifikanın iptal durumunun bir sunucu vasıtasıyla çevrimiçi olarak sorgulanması yöntemidir. İngilizce kısaltmasıyla (OCSP) daha yaygın bilinen bu yöntemde, temel olarak bir OCSP sorgusuna karşın sunucunun cevap olarak gönderdiği bir OCSP cevabı söz konusudur. Bu cevapta sertifikanın geçerlilik durumu yeralmaktadır. Bu sorgu geçerlilik süresi dolmuş sertifikalar için yapılamaz. Protokolün detayları ilgili RFC'de yer almaktadır.
+OCSP,defined in RFC 2560, is a protocol  which enables querying of one or more certificates' revocation status information online. The protocol is initiated by an OCSP request and ends with an OCSP response generated by an OCSP server which includes the validity status ofthe queried certificates.OCSP queries can not be performed for
+expired certificates. For more details about the protocol, see the RFC 2560 document.
 ===== CRL Files =====
-Yine X509 standardında sertifika iptal bilgilerinin listelendiği SİL dosyalarının yapısal özellikleri detaylı olarak tanımlanmıştır. SİL dosyaları temel olarak iptal edilmiş sertifikaların listesi ve bu listenin SM tarafından ya da SM tarafından yetkilendirilmiş başka bir makam tarafından oluşturulmuş imzasından oluşur.  Bu listede geçerlilik süresi dolmuş sertifikalar bulunmaz. Bir sertifikanın iptal durumu kontrol edilirken bir SİL'e başvurulduğunda öncelikle bu SİL'in de X509'a uygunluğu ve geçerliliği kontrol edilmelidir. SİL için yapılması gereken bu kontroller bütününe de **SİL doğrulama** denilir. SİL dosyalarının yapısal detayları RFC 5280'de yer almaktadır.
+The structural details of CRL files is specified in X509 standard. A CRL mainly consists of a list of serial numbers of revoked certificates and a signature of this list created by the CA or any other authority assigned by the CA. Expired certificates are not listed in CRL. When a CRL is checked upon revocation control of a certificate, firstly, its X509 compatibility  and signature must be validated which is called CRL validation.
+For detailed information about CRL files RFC 5280 can be seen.
 ===== X509 Certificate and CRL Validation =====
-Sertifika ve SİL doğrulama işlemi sertifikanın ya da SİL'in güvenilir bir yetkili makam sertifikasına kadar uzanan sertifika zincirinin oluşturulması (**path building** )  ve bu zincir üzerindeki bütün sertifikaların ve zincir ilişkisinin doğrulanmasından oluşan (**path validation**)  iki alt kısımda incelenebilir.
+Certificate and CRL validation consist of two phases namely path building and path validation. Creating a certificate chain starting from the certificated or crl to be validated and ending at a certificate of a trusted authority is called path building. The validation of the all certificates and the chain relation in a certificate chain is called path validation.
-Zincir doğrulama işlemi, zincir üzerindeki sertifikaların doğrulanması (**yapısal doğrulama**) ve zincir ilişkisinin doğrulanması (**zincir doğrulama**) şeklinde iki temel bölümden oluşur. Yapısal doğrulamada sertifika veya SİL'in X509'da belirtilen yapısal özellikler karşılayıp karşılamadığına bakılır. Başka bir ifadeyle Sertifika veya SİL'in üzerinde yer alan bilgilerin standarda uygunluğu ve standarda gore geçerliliği kontrol edilir. Örneğin sertifikada seri numarası alanının olup olmadığına ve bu alanın pozitif bir sayı olup olmadığına bakılır. Ya da bir sertifikanın üzerinde yazan, geçerlilik başlangıç ve bitiş tarihlerinin doğrulama zamanını kapsayıp kapsamadığı yapısal bir doğrulama adımıdır.
+The validation of the certificates in the chain is called **structural validation** and the validation of the chain relation is called **chain validation**. In structural validation the certificates or the crl is checked if it satisfies the structural characteristics specified in X509. In other words, the information in the certificate or crl is validated according to the standard. For example, it is checked if the certificate has a serial number and it is a positive number. The validity period included in the certificate is checked if it covers the validation time which is another example of structural validation operations.
-Esya Sertifika Doğrulama Kütüphanesi yapısal doğrulama kapsamında  RFC 5280'de tanımlı bütün yapısal özellikleri kontrol eder. Zincir oluşturma algoritması olarak RFC 4158'de tanımlı zincir oluşturma algoritmasını ve zincir doğrulama algoritması olarak yine RFC 5280'de tanımlanmış zincir doğrulama algoritmasını gerçekler.
+ESYA Certificate Validation API checks for all structural specifications included in RFC 5280 within the structural validation. It performs the path building algorithm described in RFC 4158 and the path validation algorithm described in RFC 5280.
 ==== Certificate Path Building ====
-Zincir oluşturma algoritması RFC 4158'de detaylı bir şekilde anlatılmaktadır. Algoritma bir başlangıç sertifikasından başlayarak güvenilir bir kök sertifikaya ulaşıncaya kadar adım adım ilerleyerek bir sertifika zinciri oluşturur. Örneğin şekildeki gibi  kurgulanmış bir sertifika ağacı olduğunu düşünelim.
+Path building algorithm is described in RFC 4158 in detail. The algorithm starts from an initial certificate, which is the certificate to be validated, and iteratively add the issuer of the certificate to the certificates chain until a trusted root certificate is reached. For examplei let us consider the certificate tree demonstrated in the figure below;
 {{ :esya:sertifika:13.png |Şekil 13 Örnek Sertifika Ağacı}}
-Sertifika ağacında **TA** ile gösterilen sertifika güvenilir bir SM ya da KSM sertifikasını temsil etmektedir. Bu durumda E sertifikasının **E**'den başlayarak **B** , **A**  veya **C**'den geçerek  **TA**'da biten bir sertifika zinciri oluşturulur.
+In the tree, the certificate named as **TA** is the certificate of a trusted CA. In this case, path building algorithm creates a certificate chain for E, starting from **E**,including **B** , **A** or **C** and ending at **TA**.
-Sertifika zinciri:  **E -> B -> A -> TA**
+The certificate chain:  **EE -> B -> A -> TA**
 ==== Certificate Path Validation ====
-Bir sertifika zinciri oluşturulduktan sonra bu zincirin doğrulanması gerekmektedir.  Şekilde zincir doğrulama algoritmasının akış diyagramı görülmektedir.
+The chain created by the path building algorithm must be validated. The path validation algorithm is described by the flow diagram as follows:
 {{ :esya:sertifika:14.png | Şekil 14 Zincir Doğrulama Aktivite Diyagramı}}
+For more details about // Certificate Processing amd Finalization Steps // shown in the figure exist in RFC 5280. In sort, it includes a set of structural and cryptografic validations.
-Şekilde  yer alan //Sertifika İşleme ve Sonlandırma Kontrolleri// işlemlerinin detayları RFC 5280'de verilmekte olup kısaca bir takım yapısal ve kriptografik kontrollerden oluştuğu söylenebilir.
+CRL validation is almost the same as certificate validation. The only difference is the first element of the certificate chain is the certificate to be validated in certificate validation whereas the first element is the crl to be validated in crl validation.
-SİL doğrulama işlemi sertifika doğrulama işlemi ile hemen hemen aynıdır. Aradaki tek fark sertifika doğrulamada oluşturulan zincirin ilk elemanı bir kullanıcı sertifikası iken SİL doğrulamada oluşturulan zincirin ilk elemanının bir SİL olmasıdır. Ve tabii ki SİL'in yapısal  doğrulamasında sertifika yerine SİL'in yapısal özellikleri doğrulanmaktadır. Bunun dışında temel akış, sertifika doğrulama ile aynıdır.

ESYAE-imza Kütüphaneleri

User Tools

Site Tools

Farklar

Page Tools