网络安全 L7 certificates 认证

Attack on public key and binding
1. How can we have assurance that a public key, purported to come from some
entity, really does belong to that identity?
2. We need to bind the identity to the public key. 

1. If the principal (entity) needs to be physically present, then you can have them
carry the key around on a tamper-resistant smart card with protection by a
password/PIN etc.
2. The original proposal was in fact to have bindings listed in a heavily write-
protected file that could easily be accessed for reading. This was difficult at the
time it was proposed (1976).
3. Use a (public key) certificate that contains a unique name for the principal, and
the public key. Have such certificates transmitted or consulted as necessary.

Certificates: main idea
1. A (public key) certificate is a signed message containing:
        1. The entity’s identity.
        2. The value of its public key.
        3. Other stuff, e.g. expiry date.
2. Analogy: Can loosely think of them as letter of introduction for the entity,
signed by someone.es transmitted or consulted as necessary.

Certificates: notation
1. In abstract terms, certificates have the form:

where:
• is a signature by the signer,
• A is the entity named, and
• is the public key of A.

Certificates and proof of identity
1. Mere possession of a valid certificate does not identify the entity in possession
as the entity named in the certificate.
2. Entity A could hold a certificate containing B’s name and public key.
3. Challenge-response protocols are often used for entity authentication instead.
        1. B might be issued a challenge, which requires a signature with its private key.
        2. Assuming that B has kept the private key private, this proves the identity of B.

Certificate, key use and trust
• Suppose that there is a certificate, c, containing principal’s name A, and public
key vA corresponding to private key sA .
• The certificate will be signed by some other entity CA using some private key sCA .
• Entity B might trust CA’s key, in the sense that it accepts that it belongs to CA:
• It will therefore accept that anything signed with sCA really was intended to be signed by CA.
• In particular, it accepts certificate c was intended to be signed by CA.
• Furthermore, B might also trust that CA will only sign a certificate that contains a correct binding:
• In this case, B will accept that vA belongs to A, i.e. B will trust A’s key.
• CA is a certification authority (CA) for B. 

如果存在一个证书 c，它包含实体 A 的名字和公钥 vA，以及与私钥 sA 相关联，这个证书将由另一个实体 CA 使用它的私钥 sCA 签名。如果实体 B 信任 CA 的密钥，即它接受 CA 的公钥确实属于 CA，那么 B 也会接受由 CA 的私钥签名的任何内容。

具体来说，如果 B 信任 CA，它将接受证书 c 是 CA 签名的，并且信任 CA 只会签名包含正确绑定的证书。在这种情况下，B 也将接受 vA 属于 A，即它将信任 A 的密钥。因此，通过信任链，B 可以建立对 A 的密钥的信任。

Application: using a key certification centre
1. If A and B both trust the same CA, T, to sign certificates binding their identities
and public keys correctly, then they can use T as a key certification centre.
2. They use this as follows:
        1. A and B both have their own public-private key pairs.
        2. The public keys are put in separate certificates signed by T:
                1. Both A and B are then confident that each other’s public keys do indeed belong to them.
        3. A encrypts the session key with B’s public key:
                1. So, A confident that only B can decrypt.
        4. A signs the result with its own private key:
                1. So, B confident that message came from A.
        5. Encrypted session key and signature can be sent.
3. Note that T does not get (symmetric) session keys in clear.

• 步骤1：A 和 B 都拥有自己的公钥-私钥对。
• 步骤2：A 和 B 的公钥被放入由 KCC 签名的证书中。这些证书由 KCC 使用其私钥签名，以确保公钥与持有者身份的正确绑定。
• 步骤3：A 使用 B 的公钥来加密会话密钥。这样，A 确信只有 B 能够解密。
• 步骤4：A 使用自己的私钥对加密后的会话密钥进行签名。这样，B 确信消息确实来自 A。
• 步骤5：加密后的会话密钥和签名可以被发送。
• 只有 A 和 B 知道会话密钥，并且 KCC 无法访问这个关键信息。

 Certification authorities
1. A certification authority (CA) is there to provide digitally signed certificates that
bind public key values to unique identities of entities.
2. CA is a form of trusted third party (TTP)

Certifying certificates

1. How do we decide to arrange larger systems of certificates and chains.
2. Two basic ways (currently):
        1. Centralised and hierarchical (e.g. PKIX / X.509 below).
        2. Decentralised and ad-hoc structure:
                1. This kind of thing arises with Pretty Good Privacy (PGP) and its relatives. We might revisit this later.
