PKI

Question 1

Definition of PKC. Which security properties can it achieve?

Answer 1

A PKC is a data structure to securely bind (with the signature by an authority) a public key to some attributes (being employed in the transaction that is protected by the PKC).
It is important to achieve non-repudiation of a digital signature which normally has only data integrity and authN.

Question 2

How can the key pair of a PKC be generated/stored?

Answer 2

The key pair has to be protected both when stored and when used.

The key pair could be generated:
* in a SW application -> needed trust in the platform
* in a. dedicated. HW -> difficult to update and to do vulnerability patching
* in SW and then injected in trusted device -> good for encryption key recovery

Question 3

PKI actors

Answer 3

• Certification Authority: generates, revokes and suspends certificates + publishes PKCs and infos about their status
• Registration Authority: helps the CA to verify claimed identity and attributes and to authorize the CA to issue or revoke a certificate
• Validation Authority
• (unofficial) Revocation authority: can be RA or CA and must be up 24/7 to timely revoke a compromised certificate

Question 4

Certificate generation

Answer 4

There are multiple possibilities after the key pair generation:
* the secret key is stored in a secure way by the user and the public key is sent to the CA with some claimed attributes -> the user is redirected to the RA to which it identifies itself -> the RA confirms to the CA and takes responsibilities in case of mistakes -> the CA issues the PKC, publishes it in a repository while the user stores it together with the secret key (like in a smart card)
* the RA generates the key pair, obtains a PKC and distributes the key pair + PKC on a secure device
* the user first visits the RA and gets a code = MAC (K, ID) where K is a shared key between CA and RA, then it uses it to get a PKC from the CA

Question 5

How many attributes can be bound to a PKC?

Answer 5

A PKC is bound to a single public key but it can be bound to multiple attributes.

Question 6

Versions of X.509 PKC

Answer 6

v1 and v2
Invented to protect OSI networks and make them more usable.

v3
Extensions were added together with attribute certificates which are used to assign attributes and not idenitties allowing to not disclose personal informations.

Question 7

Context of X.509 PKC

Answer 7

X.509 PKC is part of the X.500 standard, which provides the foundation for directory services used to hierarchically store and reteieve infos about entities in a distributed network.
Each entry in the hierarchical tree has a DN that is the result of the concatenation of the Relative DNs along the path to reach it.

The organization from top to bottom is:
* root
* country
* organization
* organization unit
* individual/resource

This standard defines the Directory Access Protocol which i used to query, modify, manage entries of the tree.

The issues are:
- lack of CA policies
- lack of a proper X.500 infrastructure
- difficult to establish the certification path among entities

Question 8

X.509: CP and CPS

Answer 8

CA liability may be limited in specific applications or purposes, as specified in the CA policies.

We have:
* Certificate Policy (CP): a. set of rules that indicate the applicability of the PKC to a particular application; it defines minimum requirements and can be followed by different CAs
* Certification Practice Statement (CPS): it is about the practices of a specific CA so it is about one particular CA only and about its implementation details. For example it contains the internal processing time to know when the next CRL will be published.

Question 9

Who is the TTP in the X.509 context?

Answer 9

CA

Question 10

RFC-1422: what is it about, what does it define and which issues does it have?

Answer 10

RFC-1422 envisioned a single hierarchical certification infrastructure for the entire world. This hierarchy was rooted at the Internet Policy Registration Authority (IPRA), which was the sole root CA. Below IPRA, there were special Certification Authorities (CAs) called Policy Certification Authorities (PCAs), which established the policies for issuing certificates. The actual CAs were positioned below the PCAs, and each CA was required to conform to a naming convention known as name subordination.

IPRA certified PCAs, which in turn issued certificates following predefined policies. The primary policies defined by RFC-1422 were:
- high assurance: to get a PKC under this policy 2-photo ID docs and a DNA test are needed
- mid-level assurance: one documment needed
- residential: PKCs issued base on the residence of the requestor
- persona: Derived from the Latin word persona (mask), this policy allowed for anonymous certificates. Such certificates did not contain personal identifiers (e.g., name or address). Instead, they included a pseudonym (e.g., Anon#37), ensuring the user’s actions were traceable to the same pseudonymous identity without revealing their real identity

The RFC-1422 hierarchy ultimately failed due to political and operational challenges:
* The single root CA (IPRA) created a single point of failure and immense political controversy over which entity (e.g., USA, China, India, Russia) should manage it. Control over IPRA allowed the creation of fake certificates for any entity, undermining trust in the entire system.
* The hierarchical structure was too rigid, limiting the flexibility of certificate management.

Question 11

X.509v3: extensions types and what is a certificate profile

Answer 11

• public: defined by the standard and public to anyone -> anyone can understan them
• private: belonging to a closed community
• critical: unrecognized critical extensions MUST be rejected
• non-critical: MAY be rejected if not understood.

Profile = set of extensions for a specific purpose

Question 12

X.509v3: base syntax of a PKC

Answer 12

A X.509 Certificate is a data structure that contains a SEQUENCE of data:
~~~
Certificate ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
tbsCertificate TBSCertificate,
signatureValue BIT STRING
}
~~~

The TBSCertificate data type represents a data structure that contains a SEQUENCE of data as well:
* version: by default it starts from 0, so, if it’s 2 it corresponds to X.509v3;
* serialNumber: unique number for the certificate issuer;
* signature: the algorithm used to sign the certificate;
* issuer: the entity that issued the certificate;
* validity: the period of time for which the certificate is valid;
* subject: whoever is in control of the private key associated to the public key in the certificate;
* subjectPublicKeyInfo: information on the public key of the certificate;
* issuerUniqueID: nowadays deprecated (that’s why it’s OPTIONAL), unique world wide identifier for the certificate issuer;
* subjectUniqueID: same as issuerUniqueID but for the subject instead;
* extensions: if any extension is present (optional), the certificate version must be v3

Why is the AlgorithmIdentifier present in both the Certificate and the TBSCertificate? This re-dundancy ensures that the algorithm used for certification matches the externally declared algorithm. If they differ, the certificate is deemed invalid. This acts as a security measure to prevent attacks such as the “signature substitution attack.”

Both issuer and subject fields can only be Distinguished Names (DNs).

Question 13

X.509v3: list of public extensions classes

Answer 13

Public extensions are those defined in the standard that everyone should understand. These extensions are divided into four classes:
* Key and policy information: This includes details about the key and the policies that the certificate follows.
* Certificate subject and certificate issuer attributes: These provide more information about the subject and issuer of the certificate.
* Certificate path constraints: This defines the sequence of certificates from the root to the certificate in question.
* CRL distribution point: These extensions identify where the Certificate Revocation List (CRL) can be obtained.

