[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Software for PKI
it was a multi part piece of logic
1) part one ... early X.509 Identify certificate work for offline
credentials has morphed into several other forms
2) ... identity is useful for more than a single relying party
3) ... eliminating identity ... somewhat restricts the domain of offline
credentials.
4) one of the morphs was into online relying-party-only credentials
5) it was possible to show that in the case of relying party only
credentials, the relying party only certificates were unnecessary,
superfulous, and redundant.
As before the nominal X.509 identify offline certificates could involve
into other types of offline information binding credentials. However, many
of the X.509 offline credential morphs for the online world could be shown
that such credential was unnecessary, redundant and superfulous (when the
online original of the
information was being accessed).
In the case of a relying party only scenerio that was accessing the online,
real time account information ... that contained the original of the
relying party only certificate .... it was possible to show either
a) reduction of the appended relying party only certificate to zero bytes
... since the receiving relying party already had a copy of all the
information in the relying party only certificate
b) eliminating the appended relying party only certificate ... since the
receiving relying party already had the original of the relying party only
certifciate.
replay of this same discussion in this newsgroup from august of last year
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation
checking capability
general thread on offline stale credential vis-a-vis online, real-time
information:
http://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures,
technology experiments, and service operations
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re:
KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment
Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla...
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm5.htm#spki Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose11 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsmore.htm#pressign President Clinton digital
signing
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations
regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark
Debate
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS)
Relying-Party Certification Business Practices
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#40 general questions on SSL
certificates
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format
standard
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
rhousley@xxxxxxxxxxxxxxx on 11/12/2001 6:20 AM wrote:
Lynn:
Good grief. You are a smart guy. Do you say these things just to provoke
reaction?
There is nothing in X.509 or PKIX that warrants such statements.
The whole point of a public key certificate is to bind a public key to an
identity. The form of the subject identity can be application
specific. For example, to support S/MIME, the certificate binds an
electronic mail address to the public key. To support a anonymous payment
protocol, the certificate would likely bind the public key to an identifier
of the financial institution and an account number, where only the
financial institution need know the identity of the account owner. This is
clearly the opposite end of the spectrum from QC defined in RFC 3039.
Do not condemn the public key certificate because one application makes use
of a different form of identity than another application.
Russ