3. Different kinds of `trust’ end up baked into the system.

Different kinds of`trust’ end up baked into the system”意味着在证书认证系统中，不同的信任模型和信任建立机制最终会以某种形式被内嵌或整合到整个系统中，成为其运作的一部分。这反映了不同信任模型的多样性以及它们在实际系统中的应用。

Arranging CAs
1. Suppose:
        1. A has a certificate from CA X.
        2. D has a certificate from CA Y.
        3. A wants assurance about authenticity of D’s public key

2. Then A needs a copy of Y’s public key.
3. The system needs one of:
        1. Cross certification
                1. X and Y issue certificates to each other
        2. Certification hierarchy
                1. X and Y both sit under another parent CA, say Z, that issues certificates to its children.

1. A 拥有 CA X 签发的证书：A 已经通过 CA X 验证了其身份，并获得了 CA X 签发的证书。

2. D 拥有 CA Y 签发的证书：D 已经通过 CA Y 验证了其身份，并获得了 CA Y 签发的证书。

3. A 需要验证 D 的公钥：A 想要确保 D 的公钥确实属于 D，并且没有被篡改。

为了实现这一点，A 需要执行以下操作：

• 获取 Y 的公钥：A 需要一个可信的来源来获取 CA Y 的公钥，以确保其用于验证 D 的证书的有效性。

为了实现这一目标，系统需要一种机制来确保不同 CA 之间的信任关系。这可以通过以下两种方式之一实现：

1. 交叉认证（Cross Certification）：

   • 步骤：CA X 和 CA Y 相互颁发证书，确认对方的身份和公钥。这样，A 可以信任 CA Y 的公钥，并使用它来验证 D 的证书。

2. 认证层次（Certification Hierarchy）：

   • 步骤：CA X 和 CA Y 都位于一个共同的上级 CA Z 下。CA Z 负责签发其子 CA 的证书。这样，A 可以信任 CA Z 的公钥，并通过它来验证 CA Y 的公钥，进而验证 D 的证书。

 1. Suppose that B needs to trust E’s public key.
2. In situation (1):
        1. B needs to verify cert. of Y issued by X, and
        2. B needs to verify cert. of E issued by Y.

3. In situation (2):
        1. B needs to verify cert. of Y issued by Z, and
        2. B needs to verify cert. of E issued by Y.

Public key infrastructure (PKI)
1. A public key infrastructure (PKI) is a system consisting of hardware, software,
people, policies and procedures needed to create, manage, store, distribute,
revoke and support use of public key certificates (PKCs).
2. They are widely used to underpin e-commerce.
3. They are currently critical, and sometimes argued to be essential, for:
        1. Secure email,
        2. Secure web-server access,
        3. Secure virtual private networks, and
        4. Other secure communications applications.

Need for PKI
1. Identity verification of central importance.
2. Cross verification requires CAs to use compatible technologies.

交叉验证的需求：

• 定义：交叉验证是指不同认证机构（CAs）之间的信任关系。

3. When should a CA be trusted?

评估：用户和系统需要评估 CA 的可靠性和安全性。这通常涉及审查 CA 的政策、实践声明以及它们的安全措施。
4. CAs need to publish policy and practice statements containing clear information
about their security.

• 目的：CA 需要发布清晰的政策和实践声明，包含有关其安全措施的详细信息。
• 内容：这些声明应包括 CA 的操作流程、密钥管理实践、安全控制措施以及如何处理证书撤销等信息。

Main players in a PKI system
1. Certificate owner :
        1. Applies for certificate.
2. CA:
        1. Issues certificate.
                1. This binds owner identity to owner public key value.