In many cases, the term EE (End Entity) is used to refer to the entity at the end of the certification hierarchy, which possesses both the public and private keys.

Question 14

What is a DN?

Answer 14

Hierarchical sequence going from the top down to the level of the entity that controls the key.

Question 15

X.509v3: alternative names

Answer 15

– rfc822Name: it’s just an email address; useful if you want to use the certificate to protect your email;
– dNSName: it’s a Fully Qualified Domain Name (FQDN);
– iPAddress: important for routing security to certify that a specific node, controlling a private key, has that specific IP address;
– uniformResourceIdentifier (URI): grants the possibility to assign different keys to different (active) web pages hosted on the same server.
– directoryName: useful if you’re using a directory with a different syntax
– X400Address: it was the old OSI email
– ediPartyName: EDI (Electronic Data Interchange) is a way in which companies transfer from each other electronic data that are relevant for their business. The purpose of EDI is to send a message which can be understood and processed directly by computers. EDI parties interact with EDI and they’re identified by ediPartyName;
– registeredID: any other kind of official registry name, e.g., VAT number (which uniquely identifies a com-
pany);
– otherName

Question 16

IETF-PKIX extensions

Answer 16

While the use of private extensions is generally discouraged due to a lack of interoperability, there is one notable exception: the IETF-PKIX has defined three extensions for the Internet user community.These extensions are now considered public because they adhere to widely known Internet standards.

The following PKIX private extensions are defined:
* Subject Information Access (SIA)
* Authority Information Access (AIA)
* CA Information Access (CAIA)

Question 17

RFC-2459

Answer 17

RFC-2459 defines the profile of X.509v3 certificates as suggested by PKIX for use in Internet applications (e.g., IPsec, TLS, S/MIME). This document provides guidelines for ensuring interoperability when using X.509 certificates with standard Internet mechanisms.

The extensions are defined using an OID having as base the PKIX OID.

RFC-2459 also provides implementation suggestions to ensure consistency and compatibility across systems, for example a Validity Period: Certificates must include a validity period (from-to) specifying their active time frame using UTC time (Universal Time Coordinated).

• UTCtime avoids issues with time zones when validating certificates.
  – Seconds must always be included.
  – Certificates must use Zulu time (GMT, denoted by the suffix Z) to ensure global compatibility.
  – When the year is written with two digits, it is assumed to be in the range 1950-2049.

Question 18

RFC-3279 and additions

Answer 18

RFC-3279 specifies the algorithms that MUST be supported by applications using the RFC-3280 profile. It includes both modern and older algorithms.

Question 19

RFC-3280 and RFC-5280

Answer 19

The RFC-3280 and its successor RFC-5280 define the PKIX profile. This profile specifies not only the values and fields but also the algorithms and procedures to ensure that certificates are processed consistently worldwide.

• Path Validation Algorithm: algorithm for validating a certificate chain. When an End-Entity (EE) certificate is issued, it is signed by a Certification Authority (CA). This CA may itself have a certificate issued by another CA, continuing up to the root CA. The RFC specifies how to construct and verify this chain.
• Certificate Status Verification: Specifies the algorithms for verifying the status of a certificate by using a basic or full Certificate Revocation List (CRL) or by using a Delta-CRL, which contains only the differences with the last full CRL.
• Extended Key Usage: Adds the OCSPSigning purpose for certificates used in Online Certificate Status Protocol (OCSP) responses.
• Extensions for Certificates: Inhibit Any-Policy (ensures that the CA explicitly specifies its policy), Freshest CRL: Provides a pointer to a Delta-CRL, which contains only the differences compared to the basic CRL, Subject Information Access
• Freshest CRL in CRL Context: The Freshest CRL extension applies not only to certificates but also to CRLs. This allows the retrieval of differences from the last full CRL when a Delta-CRL is available.
• Delta CRL Distribution Point: Specifies a distribution point for Delta-CRLs. This extension follows the same syntax as CRL Distribution Point and can be included either in a certificate or in a CRL. However, it must not be present in a Delta-CRL itself, ensuring that a Delta-CRL always represents the difference between a base CRL and its updates (i.e., no “delta of delta”). This extension is always marked as non-critical, as multiple methods for verifying the status of a certificate are available (e.g., full CRL, Delta-CRL, OCSP), and no single method can be universally mandated.

Question 20

PKC revocation: when does it happen and how is it performed?

Answer 20

A certificate may be revoked before its natural expiration for several reasons:
* Upon request of the certificate owner: Key compromise or Key loss
* Upon request of the certificate sponsor: The sponsor (e.g., an organization) may request re- vocation.
* Autonomous action by the issuer (CA): The issuer may revoke a certificate due to an error, such as issuing a wrong certificate by mistake, or a fraud, where the certificate was obtained under false pretenses.

Question 21

X.509 CRL: generalities

Answer 21

The Certificate Revocation List (CRL) is a list of revoked certificates, where each entry includes the revocation date and the reason for revocation.

CRLs are issued periodically and maintained by the certificate issuers. This process requires re-issuing a CRL even when no changes have occurred, to assure the relying party of its freshness.
This periodic reissuance is necessary to prevent replay attacks, where an attacker could present an old signed CRL as if it were a new one. To mitigate this risk, the security policy of each CA specifies the lifetime of a CRL.

CRLs are digitally signed by the CA that issued the certificate or by a delegated revocation authority (RA). In cases where the CRL is not directly issued by the CA, it is referred to as an indirect CRL (iCRL). This means that the CRL is neither created nor signed by the issuer itself, but rather by its delegate.

For an RA to sign an iCRL, it requires a certificate with the Key Usage (KU) field set to CRLSign. This field certifies that the RA has been authorized by the issuer to sign the CRL. Without this authorization, anyone with the appropriate signing capabilities could sign a CRL, compromising its integrity. In this context, the CRLSign field also functions as an authorization mechanism.

Question 22

X.509 CRL: structure

Answer 22

• tbsCertList
• signatureAlgorithm: The algorithm used to sign the CRL.
• signatureValue: The signature of the CRL.

Inside the tbsCertList we have:
* version (optional)
* signature: the signature algorithm is repeated inside TBSCertList to avoid attacks;
* issuer: the entity (usually a CA) that issued the CRL;
* thisUpdate: date and time when the CRL was created;
* nextUpdate: a promise from the CA that the next CRL will be published before this date;
* revokedCertificates: A sequence where each entry contains the serial number of the revoked certificate and the revocation date;
– userCertificate: Identifies the revoked certificate (CertificateSerialNumber).
– revocationDate: The date and time the certificate was revoked.
– crlEntryExtensions: Extensions for the individual revoked certificate entry.
* crlExtensions: extensions for the whole CRL;

