Anne & Lynn Wheeler wrote:
> This totally leaves out the relying-party ... which is the > primary beneficiary of the PKI model from being a part > of the contractual business process ... which would imply > little or no legal recourse if something went wrong. > ... > The PKI frequently creates a total disconnect between > the parties of the certification "contract" ... and the > relying parties ... which should have recourse in case > something went wrong aren't even a part of it.
The PKI model is not tied to any legal jurisdiction and is not a business process. What is meant then by relying-party (RP) and RP Reliance in X.509 and PKIX? I hope the text below, from a work in progress submitted as an IETF ID, helps clarify this issue.
RP reliance is a technical term in PKIX [1]. The concept of RP reliance is needed in PKIX/X.509 because not every aspect of certificate management can be fully verified by an RP. In short, RP reliance is that which can break the RP's security policy.
For example, a user verifying a certificate's revocation status (e.g., using mechanisms such as querying a repository or receiving notices delivered via a message service) will depend on the conforming administration and management of that status by one or more authoritative entities -- i.e., the user becomes a relying party to these entities.
More generally, a user who depends on values provided by an entity (e.g., CA) that seem reasonable on their face value to the user but are especially hard to check by the user is an RP to that entity.
What does the RP rely on? The RP relies on entities (e.g., the CA) following PKIX recommendations that the RP CANNOT verify. For example, an RP does not rely on the CA for certificate path processing (because the RP CAN verify it) but must rely on the CA for ensuring that the CA's signing key is properly secure and not compromised. The latter cannot be verified by the RP and becomes, thus, a limitation for reliance.
RP reliance limitations are objectively defined in PKIX, without reference to domain policies, user security policy, jurisdiction- based rules of laws and contracts or anything else that needs to be locally defined.
As a literal value, RP reliance on the revocation status of a certificate is defined by a conforming certificate path procedure leading to a bit value -- "revoked" or "not revoked". The literal bit value depends both on processes that the RP CAN verify and processes that the RP CANNOT verify. The latter defines the limitations of RP reliance. The lesser the limitations of RP reliance, the lesser the risk faced by the RP that RP reliance might be broken by factors outside RP control.
The literal bit value has no associated semantics outside the scope of PKIX. In other words, RP reliance is syntactic, not semantic. Any semantic value (e.g., legal reliance, contractual obligations concerning use, public policy, etc.) MUST lie outside the scope of PKIX and is, for example, regulated by terms in the CA's CPS.
Cheers, Ed Gerck
[1] A relying party (RP) is a user who processes a certificate chain, and then acts in reliance on the end-entity (EE) certificate issued by a CA (the issuer CA) and any associated revocation information.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]