3. User (`relying party’):
        1. Uses the certificate for verification.

1. 证书所有者（Certificate Owner）：

   • 职责：证书所有者是希望在其身份和公钥之间建立可信绑定的人或实体。
   • 操作：证书所有者申请证书，提供身份验证信息，并允许 CA 验证其身份。

2. 认证机构（Certification Authority, CA）：

   • 职责：CA 是颁发和管理证书的受信任第三方。
   • 操作：CA 验证证书所有者的身份，并使用其私钥签发证书。证书将所有者的身份与其公钥值绑定在一起。

3. 用户（Relying Party）：

   • 职责：用户是依赖证书来验证所有者身份的人或实体。
   • 操作：用户使用证书来验证证书所有者的身份，并确保他们与之通信的实体确实是他们声称的那个人或实体。

证书所有者是证书的拥有者和管理者，而依赖方是证书的消费者，他们使用证书来验证证书所有者的身份和属性。两者之间的区别在于他们在证书生命周期中的角色和职责。 

Validation authority
1. For a user, verifying the authenticity of a public key may involve verifying the
signatures in a long chain of certificates:
        1. We saw small examples (a) and (b) above.
2. Possibly too expensive/time-consuming for users. 耗时
3. Instead, the task can be delegated to an entity to called a validation authority (VA).
        1. So, the user relies on the VA.

Registration authority
1. Sometimes the process of issuing certs is split up.
2. Putative owner, O, applies to a Registration authority (RA):
        1. Verifies (somehow) the O’s identity.
        2. How can O prove their identity?
        3. Typically:
        1. Might be sufficient that the O can authenticate to some system (e.g. with password).
                1. Something they know.
        2. Might be that the O is required to produce another certificate!
                1. Something they have.
3. The RA and CA ensure that the key is bound to just that individual. Enables non-repudiation.

PKIX

1. PKIX is the X.509 public key infrastructure for the internet.
2. This is constructed using standard certificate formats, and standard protocols
concerning how they are managed and processed.
3. A public-key certificate (PKC) contains a subject’s public key and some further information.
4. An attribute certificate (AC) contains a set of attributes for a subject (owner/holder). These are also known as authorization certificates. They bind the identity of the subject to the attributes: these are typically privileges.

• 访问权限privilege：允许主体访问特定资源或执行特定操作。

5. Attribute certificates are issued by attribute authorities. A privilege management infrastructure (PMI) is a system of ACs, with their issuing attribute authorities, subjects, relying parties, and repositories.

PKIX entities
1. RA: registration authority
2. CA: certificate authority
3. CRL issuer: certificate revocation list issuer.
4. End entity: subject of certificate, or user of certificate.

1. 注册权威（Registration Authority, RA）：

   • 职责：RA 负责验证证书申请者的身份，确保他们的身份信息与申请的证书相匹配。RA 还可能负责收集额外的信息，如地址、组织单位等，并将其包含在证书中。
   • 操作：RA 通常会执行一些基本的身份验证，如验证用户名和密码，然后将申请者提交给证书颁发机构（CA）进行进一步验证。

2. 证书颁发机构（Certification Authority, CA）：

   • 职责：CA 是颁发和管理数字证书的受信任第三方。CA 负责最终验证申请者的身份，并使用其私钥对证书进行签名。
   • 操作：CA 接收来自 RAs 的申请，执行更严格的验证，如背景调查，然后签发证书。

3. 证书撤销列表（Certificate Revocation List, CRL）发行者：

   • 职责：CRL 发行者负责发布证书撤销列表，列出被 CA 撤销的证书。
   • 操作：当 CA 决定撤销一个证书时，它会通知 CRL 发行者，后者会更新 CRL 并发布新的 CRL 版本。

4. 终端实体（End Entity）：

   • 定义：终端实体是证书的主题，即证书所标识的个人或实体。
   • 操作：终端实体是证书的最终用户，他们使用证书来验证自己的身份或进行加密通信。

X.509
1. X.509 (v3) is the most common PKI standard.
2. The X.500 Directory is a hierarchical tree structure able to contain names of
devices, people, roles, etc. and corresponding attributes:
        1. Access control often tied to the identities in the directory.
3. X.509 is a later addition to this family of standards:
        1. Applications of X.509 are different than those originally envisaged within X.500.
        2. Applies to a broader access control situations (many situations involvingcryptographic authentication and communication, including SSL/TLS).
4. X.509 can also be used for one-way authentication or mutual authentication of
identities. We will discuss an application of this when we do SSL/TLS.

X.509 extensions
1. Key and policy information: convey additional information about the subject
and issuer keys, plus indicators of certificate policy.
        1. A certificate policy is a named set of rules that indicates the applicability of a
certificate to a particular community or class of application with common security
requirements.
2. Certificate subject and issuer attributes: can convey additional information and
alternate names for subject and issuer. Used to give additional assurance to a
user of the certificate.

例：这些属性可能包括主题的电子邮件地址、电话号码、组织单位等。
3. Certification Path Constraints: These allow constraint specifications to be
included in certificates issued for CAs, by other CAs - the issuer places the
constraint. They include basic constraints, name constraints and policy
constraints.

例：包括基本约束、名称约束和策略约束。基本约束定义了 CA 的类型（如最终 CA 或中间 CA）；名称约束定义了 CA 可以签发的证书的接收者名称；策略约束定义了 CA 必须遵守的策略。

Critical extensions in X.509
1. Extensions can be marked as critical.

这允许证书验证者知道哪些扩展是关键的，并需要特别处理。
2. Critical extensions can be used to standardize policy with respect to the use of certificates.

例：如果一个组织要求其证书必须包含特定的关键扩展，那么所有从该组织签发的证书都必须包含这些扩展
3. If a critical extension cannot be processed by an implementation, then the
certificate must be rejected.

关键扩展包含的信息对于证书的有效性至关重要，因此如果无法处理这些扩展，证书可能无法正确地用于其预期的目的。
4. Non-critical extensions may be ignored in some circumstances.

如果一个实现不支持某个非关键扩展，它可以选择忽略该扩展，而不影响证书的有效性。

Basic validation story

1. Assuming the certificate is not revoked, the following happens:
        1. User obtains the issuer’s public key for the particular algorithm:
                1. This is not on this certificate (except in the self-signing case below)
                2. We must get it from elsewhere (we’ll revisit this below).
        2. User applies the appropriate verification algorithm to the signature and the (hash
of the) foregoing fields in the certificate. The validation process continues if and
only if the signature is verified as correct.
        3. User then checks the period of validity. Process proceeds if and only if it is valid.
Finally, the constraints in the extensions must be checked. The certificate is judged
to be valid if and only if these checks are passed.
        4. Note that at step 2 we are relying on the authenticity of the issuer’s public key!

1. 假设证书未撤销：

   • 用户获取发行者的公钥：
     • 获取方式：发行者的公钥不在当前证书上（除非是自签名证书的情况）。
     • 获取途径：用户必须从其他地方获取该公钥（我们稍后会讨论这一点）。

2. 用户应用适当的验证算法：

   • 验证签名：用户将签名与证书中的先前字段的哈希值一起应用适当的验证算法。如果签名验证正确，则验证过程继续。

3. 检查证书的有效期：

   • 有效期检查：用户检查证书的有效期。如果证书有效，则继续处理。
   • 扩展检查：最后，用户必须检查证书扩展中的约束。只有当这些检查通过时，证书才被认为是有效的。

4. 对发行者公钥的依赖：

   • 依赖性：在第二步中，用户依赖于发行者公钥的真实性。这意味着用户必须信任获取到的公钥是真实的，并且与证书的发行者相关联。

Certificate chains
1. On our `basic validation’ slide above, we needed the issuer’s public key KI in order to perform the validation of the certificate, C (which certifies some K).
2. We need to be sure that KI is authentic. Often, this
assurance is provided by another certificate CI .
3. CI will have been provided by the issuer-issuer, II, who has a public key KII for which there is a certificate CII. We need to verify CII , and so on.
4. We can thus require a chain of certificates (and keys) as shown in the picture. 

1. If all is well, then this should end with a root verification key, KR. There is sometimes a root
certificate, CR, as well.
1. The authenticity of this is not assured by another certificate.
It is trusted, i.e., assumed to be genuine.
2. Typically, these are stored somewhere locally and securely,
by the entity that wishes to verify C.
3. Everyday example is that browsers and operating
systems are shipped with a small number of root-certificates and root-keys.

1. 验证证书的步骤：

   • 目标：为了验证证书 C（它认证了某个密钥 K），我们需要获取发行者（Issuer）的公钥 KI。
   • 挑战：我们需要确保 KI 是真实的。通常，这通过另一个证书 CI 提供保证。

2. CI 证书：

   • 内容：CI 证书是由证书的发行者-发行者（Issuer-Issuer, II）提供的，它验证了 KII 的真实性。
   • 公钥：II 有一个公钥 KII，对于这个公钥，有一个证书 CII。

3. CII 证书验证：

   • 验证：我们需要验证 CII 证书的有效性。这个过程可能会继续，直到我们到达一个自签名的根证书，或者直到我们到达一个我们已知是可信的证书。

4. 证书链的形成：

   • 概念：我们可以要求一系列的证书（和相应的密钥）来形成一个证书链。
   • 验证：每个证书都需要验证其发行者的公钥的真实性，直到我们到达一个可信的根证书。

在证书链的末端，我们通常会遇到一个根验证密钥 KR。有时，还有一个根证书 CR。

1. 根证书和密钥：
   • 真实性的确认：根证书和密钥的真实性不是通过其他证书来确认的，而是被信任的，即假设是真实的。
   • 存储位置：这些通常由希望验证证书的实体在本地安全地存储。
   • 日常应用：例如，浏览器和操作系统通常会包含一些根证书和根密钥，以便用户在验证证书时使用。

通过这种方式，证书链提供了一种机制，允许用户验证证书的真实性和有效性。每个证书都依赖于其发行者的公钥，而发行者的公钥又依赖于另一个发行者的公钥，依此类推，直到我们到达一个我们信任的根证书。这种方法确保了证书链的完整性，并允许用户验证任何给定证书的真实性。

Root keys and certificates
1. The root key KR (e.g. in your browser or OS) is the public key half of a public-
private key pair.
2. The private half of the pair, say KRS, is also known as the Root Key. It is held by a
Certificate Authority under tight security.
3. The public root key is often self-signed.
        1. What this means is that CR has been signed with KRS .
        2. Hence, KR is the only key that can `verify’ CR, in the usual sense, however this
doesn’t mean much. 

1. 根密钥 KR：

   • 定义：根密钥 KR 是公钥/私钥对中的公钥部分。
   • 位置：在浏览器或操作系统中，根密钥 KR 用于验证证书链的根证书。

2. 根密钥的私钥部分：

   • 定义：根密钥的私钥部分，例如 KRS，通常由证书颁发机构（CA）在严格的安全措施下持有。
   • 用途：KRS 被用于签署根证书 CR，以确保其真实性和有效性。

3. 自签名根证书：

   • 定义：自签名根证书是指根证书 CR 使用其私钥 KRS 进行签名。
   • 意义：这意味着 CR 被 KRS 签名，因此只有 KRS 能够“验证” CR，在通常的意义上，但这并不意味着 KR 也有验证能力。

 

Validation revisited
1. Checking a certificate thus involves proceeding recursively back up the unique
chain (from a root) that leads to it.
2. The process terminates either when it fails, or when you validate a certificate
that was signed by a root certificate.
3. In a browser using certificates as part of https, you get the `The site’s security
certificate is not trusted’ (or similar) message when this fails.
4. If an attacker can insert a new root pair KR and CR, then you are stuffed.

1. 递归验证过程：

   • 目标：检查一个证书涉及递归地回溯到其唯一的根链。
   • 过程：从证书链的根开始，依次验证每个证书的发行者，直到到达该证书。

2. 验证终止条件：

   • 失败：如果验证过程中任何一个环节失败，验证过程终止。
   • 根证书验证：如果成功验证了一个由根证书签发的证书，验证过程终止。

3. 浏览器中的证书验证：

   • HTTPS 应用：在浏览器中使用证书进行 HTTPS 通信时，如果验证失败，用户会收到“该网站的安全证书不受信任”或其他类似的消息。

4. 攻击风险：

   • 风险：如果攻击者能够插入一个新的根密钥对 KR 和 CR，那么用户的安全性就会受到威胁。
   • 影响：攻击者可以通过这种方式创建一个假的证书链，使得恶意网站看起来是可信的，从而欺骗用户。

PKIX certification path processing 

 

Generating and getting certificates
1. It is easy to generate your own root certificate:
        1. E.g., You can easily set up your own CA using openssl.
        2. You’d have to pay a lot of money (and demonstrate your trustworthiness) to have it
embedded in a major browser distribution.
2. You can easily be issued with a certificate by a CA that is descended from one of
the standard root CAs.
3. It is much harder to be certified as a CA that is descended from one of those
standard roots.

1. 标准根 CA：

   • 定义：标准根 CA 是一组由大多数操作系统和浏览器信任的 CA。这些 CA 通常由信誉良好的组织管理，并且它们签发的证书被广泛接受。

2. CA 的证书链：

   • 结构：一个 CA 的证书链是一系列证书，从该 CA 的证书开始，一直到某个标准根 CA 的证书。这个链中的每个证书都是由链中的前一个证书的发行者签发的。

3. 证书验证：

   • 过程：当一个用户尝试验证一个 CA 的证书时，他们首先验证该 CA 的证书。如果该 CA 的证书有效，用户将继续验证该 CA 签发的证书。这个过程一直持续到用户到达标准根 CA 的证书。

4. 信任的传递：

   • 概念：一旦用户验证了一个 CA 的证书链并确认它确实可以追溯到一个标准根 CA，他们就可以信任该 CA 签发的证书。这是因为用户的信任已经通过标准根 CA 传递给了该 CA。

5. 挑战：

   • 成为标准根 CA 的后代：由于标准根 CA 具有广泛的信任和认可，因此成为其后代 CA 相对困难。这通常需要满足一系列严格的安全、合规性和财务要求

The missing link: checking constraints
1. On our basic validation slide, I mentioned checking of constraints.
1. It is perfectly possible for nefarious characters to get hold of a certificate.
2. What is to stop someone dodgy with a genuine certificate from issuing a certificate
that spoofs something genuine?

Dodgy Dave should not have CA:
• TRUE set in the critical extensions for his certificate.
• That was issued by his issuer, so he cannot change it.
• The implementation of the certificate checking algorithm
should check that all of the issuers have CA:TRUE set.
• The failure to check such constraints resulted in a serious exploit of SSL.
 

1. CA:TRUE 约束：

   • 定义：CA:TRUE 是一个关键扩展，它指示证书颁发机构（CA）的类型。
   • 用途：如果 CA:TRUE 被设置为 TRUE，这意味着证书颁发机构是一个最终 CA，它有权签发其他证书。

Expiry dates
1. What should we do when the expiry date of one of the certificates has passed?
2. Two ways commonly discussed:
1. Shell Model
2. Chain model

Shell model
1. Motivating idea: A CA should only issue certificates that expire before its own.
2. Mode of operation: If any certificate in the chain is not between its expiry
dates, then we reject it and hence the whole chain below it.
3. Typical application: Suitable for subjects within a hierarchical address space,
where the purpose is authenticating the source of traffic.
        1. The traffic traverses links (edges) between nodes in the address space.
        2. Each traversal of a single edge requires authentication using a certified public-
private key pair.
        3. Confirm that all links to the address space are valid at the time of authentication,
and only at that time.

Chain model
1. Motivating idea: The issuer’s certificate only had to be valid at the time that the
certificate was issued.
2. Mode of operation: Certificates may remain valid even after a certificate above
them in the chain has expired or has been revoked.
3. Typical Application: Authenticating documents.
        1. A digital document has been signed with a public-private key pair that has a
certificate. If the certificate was valid at the time the document was signed, we
should accept it.
        2. Analogy: Certificate of student status should remain valid, even if the registry officer
that signed it later leaves.

4. Additional requirement: A secure and reliable time-stamping authority as a
trusted third party.
        1. In the example above, we must know that the signature was made during the
period of validity.

Revocation
1. A CA may wish to revoke a certificate that it has issued to a user (e.g., I may
wish to revoke certificate C, which was being used to guarantee key K, in our
chain example above).
2. For example, if:
        1. The user’s private key (matching K) is compromised, or
        2. Another fact that the vouches for is no longer valid, or
        3. The user is no longer certified, or
        4. The certificate should never have been issued but was through error or compromise.
3. Certificate Revocation Lists (CRLs) are distributed at regular intervals, on
demand, or sometimes queried on-line.

Problems with digital certificates
1. Revocation:
        1. Examples:
                1. Company issues certificate to employee, who then leaves.
                2. Keyholder knows that their private key is compromised.
        2. Certificate (together with private key) gives authentication capability.
        3. CA needs to revoke certificate.
        4. Difficult since certificates often widely distributed.
        5. CA may issue a certification revocation list (CRL)
        6. Known to be difficult to manage these and have various problems.

2. Liability:
        1. Users rely on certificates from CA.
        2. Certificate might be erroneous.
                1. Public key value listed may not belong to the listed owner.
        3. If this is the case, who is liable?
                1. Owner (of public key)?
                2. User (person displaying it)?
                3. CA?
                4. Not clear.

证书吊销的问题在于证书被吊销后，需要通知所有依赖该证书的用户，这在实际操作中非常困难。此外，由于证书的广泛分布，吊销操作可能会导致通信中断和系统故障。

责任问题则涉及在证书存在错误或被滥用时，各方（所有者、用户、CA）之间的法律责任。这通常需要法律框架来明确界定责任归属，但在实际情况中，责任归属可能并不清晰。

Association of keys and access rights
1. X.509 and PKIX are name-centric PKIs:
        1. To associate a key with access rights, you have to know the subject to which a key belongs.
        2. Authorization attributes are linked to a cryptographic key via a common name in a
PKC and an AC.
2. An alternative is the simple public-key infrastruture (SPKI), a key-centric PKI.
        1. SPKIs certificates bind keys directly to attributes (access rights).

X.509 和 PKIX 模型依赖于主体的身份来管理密钥和访问权限，而 SPKI 模型则直接基于密钥本身来管理访问权限。这两种模型各有优缺点，适用于不同的应用场景和需求。