Question 23

X.509 CRL: extensions

Answer 23

crlEntryExtensions
– reasonCode: A code that specifies the reason why the certificate has been revoked (e.g., keyCompromise).
– Hold Instruction Code: The PKIX group suggests not using this extension, but military organizations use it to “block” a certificate when its subject is not operative. To achieve this, the certificate is added to the CRL as if it were revoked but marked as “on hold”. When the subject becomes operative again, another CRL is published where the certificate is marked as “off hold”. If someone needs to verify whether the certificate was valid during a specific period, they must download all CRLs published in that period to check its “hold on/hold off” status.
– InvalidityDate: Specifies the date on which the private key is known or suspected to have been compromised, or when the certificate otherwise became invalid. This date may be earlier than the revocationDate in the CRL entry, which represents the date the CA processed the revocation.
– CertificateIssuer: Identifies the certificate issuer associated with an entry in an indirect CRL. This extension includes one or more names from the issuer field and/or the IssuerAlternative Name (IAN) extension of the certificate corresponding to the CRL entry. It binds the certificate serial number to the CA.

crlExtensions
- Authority Key Identifier: Points to the public key corresponding to the private key used to sign the CRL.
– Issuer Alternative Name: Allows additional identities to be associated with the issuer of the CRL.
– CRL Number: Conveys a monotonically increasing sequence number for a given CRL scope and issuer. This extension helps users determine when one CRL supersedes another and supports iden- tifying complementary complete CRLs and delta CRLs.
– Delta CRL Indicator: A critical CRL extension that identifies a CRL as a delta CRL.
– Issuing Distribution Point: A pointer to the location where the latest update of the CRL can be downloaded.

Question 24

X.509 CRL: certificate revocation timeline

Answer 24

0. The certificate is valid and it’s not included in the last CRL (CRL n);
1. Key compromise event: the subject loses control over the private key;
2. Cert revocation request: the subject asks for the certificate to be revoked and identifies himself to the CA.
   The time when the key compromise event occurred corresponds to the invalidityDate field (CRL entry extension). The subject must demonstrate, in case of legal dispute, that he lost control over the key at that time;
3. Cert revocation time: the certificate is officially revoked by the CA but it will take some time before this change
   is made public, i.e., before a new CRL containing that certificate is issued. This time depends from the processing time of the CA (time spent to create the new CRL and publish it).
   The certificate revocation time corresponds to the revocationDate field of revokedCertificates of TBSCertList. The CA will proof that it identified the subject and it followed all necessary procedures to perform the revocation;

Attacks:
* If an attack is performed during the red period, it will be successfull since the relying party (RP) will have no way to check if the certificate’s private key has been compromised (because CRL n + 1 hasn’t been published yet);
* If an attack is performed during the yellow period, it could be successful…unless the RP is cautious enough. As a matter of fact, since the internal processing time of the CA should be specified in the Certificate Practice Statement (CPS), e.g., “the CA guarantees that, as soon as it receives and validates the revocation request, CRL n + 1 will be published within 15min”, the RP could wait that specific amount of time, to see whether a new CRL is published or not and, if so, if that CRL contains the received certificate;
* If the certificate was valid at the Time of Signature (ToS), it doesn’t matter if, at the Time of Verification (ToV), it appears as “revoked”! Note that (IMPORTANT):
– If Time of Signature < Time of Verification
∗ CRL is useless unless you can demonstrate and tell with precision when was the ToS;
∗ the ToS cannot be self-declared;
– If ToS = ToV
∗ e.g., the key’s being used to perform an asymmetric challenge-response NOW;
∗ no problem…just download the newest CRL and check if it contains the certificate;

Question 25

X.509 CRL: maintainance issues

Answer 25

Certificate Revocation Lists (CRLs) can grow very large, as they include all certificates revoked up to a certain date. This size increase makes them costly to download and examine. Several strategies exist to manage this efficiently:

1. Eliminating revocations after the certificate’s expiration date: this approach involves removing the revoked certificate entry in the first CRL issued after the certificate expires. However, this method has significant drawbacks: let’s say a certificate was valid until 12/31, but it was revoked on 10/5. If the CRL is updated after the certificate’s expiration date, the revocation entry for this certificate will be included only in that specific CRL (after the certificate has expired). Once the certificate expires, it will be removed from future CRLs, even though it was revoked before its expiration. This means that subsequent CRLs will not show its revocation, which creates problems for validating past signatures or transactions.
   Consider a scenario where a student, John, receives a grade on a specific date, and a signature is created for it. This signature needs verification during graduation, which occurs at a later time. If the revocation entry has been deleted, there is no way to confirm its validity unless past CRLs are archived.
2. Publishing a complete CRL followed by deltas: a Certificate Authority (CA) generates a base CRL (e.g., CRL number N) and subsequent delta CRLs that contain only the differences from N. To verify a certificate, one must download the base CRL and all subsequent deltas until the next
   base CRL. While this approach speeds up downloads, it requires additional processing to reconstruct the full CRL.
3. Partitioning the CRL into groups using CRLDP: the CRL Distribution Point (CRLDP) extension in certificates allows partitioning CRLs into smaller subsets. This method enables a CA to manage multiple smaller CRLs instead of a single large CRL. However, to obtain all revoked certificates for a CA, all CRLDP partitions must be downloaded. The implementation of CRLDP varies across CAs, guided by their Certificate Policies (theoretical principles) and Certificate Practice Statements (practical implementations).

Question 26

OCSP: generalities and sources of information

Answer 26

OCSP is a client-server protocol used to verify the validity of a certificate at the present moment. Its primary limitation is that it cannot provide information about a certificate’s status in the past.

OCSP provides a digitally signed response regarding the certificate’s validity. Possible responses include:
* Good: The certificate is valid.
* Revoked: The certificate has been revoked, with additional information such as revocationTime and revocationReason (similar to CRL).
* Unknown: The server cannot provide information

To ensure authenticity and prevent fake responses, OCSP responses are signed by the responder (server). The signature certificate of the OCSP server cannot be verified using OCSP itself. Most often, OCSP operates over HTTP or HTTPS, adding additional security. However, even with HTTPS, the response’s signature ensures its integrity, independent of TLS.

It’s possible to obtain information from:
* (public) CRL repositories;
* direct access to CA database which lists the revoked certificates;
* colleague OCSP server (OCSP servers can be chained): in case the first server doesn’t know the answer, it will ask the colleague;

Question 27

