Security Articles from Wikipedia

More documents

Recommendations

Info

X.509 167 X.509 also includes standards for certificate revocation list (CRL) implementations, an often neglected aspect of PKI systems. The IETF-approved way of checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by default along with versions of Windows including Vista and later. Structure of a certificate The structure foreseen by the standards is expressed in a formal language, namely Abstract Syntax Notation One. The structure of an X.509 v3 digital certificate is as follows: • Certificate • Version • Serial Number • Algorithm ID • Issuer • Validity • Not Before • Not After • Subject • Subject Public Key Info • Public Key Algorithm • Subject Public Key • Issuer Unique Identifier (optional) • Subject Unique Identifier (optional) • Extensions (optional) • ... • Certificate Signature Algorithm • Certificate Signature Each extension has its own id, expressed as Object identifier, which is a set of values, together with either a critical or non-critical indication. A certificate-using system MUST reject the certificate if it encounters a critical extension that it does not recognize, or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The structure of Version 1 is given in RFC 1422 [1] . ITU-T introduced issuer and subject unique identifiers in version 2 to permit the reuse of issuer or subject name after some time. An example of reuse will be when a CA goes bankrupt and its name is deleted <strong>from</strong> the country's public list. After some time another CA with the same name may register itself, even though it is unrelated to the first one. However, IETF recommends that no issuer and subject names be reused. Therefore, version 2 is not widely deployed in the Internet. Extensions were introduced in version 3. A CA can use extensions to issue a certificate only for a specific purpose (e.g. only for signing digital object). Each extension can be critical or non-critical. If an extension is critical and the system processing the certificate does not recognize the extension or cannot process it, the system MUST reject the entire certificate. A non-critical extension, on the other hand, can be ignored while the system processes the rest of the certificate. In all versions, the serial number MUST be unique for each certificate issued by a specific CA (as mentioned in RFC 2459).
X.509 168 Extensions informing a specific usage of a certificate • Basic Constraints are used to indicate whether the certificate belongs to a CA. • Key usage is used to specify the usage of the public key contained in the certificate. • Extended key usage is used to indicate the purpose of the public key contained in the certificate. NSS uses this to specify the certificate type. As mentioned in RFC 5280, if key usage and extended key usage extensions are both present, both MUST be processed and the certificate can only be utilized if both extensions are coherent in specifying the usage of a certificate. For example, NSS uses both extensions to specify certificate usage. [2] Certificate filename extensions Common filename extensions for X.509 certificates are: • .pem - (Privacy Enhanced Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" • .cer, .crt, .der - usually in binary DER form, but Base64-encoded certificates are common too (see .pem above) • .p7b, .p7c - PKCS#7 SignedData structure without data, just certificate(s) or CRL(s) • .p12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected) • .pfx - PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS) PKCS#7 is a standard for signing or encrypting (officially called "enveloping") data. Since the certificate is needed to verify signed data, it is possible to include them in the SignedData structure. A .P7C file is a degenerated SignedData structure, without any data to sign. PKCS#12 evolved <strong>from</strong> the personal information exchange (PFX) standard and is used to exchange public and private objects in a single file. Sample X.509 certificates This is an example of a decoded X.509 certificate for www.freesoft.org, generated with OpenSSL—the actual certificate is about 1 kB in size. It was issued by Thawte (since acquired by VeriSign), as stated in the Issuer field. Its subject contains many personal details, but the most important part is usually the common name (CN), as this is the part that must match the host being authenticated. Also included is an RSA public key (modulus and public exponent), followed by the signature, computed by taking a MD5 hash of the first part of the certificate and signing it (applying the encryption operation) using Thawte's RSA private key. Certificate: Data: Version: 1 (0x0) Serial Number: 7829 (0x1e95) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, Validity OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com Not Before: Jul 9 16:04:02 1998 GMT Not After : Jul 9 16:04:02 1999 GMT Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Page 1 and 2:
Security Articles from Wikipedia PD
Page 3 and 4:
Article Licenses License 180
Page 5 and 6:
Advanced Encryption Standard 2 is a
Page 7 and 8:
Advanced Encryption Standard 4 The
Page 9 and 10:
Advanced Encryption Standard 6 Know
Page 11 and 12:
Advanced Encryption Standard 8 Test
Page 13 and 14:
Block cipher 10 Block cipher In cry
Page 15 and 16:
Block cipher 12 Block ciphers and o
Page 17 and 18:
Block cipher modes of operation 14
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Certificate authority 24 Certificat
Page 29 and 30:
Certificate authority 26 Security T
Page 31 and 32:
CMAC 28 The CMAC tag generation pro
Page 33 and 34:
Cryptographic hash function 30 resi
Page 35 and 36:
Cryptographic hash function 32 func
Page 37 and 38:
Cryptographic hash function 34 Algo
Page 39 and 40:
DiffieHellman key exchange 36 The s
Page 41 and 42:
DiffieHellman key exchange 38 3. Bo
Page 43 and 44:
DiffieHellman key exchange 40 Upon
Page 45 and 46:
DiffieHellman key exchange 42 • C
Page 47 and 48:
Digital signature 44 every paramete
Page 49 and 50:
Digital signature 46 implemented. I
Page 51 and 52:
Digital signature 48 authority). Fo
Page 53 and 54:
Digital Signature Algorithm 50 Digi
Page 55 and 56:
Digital Signature Algorithm 52 Sens
Page 57 and 58:
HMAC 54 Implementation The followin
Page 59 and 60:
HMAC 56 External links • FIPS PUB
Page 61 and 62:
HTTP Secure 58 Browser integration
Page 63 and 64:
HTTP Secure 60 From an architectura
Page 65 and 66:
IPsec 62 IPsec Internet Protocol Se
Page 67 and 68:
IPsec 64 operates directly on top o
Page 69 and 70:
IPsec 66 Cryptographic algorithms C
Page 71 and 72:
IPsec 68 External links • All IET
Page 73 and 74:
Kerberos (protocol) 70 Kerberos (pr
Page 75 and 76:
Kerberos (protocol) 72 Client Authe
Page 77 and 78:
Kerberos (protocol) 74 External lin
Page 79 and 80:
Message authentication code 76 Mess
Page 81 and 82:
Message authentication code 78 Exte
Page 83 and 84:
NeedhamSchroeder protocol 80 S resp
Page 85 and 86:
Pretty Good Privacy 82 Pretty Good
Page 87 and 88:
Pretty Good Privacy 84 Security qua
Page 89 and 90:
Pretty Good Privacy 86 PGP 3 and fo
Page 91 and 92:
Pretty Good Privacy 88 based on sec
Page 93 and 94:
Public key certificate 90 Public ke
Page 95 and 96:
Public key certificate 92 (b) ensur
Page 97 and 98:
Public key certificate 94 Usefulnes
Page 99 and 100:
Public key infrastructure 96 As tim
Page 101 and 102:
Public key infrastructure 98 Extern
Page 103 and 104:
Public-key cryptography 100 In cont
Page 105 and 106:
Public-key cryptography 102 To achi
Page 107 and 108:
Public-key cryptography 104 using t
Page 109 and 110:
Public-key cryptography 106 Spreadi
Page 111 and 112:
Public-key cryptography 108 Externa
Page 113 and 114:
RSA (algorithm) 110 The RSA algorit
Page 115 and 116:
RSA (algorithm) 112 A working examp
Page 117 and 118:
RSA (algorithm) 114 Signing message
Page 119 and 120: RSA (algorithm) 116 Side-channel an
Page 121 and 122: RSA (algorithm) 118 • The PKCS #1
Page 123 and 124: S/MIME 120 administrative overhead
Page 125 and 126: Secure Electronic Transaction 122 T
Page 127 and 128: Secure Shell 124 Usage SSH is typic
Page 129 and 130: Secure Shell 126 • RFC 4462, Gene
Page 131 and 132: Secure Shell 128 ability to multipl
Page 133 and 134: Security service (telecommunication
Page 135 and 136: Security service (telecommunication
Page 137 and 138: SHA-1 134 SHA-1 SHA-1 General Desig
Page 139 and 140: SHA-1 136 Applications SHA-1 forms
Page 141 and 142: SHA-1 138 At the Rump Session of CR
Page 143 and 144: SHA-1 140 a = temp Add this chunk's
Page 145 and 146: SHA-1 142 • Xiaoyun Wang, Yiqun L
Page 147 and 148: Stream cipher 144 Types of stream c
Page 149 and 150: Stream cipher 146 Filter generator
Page 151 and 152: Stream cipher 148 SNOW Pre-2003 Ver
Page 153 and 154: Symmetric-key algorithm 150 Key gen
Page 155 and 156: Transport Layer Security 152 TLS 1.
Page 157 and 158: Transport Layer Security 154 • SS
Page 159 and 160: Transport Layer Security 156 • Fi
Page 161 and 162: Transport Layer Security 158 Length
Page 163 and 164: Transport Layer Security 160 layer
Page 165 and 166: Transport Layer Security 162 Suppor
Page 167 and 168: Transport Layer Security 164 • RF
Page 169: Transport Layer Security 166 Extern
Page 173 and 174: X.509 170 00:d3:a4:50:6e:c8:ff:56:6
Page 175 and 176: X.509 172 Exploits • MD2-based ce
Page 177 and 178: X.509 174 External links • ITU-T
Page 179 and 180: Article Sources and Contributors 17
Page 181 and 182: Article Sources and Contributors 17
Page 183: License 180 License Creative Common
show all

Security Articles from Wikipedia

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?