RP -- Re: Using crypto against Phishing, Spoofing and Spamming...

[Ed Gerck]

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 majordomo at metzdowd.com