OCSP requests and responses

Answer 27

Request
* Protocol version
* list of certIDs: it is possible to request information regarding one or multiple certificates.
* Extensions (optional, MAY be processed or ignored).

Each certificate is identified by its certID:
– hashAlgorithm (AlgorithmIdentifier);
– issuerNameHash (hash of the Issuer’s DN);
– issuerKeyHash (hash of the Issuer’s public key);
– serialNumber (CertificateSerialNumber).
For privacy reasons, the CA (Issuer) name is not included in cleartext but is hashed. An OCSP responder maintains a list of CAs it can manage. If the hash of a CA name matches an entry, the responder can provide an answer.

Response
– Version of the response syntax;
– Name of the responder;
– list of SingleResponses;
– Extensions (optional);
– Signature algorithm OID;
– Signature computed across the hash of the response.

The response contains a SingleResponse for each certificate in the request:
– certID;
– certStatus (good, revoked, unknown): if revoked it includes revocationTime (mandatory) and may include revocationReason (optional).
– thisUpdate: Specifies the time at which the information carried by the OCSP response is based
– nextUpdate (optional): Specifies the time interval after which a “fresher” response can be obtained by querying the OCSP server again.

Question 28

Models of OCSP responder

Answer 28

There are three models of OCSP responders:
* CA Responder: OCSP server operated by the CA, which signs the responses with its own private key => risk of exposing the private key since it’s used for an online service (if it’s online it can be attacked). Moreover, the CA private key is used for signing both certifcates and OCSP responses. So, this approach is rarely adopted;

• Designated Responder (also Authorized Responder): the OCSP server signs the responses with a pair key:cert which is different based on the CA it is responding for. The OCSP server is delegated by the CA to provide OCSP answers and certificates must contain extendedKeyUsage OCSPSigning, which testifies the CA has authorized the OCSP server to provide answers on her behalf.
  TTP operated / paid by the CA.
• Trusted Responder: the OCSP server signs the responses with a pair key:cert independent of the CA it is responding for.
  TTP (Trusted Third Party) paid by the users;

Question 29

OCSP issues

Answer 29

Replay attack:
– (attack) copy response (valid certificate) and replay it after that certificate is revoked;
– (defense) client may insert a nonce (need id-pkix-ocsp-nonce extension) in its request, to be included in the data signed by the server;

DoS attack:
– (attack) flood the server with many requests, since each one requires a real-time on-line digital signature (computing signatures is a costly operation);
– (defense) pre-compute responses, with three timestamps (risky!): thisUpdate, nextUpdate, producedAt (specifies when the OCSP response was produced);
- it opens door for replay attacks, as a precomputed response cannot contain a specific nonce;

So, it’s not possible to have protection against both replay and DoS attacks because applying one protection means leaving room for the other category of attacks to take place;

Question 30

POP: why is it needed

Answer 30

Proof of Possession gives the CA sufficient guarantees that the Subject requiring a PKC really possesses the private key it is requireing a certificate for.

The issuance of certificates without POP allows various attacks. Let’s consider a scenario where the CA doesn’t require POP:
1. Alice generates her key pair, stores her private key locally and sends her public key to the CA along with the identifier she wants to put in the certificate;
2. The CA creates the certificate and binds Alice’s public key to her identity;
3. Bob sends a request for certification by using Alice’s public key: it may seem useless, since Bob doesn’t know Alice’s private key (he can’t perform signatures), however…
4. The CA issues the certificate to Bob => now there are two certificates with the same public key (Alice’s) but with different subjects (Bob and Alice);
5. Let’s now suppose Alice signs a document. The following two attacks are possible:
* Bob can claim to be the one who signed the document, since he has a certificate with Alice’s public key;
* if Alice discovers that Bob has a certificate with her public key, she can repudiate her signature, i.e., she can deny to have signed the document and she can claim Bob did;
There’s no way to tell who’s telling the truth!

Question 31

PSE

Answer 31

A Personal Security Environment (PSE) is essential for protecting private keys and ensuring the authenticity of trusted root CA certificates.

There exist:
* Software PSE: Typically an encrypted file containing both the private key and trusted root CA certificates. Although root CA certificates do not require encryption, they are often encrypted along with the private key.
* Hardware PSE - Passive: Functions as secure storage for keys, similar to a software PSE but in hardware (e.g., a USB drive).
* Hardware PSE - Active: Protects keys and performs cryptographic operations using those keys.

Both software and hardware PSEs support mobility, enabling the use of keys in different environments. However, this introduces challenges, which are partially addressed by standards such as FIDO for asymmetric key pairs.

Question 32

PKI models list

Answer 32

• Hierarchical
• Mesh
• Bridge

Question 33

Solutions if PKC mistakenly issued or compromised CA

Answer 33

It’s difficult for domain owners to detect certificates fraudulently issued for their domain (servers).

Browsers aren’t good at rapidly detecting malicious websites if they receive (e.g. in a TLS connection) mistakenly issued certificates or certificates issued by a compromised CA.
When these situations occur, it takes time to detect the problem, revoke the certificates and make the browser aware.
Until then…browser users think that they are visiting an authentic site and/or the connection is secure but instead it could be subjected to:
– fake server;
– MITM attacks;

Solutions:
- HTTP Key Pinning
- Certificate Transparency

Question 34

HTTP Key Pinning

Answer 34

HPKP provides protection against fake web site trying to impersonate the real site by using fraudulently obtained PKC but it has been deprecated in favour of Certificate Transparency.

It’s an HTTP extension defined in the RFC-7469 where:
* an HTTPS site specifies the digest of its own public key and/or **one or more CAs in its chain **(but the root!)
* then the User Agent (UA) caches the key and refuses connecting to a site with a different key: it’s a TOFU (Trust On First Use) technique (risky!), dangerous when loosing control of the key and gves problems with key updates: always include at least one backup key

The header permits also to specify a URI to report violations:
* used to inform the legitimate server owner that another server with the same name but a different public key has been found;
* if the UA performs pin validation and fails to find a valid SPKI (SimplePublic Key Infrastructure) fingerprint in the served certificate chain, it will POST a JSON formatted violation report to the host specified in the report-uri directive containing details of the violation;

This can be used in enforcing or report-only mode (a different URI is provided for each mode):
* enforcing mode: the suspicious web site is reported and an error message is shown to the user: the user can’t connect to the web site;
* report-only: the suspicious site is reported but no error is shown to the user: the user can connect to the web site if she’s willing to;

Question 35

Certificate transparency: what is it

Answer 35

