Why PKI?

PKI is the only technology that extends trust beyond the enterprise with no a priori relationship between the trusted parties
President Bush (2007):

US Agencies will undertake a Federal Public Key Infrastructure
(PKI) to promote digital signatures for transactions:
parties.
* within the federal government,
* between government and businesses and
* between government and citizens

Key Distribution








Public Key Infrastructure (PKI) provides the means to bind public keys to their owners and helps in the distribution of reliable public keys in large heterogeneous networks. NIST The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke Public Key Certificates based on public‐key cryptography.

The core components of a PKI include:
* The End‐Entities (EE)
* The Certificate Authority (CA)
* The Certificate Repository (CR)
* The Registration Authority (RA)
* Digital Certificates (X.509 V3)

PKI Key Distribution










Digital Certificate X 509 V3

• Is a person really who claim?
• How do you know that the public key you got from a person really bellongs to this person?
• Solution: CERTIFICATE - like an Information Highway Driver Licence

CERTIFICATE CONTENT

Base Certificate Fields
[PKIX] and [X.509] mandate inclusion of most base certificate fields:
1. Version
• To date, there have been three versions of the syntax for public‐key certificates
defined in [X.509]. The only version that allows extensions to be included in certificates is version 3.
• Because of the key role extensions play in determining the trustworthiness of a
certificate and the appropriateness of a given certificate to a particular transaction, all certificates should now be issued as version 3 certificates.
2. Serial Number
• The only requirement placed on serial numbers by [X.509] is that the value be a
unique integer for each certificate issued by a given CA.
• The combination of serial number plus certificate issuer name provides a unique
identifier for each certificate.
• In order to avoid any interoperability issues with systems that may not support
negative integers in this field, it is recommended that the values of the serial number be assigned starting with the integer “1” and increasing by the value of “1” for each subsequently issued certificate.
3. Signature
• This field contains the identifier for the algorithm used by the CA to sign the
certificate It must contain certificate. the same algorithm identifier as the signatureAlgorithm field in the Certificate ASN.1 sequence.
• For interoperability reasons, it is recommended that these fields be populated with
the algorithm identifier for the RSA PKCS #1 Version 1.5 or 2.1 signature algorithm
along with the appropriate SHA hash function for the desired security level
• All certificates should be signed by CA public keys that are 2048 bits long and the
signatures should be created using the SHA ‐256 hash function.
•While there are no known attacks on the RSA PKCS #1 Version 1.5 algorithm, some
high security applications may wish to use the RSA‐PSS (version 2.1) algorithm which
has more attractive security characteristics.
• Similarly, some applications may want to use the ECDSA signature algorithm, which
uses elliptic curve cryptography, because of the performance advantages that it
provides at high security levels.
4. Issuer/Subject
• These fields contain the Distinguished Name (DN) of the certificate issuer and the
certificate subject respectively.
• There are two schemes for formulating DNs that are generally used. The geopolitical
name scheme formulates DNs based on the geographic location of the entity
combined with organizational and/or personal attributes. For example, a U.S. based
organization might choose to name its CA “ou=ABC CA; o=ABC; c=us”. In some
countries there is a national registration authorities set up to register organization names. If the geopolitical name scheme is used, it is recommended that the organization name be registered with such an authority to ensure uniqueness.
• This name scheme is most applicable to environments where there is an existing
LDAP or X.500 directory infrastructure in place that makes use of geopolitical names,
or where a national identity is important.
• If geopolitical names are to be used, it is recommended that, as a minimum, the DN
of a CA include the countryName attribute, the organizationName attribute and the
organizationalUnitName attribute.
5. Validity
• Both the notBefore and notAfter elements of validity need to be present in all
certificates. [X.509] allows these times to be represented as either utcTime or
generalizedTime, however [PKIX] requires that dates through the year 2049 be encoded
as utcTime and dates in 2050 or later be encoded as generalizedTime.
• Therefore, given that certificates are normally issued with a much smaller validity period than 45 years, all certificates should currently be issued with their validity periods in utcTime format. These times must be expressed as Greenwich Mean Time (Zulu) and be of the format (YYMMDDHHMMSSZ). If the value of “YY” is greater than or equal to “50”, this represents the year “19YY”. If the value of “YY” is less than “50”, this represents the year “20YY”.
• For most applications user certificate lifetimes will tend to be 1 or 2 years, and certainly less than 5 years. CA certificates will tend to be in the 5 to 10 year timeframe and root certificates will tend to be in the 10 to 20 year timeframe. If any certificate content needs to be modified during the validity period of a certificate, that certificate needs to be revoked and replaced with a new one. To balance the amount of time such certificates need to remain on CRLs, all profiles in this paper recommend a validity period of 2 years for user certificates, 5 years for subordinate and cross‐certificates and 10 years for hierarchical root certificates.
6. Subject Public Key Info
• This field is used to carry the public key and identify the algorithm with which the key is used. For interoperability, this field should contain the algorithm identifier for RSA public keys, rsaEncryption. The parameters field has value NULL for this algorithm. This algorithm identifier is used in public key certificates for both RSA signature keys and RSA encryption keys. The intended application for the key will be indicated in the key usage field.
• Given the validity periods in these profiles, user keys should be 1024 bits long and CA keys should be 2048 bits long. The OID for rsaEncryption for these keys is {iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs‐1(1) 1}. This recommendation is common to all profiles in this paper. Certain high security applications may wish to restrict the use of the RSA public keys to the RSA‐PSS algorithm (for signature) or RSA‐OAEP (for encryption).

Digital Certificate Example

I'm reading: Why PKI?