(hx509.info.gz) What is X

 
 2 What is X.509, PKIX, PKCS7 and CMS ?
 **************************************
 
 X.509 is from the beginning created by CCITT (later ITU) for the X.500
 directory service. But today when people are talking about X.509 they
 are commonly referring to IETF's PKIX Certificate and CRL Profile of the
 X.509 v3 certificate standard, as specified in RFC 3280.
 
 ITU continues to develop the X.509 standard together in a complicated
 dance with IETF.
 
 X.509 is public key based security system that have associated data
 stored within a so called certificate. From the beginning X.509 was a
 strict hierarchical system with one root. This didn't not work so over
 time X.509 got support for multiple policy roots, bridges, and mesh
 solutions. You can even use it as a peer to peer system, but this is not
 very common.
 
 2.1 Type of certificates
 ========================
 
 There are several flavors of certificate in X.509.
 
    * Trust anchors
 
      Trust anchors are strictly not certificate, but commonly stored in
      certificate since they are easier to handle then. Trust anchor are
      the keys that you trust to validate other certificate. This is
      done by building a path from the certificate you wan to validate
      to to any of the trust anchors you have.
 
    * End Entity (EE) certificates
 
      End entity certificates is the most common type of certificate. End
      entity certificates can't issue certificate them-self and is used
      to authenticate and authorize user and services.
 
    * Certification Authority (CA) certificates
 
      Certificate authority are certificates that have the right to issue
      other certificate, they may be End entity certificates or
      Certificate Authority certificates. There is no limit to how many
      certificates a CA may issue, but there might other restrictions,
      like the maximum path depth.
 
    * Proxy certificates
 
      Remember that End Entity can't issue certificates by them own,
      it's not really true. There there is an extension called proxy
      certificates, defined in RFC3820, that allows certificates to be
      issued by end entity certificates. The service that receives the
      proxy certificates must have explicitly turned on support for
      proxy certificates, so their use is somewhat limited.
 
      Proxy certificates can be limited by policy stored in the
      certificate to what they can be used for. This allows users to
      delegate the proxy certificate to services (by sending over the
      certificate and private key) so the service can access services on
      behalf of the user.
 
      One example of this would be a print service. The user wants to
      print a large job in the middle of the night when the printer
      isn't used that much, so the user creates a proxy certificate with
      the policy that it can only be used to access files related to
      this print job, creates the print job description and send both
      the description and proxy certificate with key over to print
      service. Later at night will the print service, without the help
      of the user, access the files for the the print job using the
      proxy certificate and print the job. Because of the policy
      (limitation) in the proxy certificate, it can't be used for any
      other purposes.
 
 
 2.2 Building a path
 ===================
 
 Before validating a path the path must be constructed. Given a
 certificate (EE, CA, Proxy, or any other type), the path construction
 algorithm will try to find a path to one of the trust anchors.
 
 It start with looking at whom issued the certificate, by name or Key
 Identifier, and tries to find that certificate while at the same time
 evaluates the policy.
Info Catalog
(hx509.info.gz) Introduction
(hx509.info.gz) Top
(hx509.info.gz) Setting up a CA
automatically generated byinfo2html