The main ideas of Certificate Transparency are:
* to make impossible or very difficult for a CA to issue a PKC for a domain without making it visible to the domain owner
* if this happen, let the domain owner know about the fraudolent certificate
* provide an open auditing (to verify when certificates are created) and monitoring (to verify if certificates are legal)
* protect users from these certificates

CT framework is composed of several actors:
* Submitter;
* Loggers;
* Monitor;
* Auditors;

The CT framework requires all TLS certificates to be registered into a log;
If a certificate has not been registered in a log, it’s a sign that the certificate is suspect, and TLS clients may refuse to connect to servers that have suspect certificates.

Currently:
- 6 log servers: CloudFlare, Google, Let’s Encrypt…
– 10 public monitors: CloudFlare, Facebook, …

Question 36

Certificate transparency: actors

Answer 36

Submitter
They are the ones that submit certificates (or partially completed certificates) to a log server and receive a SCT.
Anyone can submit a certificate to a log server, although most certificates will be submitted by CAs and server operators.

Loggers
The logger provides each submitter with a promise to log the certificate within a certain time window: such promise is represented by a Signed Certificate Time-stamp (SCT). The SCT accompanies the certificate throughout its lifetime (proof that the certificate has been submitted to the logger).
Since SCT is not created by CAs, but directly from Log servers, it must be delivered somehow with the certificate. How is the SCT delivered with the certificate (created by the CA)?
* X.509v3 extension
* TLS extension;
* OCSP Stapling;

Every issued certificate is logged, so there will be around the world several log servers. These servers maintain a secure log of TLS certificates.

Security here is guaranteed by:
* Append-only: certificates can only be added to a log (cannot be deleted, modified, or retroactively inserted into a log).
* Cryptographically assured: protected by Merkle Tree Hashes (provide integrity and authentication) to prevent tampering and misbehaviour.
* Publicly auditable: anyone can query a log (via HTTPS GET and POST) and verify that it’s well behaved, or verify that a TLS certificate has been legitimately appended to the log.

Monitor
It is a public or private service that watches for misbehaving logs or suspicious certificates and periodically contacts and downloads information from log servers and then inspects every new entry, keeps copies of the entire log and verifyies the consistency between published revisions of the log.
This last mechanism is used to avoid the substitution attack: if there is a certificate log today, and another one of the previous weeks, since new entries can only be appended, the log should increase with all the previous data being present. If someone completely remove logs and replace it with fake ones, it is possible to detect it because of that copy of the log of previous week.

Auditors
Certificate Auditors are lightweight software components that perform two functions:
– verify overall integrity of logs: periodically fetch and verify log proofs (signed cryptographic hash which a log uses to prove it’s in good standing)
– verify that a particular certificate appears in a log

If a TLS client determines (via auditor) that a certificate is not logged, it can use the SCT from the log as evidence that the log has not behaved correctly. Auditors and monitors exchange information about logs through a “gossip protocol”.

Question 37

Certificate transparency: possible CT system configurations

Answer 37

Note that there are only an examples, because the general certification of CT does not prescribe any particular configuration to follow

Configuration 1
A monitor, that is inside the CA, watches logs for suspicious certs (certificates issued in the name of the CA but not by the CA itself) and verifyies that all logged certs are visible.
If not all logged (regularly issued) certificates are visible (e.g., an attack successfully cancelled some certificates from the log), clients experience DoS (since certificates are not in the log they don’t connect to the web servers);

A cert owner (server) can query the monitor to verify there are no illegitimate certs logged for its domain: monitors return all logged certificates for example.com.

The auditor, that is inside the client, verifyies that logs are behaving properly and can also verify that a particular certificate has been logged. Even after receiving the SCT the browser may still check with the log server that the SCT itself is logged and everything’s fine (the SCT could be fake, since it’s just a signed element);

Monitors and auditors exchange info about logs to detect forked/branched logs;

Configuration 2
Monitor and Auditor are external entities which get paid to provide a service. This permits to minimize the environmental software change on CAs and web browsers. However, browsers should support anyway extensions for SCT. Now monitor and auditor talk with the log server and accept requests by all interested parties.

Question 38

ACME: generalities

Answer 38

Let’s Encrypt is the only CA offering valid certificates that are automatically recognized by browsers with- out charging fees. The costs of this service are covered by donations. The key of operating a free CA was to automate as much of the process as possible. This automation is defined by the ACME protocol (Automated Certificate Management Environment).

• protocol for PKC management between EE and CA;
• the managed key pairs are used for online services (network attacks are possible!);

If a key is being used for an online service, it can’t have an associate certificate for more than 1 year (they’re trying to reduce this time window to 6 months, or even 3 months) -> anagers of TLS servers must continuously create and install new certificates. This becomes really difficult if there are many servers, so that’s why ACME protocol was invented;
It allows PKC to be automatically requested and issued, without human interaction. ACME interactions are based on exchanging JSON documents over HTTPS connections.

To implement it an ACME agent (client) installed on a web server proves to the CA (Let’s Encrypt) that the server controls a domain (otherwise someone could request a certificate for another domain). Once the CA verifies this, it allows the client to request and install as many certificates as it wants.

Question 39

Key and Policy Information extensions

Answer 39

• Authority Key Ientifier: identifies a specific public key used to sign a certificate and to do so it uses the pair issuerName:serialNumber. It is NON-CRITICAL but it is really useful to build certificate chain or in applications that store the keys with this attribute
• Subject Key Identifier: identifies a specific public key used in an application. It is NON CRITICAL
• Key Usage: it identifies the application domain for which the pub key can be used. It can be both CRITICAL or NON CRITICAL; it if is critical it can only be used for the decided scopes
• Private Key Usage Period: NON CRITICAL and discouraged
• Certificate Policies: list of policies that were followed by the CA when the PKC was issued; the indication is done with OID, URI. text. It can be ** CRITICAL or NOT CRITICAL**
• Policy Mappings: indicates the correspondence of policies among different security domains and it is only present in CA certificates. It is NON CRITICAL

Question 40

Key Usage options

Answer 40

∗ digitalSignature (CA, user): It is valid to appear both in the certificate of the CA and in the certificate of a user because the CA performs the signing of certificates, while the user performs the signing of documents.

∗ nonRepudiation (user): only achieved if the following conditions are met: you need the key-pair, you must be the only one to control the private key, you need the certificate to attest your identity, and you have to use the key voluntarily. In asymmetric challenge-responses, the private key is automatically used for signing and so it can’t provide non-repudiation.

∗ keyEncipherment (user): This refers to generating a key and performing encryption with the public key, enc(pk, k). Someone can take the public key from a certificate and use it to encrypt another key that was used to encrypt the document. This value is valid only for users.

