Datasheet

“main” (Installation and Administration) — 2004/6/25 — 13:29 — page 622 — #648
i
i
i
i
i
i
i
i
The extensions can contain any additional information. An application
does not normally need to be able to evaluate an extension unless it is iden-
tified as critical. If an application does not recognize a critical extension, it
must reject the certificate. Some extensions reduce the use of the certificate
to a specific application, such as signature or encryption.
Table 26.1 shows the principle underlying an X.509 certificate in version 3.
Table 26.1: X.509v3 Certificate
Field Content
Version The version of the certificate, e.g., v3.
Serial Number Unique certificate ID (Integer).
Signature The ID of the algorithm used to sign the
certificate.
Issuer Unique name (DN) of the issuing authority
(CA).
Validity Period of validity (from...to).
Subject Unique name (DN) of the owner.
Subject Public
Key Info
Public key of the owner and the ID of the
algorithm.
Issuer Unique
ID
Unique ID of the issuing CA (optional).
Subject
Unique ID
Unique ID of the owner (optional).
Extensions Optional additional information, e.g.,
“KeyUsage”, “BasicConstraints”, etc.
Blocking X.509 Certificates
If a certificate becomes untrustworthy before the validity period has lapsed,
it must be blocked immediately. This can become necessary if, for example,
the private key has become public knowledge. This applies in particular if
the private key belongs to a CA rather than a user certificate. In this case,
all user certificates issued by the relevant CA must be blocked immediately.
If a certificate is blocked, the PKI (the responsible CA) must make this in-
formation available to all those involved. The instrument currently used for
this is a certificate revocation list (CRL).
622 26.1. X.509 Certification with YaST