Express YourSelf !

entity = computer | user

Every entity has identity

Authentication is verification of claim by entity

======================================

Hash function: same input => same output. If input is different by even a bit, output is completely different. They are one way. MAC (Message Authentication Code) is hash function. MAC needs common key. 

Signature is similar but uses key pair.  If only one entity knows the private key you get a property called non-repudiation: the private key holder can't deny (repudiate) the fact that they signed some data.

sign with private key. verify with public key. 

encrypt with public key. decrypt with private key

public key cryptography = asymmetric cryptography, as above

=====================================

subscriber or end entity is subject of certificate

CA is issuer of certificate

CA has root certificate | intermediate certificate

end entity has leaf certificate

relying party trust CA and verify certificate.

relying parties are pre-configured with a list of trusted root certificates (or trust anchors) in a trust store. Root certificates in trust stores are self-signed . Trust store by 4 major organization

1. Apple's root certificate

2. Microsoft's root certificate programm

3. Mozila's root certificate programm

2. Google's root certificate programm

Cloudflare's cfssl project maintains a github repository that includes the trusted certificates from various trust stores. https://github.com/cloudflare/cfssl_trust

=======================================

Certificate : issues says entity (subject) has public key

X.509, ASN.1, OIDs, DER, PEM, PKCS

X.509 builds on ASN.1. ASN.1 : DER (Binary) and BER

PEM: base64 encoded DER payload sandwiched between a header and a footer

Possible extension for PEM: .der, .pem, .crt, .cer

======================================

PKCS (Public Key Cryptography Standards) published by RSA labs

• * PKCS#7 is rebranded as Cryptographic Message Syntax (CMS) is by IETF. It is used by Java.

Possible extension for PKCS#7: .p7b, .p7c

• * PKCS#12 = certificate chain + private key

It is used by microsoft products

Possible extension for PKCS#12: .pfx, .p12

So possible formats for PKCS#7 and PKCS#12 are : raw der, pem, ber

raw der is most widely used.

• * PKCS#8 is for private key and its metadata

Possible extension for private key: .prv, .key, .pem

Possible extension for public key: .pub, .pem

They may includes headers: Proc-Type, DEK-Info

• * PKCS#10 is CSR

====================================

• SSH: certificate less PKI .It binds names to public key in files
• PGP: uses certificate, but not CA. It uses web-of-trust model
• Web PKI (Internet PKI or PKIX) works with browser.  no control over important details like certificate lifetime, revocation mechanisms, renewal processes, key types, and algorithms

=====================================

Bundle of certificate: root intermediate leaf - forms certificate chain. More often, certificate chains are encoded as a simple sequence of line-separated PEM objects. Some stuff expects the certs to be ordered from leaf to root, other stuff expects root to leaf, and some stuff doesn't care. The relying party verifies the leaf and intermediate certificates in a process called certificate path validation.

=====================================

PKIX originally specified to use FQDN in DN common name. The modern best practices is to leverage SANs. There are four sorts of SANs in common use, all of which bind names that are broadly used and understood: domain names (DNS), email addresses, IP addresses, and URIs.

=====================================

• To configure a PKI relying party you tell it which root certificates to use
• To configure a PKI subscriber you tell it which certificate and private key to use (or tell it how to generate its own key pair and exchange a CSR for a certificate itself)