∗ dataEncipherment: Used when data is directly encrypted with the private or public key. There are no specific limitations (user, CA, or both), as this is quite unusual. Asymmetric encryption is typically slow, so it is not commonly used for direct data encryption, but it is possible.

∗ keyAgreement (encipherOnly or decipherOnly): This supports protocols like Diffie-Hellman, where there is an agreement. Diffie-Hellman parameters may be included, and it is possible to decide if these parameters are used for encryption or decryption (limited to one of the two).

∗ keyCertSign (CA): This is only for the CA: it is a permission to sign a certificate.

∗ cRLSign (CA): This is only for the CA: it is a permission to sign a Certificate Revocation
List (CRL).

Question 41

Certificate Subject and Certificate Issuer Attributes extensions

Answer 41

These extensions, NON CRITICAL, include:
* Subject Alternative Name: Allows the use of different formalisms to identify the certificate owner, which are more meaningful for specific contexts.
* Issuer Alternative Name: Allows the identification of the Certification Authority (CA) that issued the certificate or a CRL
* Subject Directory Attributes: Enables storage of additional attributes related to the certificate owner

Question 42

Certificate Path Constraints extensions

Answer 42

The certificate path is the chain that goes up to a trusted root. The extensions related to the certificate path constraints are:

• Basic Constraints (BC): indicates if the subject of the certificate can act as a CA. If BC=true then the subject is a CA and it can sign to create another level of certification. If BC=true, it is possible to define the maximum depth of the certification tree: a CA can create at most n levels of certification.
  It can be both critical or non-critical but it is strongly recommended to always mark this extension as critical to ensure a clear distinction between CA and EE. Omitting this extension might lead to an EE improperly acting as a CA, posing a significant security risk.
• Name Constraints (NC): it is included only in CA certificates and specifies the namespace that the CA can certify (same format as for Alternative Names). It includes at least one between: PermittedSubtree (i.e., whitelist) and ExcludedSubtree (i.e., blacklist). The Whitelist is processed first: If a format is unspecified in the whitelist (e.g., directoryName), it is implicitly permitted (use caution!).
  It is both critical or non-critical:
• Policy Constraints (PC): used by a CA to specify the constraints that could require an explicit identification by a policy or that inhibit the policy mapping for the rest of the certification path.
  While this extension is rarely used in practice, it can be either critical or non-critical depending on the implementation requirements;

Question 43

CRL distribution point Extension

Answer 43

The CRL Distribution Point is an extension in certificates that specifies where the Certificate Revocation List (CRL) related to a certificate can be downloaded.

Typically, it is considered non-critical to maintain compatibility with systems that do not fully support CRLs.

It provides a pointer to the location of the CRL, enabling verification of the certificate’s status.
The CDP can specify the location of the CRL using three main formats:
– Directory entry: points to a location in a directory, often as an LDAP URL (e.g., LDAP:entryName).
– E-mail: The certificate includes an e-mail address where a CRL can be requested by sending an e-mail with “CRL” as the subject. This approach is risky because CRLs can be very large, potentially exceeding attachment size limits (e.g., 64kB for basic mail servers, up to a few MB for others).
– URL: Provides a direct link to download the CRL automatically.

When a certificate containing a CDP is received, the pointer can be followed to retrieve the CRL. The CRL is then checked to determine if the certificate has been revoked.

Question 44

SIA

Answer 44

Subject Information Access: IETF-PKIX private extension
It specifies:
- a method (e.g., HTTP, LDAP) to obtain further information about the certificate owner
- a name that indicates the location (address, e.g., a URL, phone number) to reach to have these infos

Question 45

AIA

Answer 45

Authority Information Access (AIA): private extension of ITF-PKIX

Used for the certificates owned by the user (certificates whose issuer is the CA).

The AIA extension serves as a back-pointer that indicates how to access information and services of the CA that issued the certificate.
It includes:
* certStatus (e.g., URL to follow): can contain either the pointer to the CRL or the pointer to the OCSP responder. This is important, since CDP only provides the pointer to the CRL. This is the only place where you can find a pointer to the OCSP responder. If we want to check the validity of the certificate with OCSP we must hope that the certificate has the AIA extension. Otherwise, we can’t know what is the correct OCSP server to query;
* certRetrieval: it’s a pointer (e.g., URL) to the repository of certificates issued by the CA where it’s possible to download all (public) certificates;
* cAPolicy: it’s a pointer (e.g., URL) to the the policy followed by the CA; PKIX private extensions: AIA
* caCerts: the certificates of the CA itself

Although the AIA extension can be marked as critical or non-critical, it is almost always marked as non-critical,

Question 46

CAIA

Answer 46

CA Information Access (CAIA): IETF_PKIX private extension
This extension is used for the certificates owned by a CA (certificates whose subject is the CA).
The extension may include pointers to:
* certStatus: Provides the OCSP pointer, enabling immediate validation of the CA’s own certificate;
* certRetrieval: Retrieves the CA’s certificate;
* cAPolicy: it’s a pointer (e.g., URL) to the the policy followed by the CA; PKIX private extensions: AIA
* caCerts: the certificates of the CA itself

It is typically non-critical.

Question 47

What is a OID?

Answer 47

The OID (Object Identifier) is a globally unique identifier for data. It was originally introduced with SNMP (Simple Network Management Protocol) to manage routers and switches remotely by sending configuration commands.

OIDs follow a hierarchical structure maintained by IANA.

Question 48

Extended Key Usage

Answer 48

The Extended Key Usage field can be used in addition to or as a substitution for the keyUsage field. Unlike keyUsage, which specifies cryptographic operations (e.g., encryption or digital signature), Extended Key Usage is oriented toward applications.
It can be used simultaneously with keyUsage. In case of conflicts, the CA (Certificate Authority) must compare the values of keyUsage
and Extended Key Usage to determine if they are compatible. Typically, Extended Key Usage takes precedence in modern applications as it is more meaningful, but clear rules for priority should be established by the CA.

Possible values: serverAuthN, clientAuthN, codeSigning, ocspSigning, timeStamping

Question 49

Evolution of RFC-2459

Answer 49

RFC-2459 was the first version of the PKIX profile, which defined the Internet standard for Public Key Infrastructure (PKI).

Over time, its content was reorganized and split into two distinct documents for greater flexibility:
* RFC-3280: Defined the Internet profile for X.509v3 certificates and X.509v2 Certificate Revocation Lists (CRLs). This RFC later became obsolete with the publication of RFC-5280.
* RFC-3279: Documented the cryptographic algorithms (including identifiers, parameters, and encodings) required for RFC-3280. By separating the algorithm specifications, updates could be made independently, allowing the algorithms to evolve in line with advancements in cryptographic techniques.

