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> 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. </p> </div> <h2>CRL Files</h2> <div class="level2"> <p> 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. </p> </div> <h2>X509 Certificate and CRL Validation</h2> <div class="level2"> <p> 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. </p> <p> The validation of the certificates in the chain is called <b>structural validation</b> and the validation of the chain relation is called <b>chain validation</b>. 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. </p> <p> 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. </p> </div> <h3>Certificate Path Building</h3> <div class="level3"> <p> 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; </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> In the tree, the certificate named as <b>TA</b> is the certificate of a trusted CA. In this case, path building algorithm creates a certificate chain for E, starting from <b>E</b>,including <b>B</b> , <b>A</b> or <b>C</b> and ending at <b>TA</b>. </p> <p> The certificate chain: <b>EE → 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>