ESYAE-imza Kütüphaneleri

Bu sayfa salt okunur. Kaynağı görebilirsiniz ama değiştiremezsiniz. Bunun yanlış olduğunu düşünüyorsanız yöneticiye danışın.

<h1>Certificate Validation</h1> <div class="level1"> </div> <h2>Certificates</h2> <div class="level2"> <p> Certificates,in short, a digital data that cryptographically binds a key pair and any information (identity info, authority info, role etc.) in a provable and undeniable way. Data signing, encyption , authentication are some of the basic PKI operations that can be performed with the key pair in certificates. The credibility of the certificate stems from the inimitable signature issued by trusted authority (CA). This signature is included in the certificate and can be verified when needed. The <b>CA</b> can either be the source of the trust itself or its trust can come from another trusted authority (Root CA ) via CA certificate issued by the Root CA. <b>The Root CA</b> has trust on its own and its certificate issued by itself. The certificates that are not used for certificate signing and used for other purposes are called as <b>user certificates</b>. For a user certificate, the chain of certificates starting from that certificate, going thorugh the certificate issuance relation and ending at the Root CA's certificate is named as <b>certificate chain</b>. In order for a user certificate to be trusted, firstly, a certificate chain starting from the user certificate and ending at a trusted CA or Root CA's certificate must exist. The total process of checking if a certificate can be trusted and valid and therefore can be used for the applied job is called <b>certificate validation</b>. </p> <p> In order to provide a common structure for the certificates published for different purposes all over world, there are some standards defined the most widely accepted of which is X.509. In X.509 standard, certificates and CRLs are defined with their structural details. RFC 5280 document contains X.509 standard and it also includes a description of the validation process of X.509 certificates. </p> <p> Certificate Authorities (CAs) beside issuing certificates, can revoke them due to several reasons. In that case these certificates become invalid and can not be trusted anymore. For example, when the private key of a certificate is acquired by unwanted people, due to the notification of this to the corresponding CA, the CA performs the revocation of the certificate. In order for user certificates to be validated in a secure manner, the revocation information of those certificates must be securely and easily accessible. Two methods are used for this, one is the online certificate status protocol (OCSP) in which the status of the certificates are queried online and the other one is CRLs in which the revoked certificates are periodically published in a file. These two methods, like certificates, are defined by standards commonly accepted and complied all over the world. </p> </div> <h2>Online Certificate Status Protocol (OCSP)</h2> <div class="level2"> <p> 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. </p> </div> <h2>CRL Files</h2> <div class="level2"> <p> 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 <b>SİL doğrulama</b> denilir. SİL dosyalarının yapısal detayları RFC 5280'de yer almaktadır. </p> </div> <h2>X509 Certificate and CRL Validation</h2> <div class="level2"> <p> 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ı (<b>path building</b> ) ve bu zincir üzerindeki bütün sertifikaların ve zincir ilişkisinin doğrulanmasından oluşan (<b>path validation</b>) iki alt kısımda incelenebilir. </p> <p> Zincir doğrulama işlemi, zincir üzerindeki sertifikaların doğrulanması (<b>yapısal doğrulama</b>) ve zincir ilişkisinin doğrulanması (<b>zincir doğrulama</b>) ş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. </p> <p> 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. </p> </div> <h3>Certificate Path Building</h3> <div class="level3"> <p> 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. </p> <p> <a href="/esya-api/lib/exe/detail.php?id=en%3Aesya%3Asertifika%3Asertifika-dogrulama-araclar%C4%B1&media=esya:sertifika:13.png" class="media" title="esya:sertifika:13.png"><img src="/esya-api/lib/exe/fetch.php?media=esya:sertifika:13.png" class="mediacenter" title="Şekil 13 Örnek Sertifika Ağacı" alt="Şekil 13 Örnek Sertifika Ağacı" /></a> </p> <p> Sertifika ağacında <b>TA</b> ile gösterilen sertifika güvenilir bir SM ya da KSM sertifikasını temsil etmektedir. Bu durumda E sertifikasının <b>E</b>'den başlayarak <b>B</b> , <b>A</b> veya <b>C</b>'den geçerek <b>TA</b>'da biten bir sertifika zinciri oluşturulur. </p> <p> Sertifika zinciri: <b>E → B → A → TA</b> </p> </div> <h3>Certificate Path Validation</h3> <div class="level3"> <p> Bir sertifika zinciri oluşturulduktan sonra bu zincirin doğrulanması gerekmektedir. Şekilde zincir doğrulama algoritmasının akış diyagramı görülmektedir. </p> <p> <a href="/esya-api/lib/exe/detail.php?id=en%3Aesya%3Asertifika%3Asertifika-dogrulama-araclar%C4%B1&media=esya:sertifika:14.png" class="media" title="esya:sertifika:14.png"><img src="/esya-api/lib/exe/fetch.php?media=esya:sertifika:14.png" class="mediacenter" title=" Şekil 14 Zincir Doğrulama Aktivite Diyagramı" alt=" Şekil 14 Zincir Doğrulama Aktivite Diyagramı" /></a> </p> <p> Şekilde yer alan <em>Sertifika İşleme ve Sonlandırma Kontrolleri</em> işlemlerinin detayları RFC 5280'de verilmekte olup kısaca bir takım yapısal ve kriptografik kontrollerden oluştuğu söylenebilir. </p> <p> 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. </p> </div>