Question 50

PKC validation

Answer 50

Every time a transaction relies on certificates to provide security features, it is necessary to verify that the certificate is valid. Validity does not only mean performing cryptographic verification.
When a certificate is received, the following checks are required:
* Verify that the certificate is cryptographically signed.
* Confirm it has been issued by a CA certified by another CA up to a trusted root CA.
* Ensure the validity period is still active.

Question 51

Possible solutions to have POP

Answer 51

The most effective method is to perform POP at the time of signature creation. This means that: The signer inserts a reference to the certificate (e.g., a hash) among the signed information. Thus, the signature value becomes a function of both the data and the certificate, thereby strengthening non-repudiation. Unfortunately this approach is not supported by current signature standards, necessitating the development of custom protocols.

An alternative solution involves the CA issuing a certificate only after verifying that the requester owns the corresponding private key. This can be achieved through several methods.

POP methods
Keys generated by CA/RA and delivered in secure token (e.g., smart-card, USB crypto-token). The possession of the token is considered as a proof.

If the key pair is used for encryption and the token is lost/destroyed, there’s no way to decrypt data…unless the CA adopts policies of key-recovery/key-backup.

Policies of key-recovery/key-backup (very risky!!!):
– the CA maintains a copy of all private keys (how can it protect them efficiently?). Since the CA maintains such copies, you don’t have non-repudiation (since you’re not the only one possessing the private key);
– key pairs are generated externally and then they’re injected into devices.

Best practice: use two key pairs
– one key pair for digital signature only, locally generated on the token;
– one key pair for encryption only, subject to key-recovery/key-backup policies and injected;

