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

Anne & Lynn Wheeler lynn at garlic.com
Thu Jul 22 15:07:30 EDT 2004


At 01:39 PM 7/21/2004, Ed Gerck wrote:
>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.


the TTP (trusted third party) PKI business model typically described in the 
early 90s ... had a business exchange between a key owner and a 
certification authority ... where the key owner paid the certification 
authority for the issuing of a certificate that bound some information to 
the public key. The payment of money by the key owner to the certification 
authority created some sort of legal relationship between the key owner and 
the certification authority .... with regard to the certificate.

in that environment .... the key owner then digitally signed something, and 
sent the something with a digital signature and the certificate to a 
relying-party. The relying-party was frequently assumed to be making some 
sort of legal reliance and recourse on the performance of the certification 
authority. However, w/o payment of funds and/or other legal arrangement 
between the relying-party and the certification authority .... there was no 
legal bases for reliance (unless mandated outside of traditional business 
context by some gov. mandate)

it appears that the GAO .... working within that semantic & structural 
business context ... has taken some effort to create a legal basis for 
reliance and recourse between the relying parties and the certification 
authorities for the federal PKI . It basically has something along the 
lines of the certification authorities signing a contractual relationship 
with the GAO. Then all the relying parties also sign a contractual 
relationship with the GAO ....  then there is recourse for the relying 
parties on certification authority performance based on the relying parties 
contract with GAO (for certification authority performance) and the GAOs 
contract with the certification authorities (for certification authority 
performance). This is sort of trying to get around the lack of any implied 
performance and/or contractual relationship (and therefor recourse) because 
the relying parties haven't actually paid any money to the certification 
authorities.

In the simple case, having any sort of legal obligation between the 
certification authority and the key-owner ... and any sort of totally 
different legal obligation between the key-owner and a relying party ... 
normally would fail to create any sort of legal obligation between (the 
traditional TTP PKI) certification authorities (described in the early 90s) 
and the set of relying parties.

some of this became mute by the mid-90s with the observation that the 
traditionally considered identity x.509 certificates represented a 
significant privacy and liability exposure ... and the retrenching by 
infrastructures to relying-party-only certificates (effectively account 
number and public key ... although even a relying-party-only SET 
certificates could represent a factor of 100-times payload bloat). the 
other issue that quickly became observed if the relying-party and the 
certification authority were the same .... then the relying party would 
typically have a large superset of the information that they included in 
any relying-party-only certificate ... and that having the key-owner to 
return this small subset of information repeatedly to the relying-party 
(/certification authority) was redundant and superfluous .... other than 
possibly contributing huge computational and transmission overheads for no 
useful purpose.

IETF standards tend to be descriptions of protocol and parties role in the 
protocol. Such syntactical and semantical description of the protocols has 
rarely included description of any possible syntactical and semantic 
business relationships .... especially of the typical kind being proposed 
in the early 90s for TTP certification authorities.

for pkix references .... see
http://www.garlic.com/~lynn/rfcietff.htm

and click on "Term (term->RFC#)" in the "RFC's listed by" section

then click on "PKI" in the "Acronym fastpath" section.

the current results:

public key infrastructure (PKI)
see also <file:///D:/users/http/rfcterms.htm#t508>authentication , 
<file:///D:/users/http/rfcterms.htm#t600>encryption , 
<file:///D:/users/http/rfcterms.htm#t770>public key
<file:///D:/users/http/rfcidx12.htm#3820>3820 
<file:///D:/users/http/rfcidx12.htm#3779>3779 
<file:///D:/users/http/rfcidx12.htm#3778>3778 
<file:///D:/users/http/rfcidx12.htm#3770>3770 
<file:///D:/users/http/rfcidx12.htm#3741>3741 
<file:///D:/users/http/rfcidx12.htm#3739>3739 
<file:///D:/users/http/rfcidx12.htm#3709>3709 
<file:///D:/users/http/rfcidx12.htm#3653>3653 
<file:///D:/users/http/rfcidx12.htm#3647>3647 
<file:///D:/users/http/rfcidx11.htm#3562>3562 
<file:///D:/users/http/rfcidx11.htm#3447>3447 
<file:///D:/users/http/rfcidx11.htm#3379>3379 
<file:///D:/users/http/rfcidx11.htm#3354>3354 
<file:///D:/users/http/rfcidx11.htm#3335>3335 
<file:///D:/users/http/rfcidx10.htm#3281>3281 
<file:///D:/users/http/rfcidx10.htm#3280>3280 
<file:///D:/users/http/rfcidx10.htm#3279>3279 
<file:///D:/users/http/rfcidx10.htm#3278>3278 
<file:///D:/users/http/rfcidx10.htm#3275>3275 
<file:///D:/users/http/rfcidx10.htm#3174>3174 
<file:///D:/users/http/rfcidx10.htm#3163>3163 
<file:///D:/users/http/rfcidx10.htm#3161>3161 
<file:///D:/users/http/rfcidx10.htm#3156>3156 
<file:///D:/users/http/rfcidx10.htm#3126>3126 
<file:///D:/users/http/rfcidx10.htm#3125>3125 
<file:///D:/users/http/rfcidx10.htm#3110>3110 
<file:///D:/users/http/rfcidx10.htm#3076>3076 
<file:///D:/users/http/rfcidx10.htm#3075>3075 
<file:///D:/users/http/rfcidx10.htm#3039>3039 
<file:///D:/users/http/rfcidx10.htm#3029>3029 
<file:///D:/users/http/rfcidx9.htm#2986>2986 
<file:///D:/users/http/rfcidx9.htm#2985>2985 
<file:///D:/users/http/rfcidx9.htm#2943>2943 
<file:///D:/users/http/rfcidx9.htm#2931>2931 
<file:///D:/users/http/rfcidx9.htm#2898>2898 
<file:///D:/users/http/rfcidx9.htm#2847>2847 
<file:///D:/users/http/rfcidx9.htm#2807>2807 
<file:///D:/users/http/rfcidx9.htm#2803>2803 
<file:///D:/users/http/rfcidx9.htm#2802>2802 
<file:///D:/users/http/rfcidx9.htm#2797>2797 
<file:///D:/users/http/rfcidx9.htm#2726>2726 
<file:///D:/users/http/rfcidx8.htm#2693>2693 
<file:///D:/users/http/rfcidx8.htm#2692>2692 
<file:///D:/users/http/rfcidx8.htm#2587>2587 
<file:///D:/users/http/rfcidx8.htm#2585>2585 
<file:///D:/users/http/rfcidx8.htm#2560>2560 
<file:///D:/users/http/rfcidx8.htm#2559>2559 
<file:///D:/users/http/rfcidx8.htm#2537>2537 
<file:///D:/users/http/rfcidx8.htm#2536>2536 
<file:///D:/users/http/rfcidx8.htm#2535>2535 
<file:///D:/users/http/rfcidx8.htm#2528>2528 
<file:///D:/users/http/rfcidx8.htm#2527>2527 
<file:///D:/users/http/rfcidx8.htm#2511>2511 
<file:///D:/users/http/rfcidx8.htm#2510>2510 
<file:///D:/users/http/rfcidx8.htm#2459>2459 
<file:///D:/users/http/rfcidx8.htm#2440>2440 
<file:///D:/users/http/rfcidx8.htm#2437>2437 
<file:///D:/users/http/rfcidx8.htm#2404>2404 
<file:///D:/users/http/rfcidx8.htm#2403>2403 
<file:///D:/users/http/rfcidx7.htm#2385>2385 
<file:///D:/users/http/rfcidx7.htm#2315>2315 
<file:///D:/users/http/rfcidx7.htm#2314>2314 
<file:///D:/users/http/rfcidx7.htm#2313>2313 
<file:///D:/users/http/rfcidx7.htm#2311>2311 
<file:///D:/users/http/rfcidx7.htm#2202>2202 
<file:///D:/users/http/rfcidx7.htm#2154>2154 
<file:///D:/users/http/rfcidx7.htm#2137>2137 
<file:///D:/users/http/rfcidx6.htm#2085>2085 
<file:///D:/users/http/rfcidx6.htm#2082>2082 
<file:///D:/users/http/rfcidx6.htm#2065>2065 
<file:///D:/users/http/rfcidx6.htm#2025>2025 
<file:///D:/users/http/rfcidx6.htm#2015>2015 
<file:///D:/users/http/rfcidx6.htm#1991>1991 
<file:///D:/users/http/rfcidx6.htm#1864>1864 
<file:///D:/users/http/rfcidx6.htm#1852>1852 
<file:///D:/users/http/rfcidx6.htm#1828>1828 
<file:///D:/users/http/rfcidx6.htm#1810>1810 
<file:///D:/users/http/rfcidx5.htm#1751>1751 
<file:///D:/users/http/rfcidx5.htm#1544>1544 
<file:///D:/users/http/rfcidx4.htm#1424>1424 
<file:///D:/users/http/rfcidx4.htm#1423>1423 
<file:///D:/users/http/rfcidx4.htm#1422>1422 
<file:///D:/users/http/rfcidx4.htm#1421>1421 
<file:///D:/users/http/rfcidx4.htm#1321>1321 
<file:///D:/users/http/rfcidx4.htm#1320>1320 
<file:///D:/users/http/rfcidx4.htm#1319>1319 
<file:///D:/users/http/rfcidx3.htm#1186>1186 
<file:///D:/users/http/rfcidx3.htm#1115>1115 
<file:///D:/users/http/rfcidx3.htm#1114>1114 
<file:///D:/users/http/rfcidx3.htm#1113>1113 
<file:///D:/users/http/rfcidx3.htm#1040>1040 
<file:///D:/users/http/rfcidx3.htm#989>989


clicking on any RFC number will bring up the RFC summary in the lower 
frame. Clicking on the ".txt" field in the RFC summary will fetch the 
actual RFC.


--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list