POP methods - online methods
* For signing and encryption keys: use self-signed formats (PKCS#10, SPKAC): the CA verifies the signature and obtains POP.
* For encryption keys (no signature): use of challenge-response protocols that involve a decryption operation (use of the private key); the certificate will be returned in an encrypted form (subsequent revocation if the certificate is not used);

Question 52

PKCS#10

Answer 52

It is a for certificate requests providing POP.

This format is commonly referred to as a Certificate Signing Request (CSR).
A CSR contains the following information:
DN + public key + (optional) attributes
– Distinguished Name (DN): the identifier being requested.
– Public Key: the key to be associated with the certificate.
– (Optional) Attributes: additional data about the requestor.

Attributes may include a Challenge Password, that is a **one-time code provided by the Registration Authority **(RA), which can be used for:
* Registration: The RA gives this password to the user to authenticate to the CA.
* Revocation: If the user loses their private key and needs to revoke the certificate, they can use this emergency password to authenticate the revocation request. This is crucial since asymmetric challenge-response mechanisms cannot be used without the private key.

Attributes may also include Attributes to be inserted into the certificate (e.g., those specified in PKCS#9) and additional information about the requestor.

The CSR also contains a signature that doesn’t have an associated certificate yet but it is inserted as the last part of PKCS#10. So, when this blob is received by the CA, the CA can use the specified public key to verify if that signature is correct or not. If the signature is correct, it means the requestor is controlling the corresponding private key (POP at certificate request time).

Question 53

Secure Time Stamping

Answer 53

Time-stamping provides proof that certain data existed before a specific point in time. This is crucial for workflows involving document signing, especially in cases where deadlines must be met. However, it is important to note that time-stamping does not indicate when the data was created, only that it existed before the recorded time.

• Time-Stamping Authority (TSA): Time-stamping is typically carried out by a TSA, which uses precise clocks (e.g., GPS or atomic clocks) to provide accurate timestamps.
• The related standard (RFC) specifies: the Time-Stamp Protocol (TSP) (to request the timestamp) and the format of the proof, that is the Time-Stamp Token (TST).

When a user wishes to timestamp a document, the following steps are typically followed:
1. The user computes a hash of the document instead of sending the document itself to the TSA, ensuring privacy.
2. The resulting digest is submitted to the TSA, which reads the current date and time from its clock. The TSA has typically access to a very precise clock (e.g., the TSA is connected to the global positioning system or, even better, to an atomic clock) from which it reads the time to be used for creating the response. It then creates a TST containing: the submitted digest, the (ultra) precise date and time, a digital signature created by the TSA, binding the hash, date, and time. This response is clearly saying “this digest was submitted on this date at this time”. That means the document on which the digest was computed was created before that date and time (e.g., it could even be 10 years old).
3. The TST is returned to the user, who can attach it to the document as proof that: the dcoument existed before the timestamp and the document has not been modified since the timestamp => if the document is altered the hash won’t match the TST anymore.

Question 54

Time Stamp Token problem

Answer 54

In case of a document with a digital signature, how to prove that the document was signed at a certain time? It’s not actually possible to specify the exact time when the signature was performed but it’s possible to demonstrate that the signature was performed within a specific time interval.
This can be done by using two timestamps:
1. the non-signed document digest is sent to the TSA;
2. the received TST1 is put together with the document and a signature is computed over them;
3. the digest of document + TST1 + signature is sent to the TSA which then replies with TST2;
4. TST1 demonstrates that the document was created before timestamp1.
Both TST1 and TST2 demonstrate that the signature was computed within the time interval [timestamp1,timestamp2];

Question 54

PSE: Cryptographic smart-card

Answer 54

An active PSE is typically implemented using cryptographic smart cards, which are chip cards with memory and/or autonomous cryptographic capabilities. Cryptographic capabilites can be:
* Simple: Symmetric cryptography such as DES, AES, and SHA.
* Complex: Asymmetric cryptography like RSA, DSA, and ECDSA, with considerations such as:
– Key length (longer keys increase security but also cost).
– Key generation: Onboard key generation, exportable keys, or injectable keys.

The hardware components of a cryptographic smart card are:
* EEPROM: Small protected memory (4-64 kB) used to store private keys securely.
* ROM: Contains the card’s operating system.
* RAM: Used for computations.
* μController: Combines CPU, memory controller, and I/O device but is limited in capacity and performance, making it unsuitable for running cryptographic algorithms directly.
* Cryptographic Coprocessor: Implements cryptographic algorithms directly in hardware, enabling secure computations without exposing private keys.

Advantages of Cryptographic Smart Cards
* Keys are never exposed in RAM, minimizing the risk of malware attacks. The smart card performs cryptographic computations internally and returns only the results (e.g., a signature).
* Smart cards are dedicated devices not vulnerable to general-purpose Malware (≠ smartphones)

Limitations
* smart cards are slow due to their limited CPU speed
* good for individual use but not for environments like servers

Question 55

HSM

Answer 55

Hardware Security Module
It is considered a crypto accelerator for servers which provides secure storage of private keys and has ncryption capabilities

Question 56

PKCS#12 format

Answer 56

It is a widely used format for transporting and storing cryptographic material across different applications and devices.
It contains a private key and one or more certificates (both personal and root certificates) and it is used to transport the digital identity of a user.

Concerns:
∗ Prioritizes speed over security by minimizing the number of hashing rounds, making it more susceptible to attacks.
∗ It is recommended to create PKCS#12 files using other systems (e.g., Mozilla or Google) for better security and then import them into Microsoft systems.
∗ Avoid exporting PKCS#12 files from Microsoft to prevent creating a less secure version.

Despite technical criticisms (especially of the Microsoft implementation), PKCS#12 remains widely used due to its versatility and support across platforms.

Question 57

Hierarchical PKI

Answer 57

• A tree rooted at a self-signed root CA;
• Very easy to build a certification path between any two End Entities (EEs): just need to go up in the chain until a common ancestor is reached.
• It is natively supported by applications
• It has political issues because it is difficult to have just a root over the whole worlds => we have a forest

Question 58

Mesh PKI

Answer 58

• Two hierarchical PKIs may unilaterally or bilaterally trust each other by issuing a cross-certificate.
  A cross-certificate is a certificate issued by a root CA for another root CA.
  Let’s suppose a client doesn’t want to trust a list of root CAs but just one CA, e.g., H3. If the client receives a certificate coming from a different hierarchy, that hierarchy must have a cross-certificate with H3, otherwise it won’t be trusted;

The problem is that cross-certificates are not automatically recognized by standard applications, because if there is a cross-certificate, then the application does not know which certificate chain should consider. For example, if a certificate starts from H1, the application should stop on the root CA of H1 or continue to H2 using the link? There is no single path but multiple options.

For complete trust among all hierarchies, we need N(N − 1)/2 cross-certificates.

It is rarely used in practice (mostly due to the application problem).

Question 59

Bridge PKI

Answer 59

To simplify management operations (i.e, addition and deletion of a CA) and trust transitivity, a bridge CA is introduced such that:
- it is trusted and cross-certified with each root CA (i.e., with each hierarchy)
- it does not certify any other CA or EE;
- it is preconfigured and never sent within the certificate chain;

Issues:
- not automatically recognized by applications
- N cross certificates needed to build complete trust

Question 60

How to deliver a Signed Certificate Time-stamp(SCT)

Answer 60

Context: Certificate transparency, the logger promises that it will log the certificate within the timestamp.

SCT via X.509v3 extension
1. The CA submits a pre-certificate to the log server: the CA can’t issue the real certificate because it needs the SCT first; the pre-certificate tells to the log server that the CA is about to issue a certificate which contains some information;
2. The log server returns an SCT;
3. The CA then attaches the SCT to the pre-certificate
as an X.509v3 extension, signs the certificate, and delivers the certificate to the server operator;
4. The server operator (example.com) will then send
that certificate, as part of the TLS handshake, to any client willing to connect;

SCT via TLS extension
1. The CA issues the certificate to the server operator (without SCT)
2. The server operator submits the certificate to the log server: it is obligation of the server operator to submit the certificate to the log server, since it has no SCT; the log server receives the real certificate and not a precertificate;
3. The log server sends the SCT to the server operator;
4. The server uses the TLS handshake extension signed_certificate_timestamp to deliver the SCT to the client during the TLS handshake: the SCT is not embedded in the certificate and it’s delivered separately during the TLS handshake;

SCT via OCSP stapling
1. The CA provides the certificate to the log server and the server operator: they both receive the real certificate without SCT;
2. The log server returns an SCT;
3. The server operator makes an OCSP query to the CA;
4. The OCSP (stapled) response contains the SCT, which the server can include in the OCSP extension during the TLS handshake;

All three solutions presented above require modifications of the browser. Note that the browser could receive the SCT by means of any of the previous methods, since there’s no agreement whatsoever between the browser itself and the web server (the way the SCT is delivered depends entirely from the CA and/or the domain owner). So, it would be better for the browser to support all three methods.

X.509v3 extension: the TLS handshake is not modified but the browser must understand this extension in the certificate;
≠
TLS extension: the certificate is not modified but the TLS handshake is modified;

Question 61

ACME: steps to obtain a certificate

Answer 61

Account creation
1. Account creation needs to be performed only once, before asking issuance/revocation of domain certificate(s).
2. The ACME client generates a private/public key pair used for authorization purpose, the “authorized key pair”: this key pair can be used for generating certificates for all sub-domains as well. The authorized public key is associated to the account registered at Let’s Encrypt (LE).

The authorized private key will be used to sign the certificate requests, while the authorized public key will be used by LE to validate the received certificate requests.
A single account is associated to one or more domains.

Domain validation
1. ACME client must prove to the CA to be in control of the domain for which it will request certificates;
2. ACME client claims ownership of a particular domain;
3. The CA challenges the client to store a value at a specific path inside the domain (step 1) or in a DNS record… e.g., create a web page at https://example.com/8303 which contains the string “ed98” (this proofs the domain ownership); e.g., if the client really manages example.com it should be managing the DNS too. So, it should be able to create a DNS record with a specific name which contains a specific value (this proofs the domain ownership as well); …and to sign a nonce with the authorized private key → proof of possession.
4. When the 1st challenge is solved (value stored at requested location), the client sends the signed nonce
to the CA to start the validation process (step 2);
The CA downloads the response from the domain and verifies its correctness (steps 3 & 4) and the signature’s one;
If everything is correct, the CA approves domain ownership (step 5) and the client is enabled to request certificates for that domain; remember that the ACME client is not enabled to request certificates just for a single web server but for all web servers of that domain;
The CA associates the public key A.PK to example.com and stores that information in the database: A.PK is the key which is authorized to request and manage certificates for example.com;

Certificate request and issuing
1. Client uses the authorized key pair to request, renew, and revoke certificates for the domain;
2. Client constructs a PKCS#10 CSR and asks the CA to issue a certificate with a specified public key: the CSR includes a signature by the private key corresponding to the public key in the CSR; the client also signs the whole CSR with the authorized private key for that domain.

In this case, the PKCS#10 request is further externally signed with the authorized private key in order to show that this is a valid request for that domain; -> POP

Question 62

ACME – certificate revocation

Answer 62

1. The Client signs a revocation request with the authorized private key for the corresponding domain.
2. The CA verifies that the key is authorized: if so, it revokes the certificate and includes this information in the proper revocation mechanisms (CRL and/or OCSP).