Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home



OCSP and LDAP
OCSP and LDAP
OCSP value proposition
OCSP and LDAP
OCSP and LDAP
OCSP and LDAP
OCSP and LDAP
OCSP and LDAP
OCSP and LDAP
OCSP and LDAP
X.500, LDAP Considered harmful Was: OCSP/LDAP
Kansas kicks of satewide PKI project
Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
A challenge
A challenge (addenda)
A challenge
A challenge
A challenge
A challenge
A challenge
surrogate/agent addenda (long)
A challenge
Encryption of data in smart cards
Certificate Policies (was Re: Trivial PKI Question)
Encryption of data in smart cards
Certificate Policies (addenda)
How effective is open source crypto?
How effective is open source crypto?
How effective is open source crypto? (addenda)
How effective is open source crypto? (bad form)
How effective is open source crypto? (aads addenda)
How effective is open source crypto? (bad form)
How effective is open source crypto? (bad form)
How effective is open source crypto? (bad form)
How effective is open source crypto? (bad form)
How effective is open source crypto? (bad form)
How effective is open source crypto? (bad form)
How effective is open source crypto?
The case against directories


OCSP and LDAP

Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 07:52 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ambarish@xxxxxxxx, ietf-pkix@xxxxxxxx, madwolf@xxxxxxxx,
    "Peter Gutmann" <pgut001@xxxxxxxx>
Subject: Re: OCSP and LDAP
but as been discussed in other venues ... it is not only the cost ... but also who pays (how does the money flow). does a consumer pay for checking a merchant's certificate as part of access the merchant's website .... which might otherwise be free access? A merchant (as the relying party) might pay when checking the status of a consumer's certificate .... but does a consumer (as the relying party) pay when checking the status of a merchant's certificate.. Also ... as in other merchant/consumer e-commerce discussions .... a merchant's interest in the status (real-time or not) of a consumer's certificate is only incidental to whether the bank says that the merchant gets paid.

now the other business flow as a certificate, offline, stale paradigm is pushed towards an online, real-time model .... there is a question of what point does the paradigm switch. In the original offline credit-card paradigm .... the transition to online, real-time .... bypassed the real-time checking on whether the offline, stale credential was still good ... and/or whether the stale assertions in the offline credential was still good .... but whether the real-time assertions were valid.

The model in the certificate ... is that there are some assertions that are inserted into a stale, static certificate at some time in the past .... and for OCSP ... you do real-time checks to see if the stale, static past assertions still hold. The model that credit-cards went to .... was doing real-time checks on real-time assertions ... not real-time checks on real-time stale, static assertions.

The distinction is that the payment card paradigm in moving to online ... bypassed the intermediate paradigm of real-time checks on past, stale, historic, static assertions (contined in the certificate) .... and went directly to real-time checks on current, real-time assertions, aka the credit-card industry in transitioning to online .... could have continued to preserve the offline paradigm with real time checks (like OCSP does for certificates) .... which is equivalent to a real-time check to see if the consumer still has a valid account. However, the payment card industry in transitioning to online discovered that they could significantly leverage the utility of having real-time, online checking .... that instead of having real-time, online checking of stale, static information .... significantly increase the utility of having real-time checking of real-time information.

So the credit-card industry skipped the OCSP-analogous step of having a real-time infrastructure for checking of stale, static data (aka does an account still exist), and significantly improved the utility of having an online, real-time infrastructure ... and performing real-time checking of what the merchant is really interested in .... will they get paid. An issue is whether the value of having a real-time online infrastructure is significantly depreciated if it is just being applied to checking status of stale, static information .... when for effectively the same infrastructure costs .... it can be used for real-time, online checking of real-time dynamic information (under the assumption that real-time checking of real-time dynamic information tends to have more value than real-time checking of stale, static information).

... i believe that the charge/cost at supermarket check-out for debit card transaction doing real-time checking for sufficient funds for the transaction (rather than just checking if the account still exists) as well as scheduling the transaction .... the charge/cost for both/combined ... is on the order of your projected lookup costs.

If the online, real-time validation of real-time dynamic assertion (rather the real-time validation of stale, static assertion) can be bundled with the actual execution of real transaction .... and be bundled for essentially the same cost of doing just online, real-time lookup of stale, static data .... then it would imply that stale, static data paradigm would be somewhat redundant and superfluous in an online, real-time environment.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

anders.rundgren@xxxxxxxx on 1/5/2002 2:44 am wrote:
I agree with Peter.

I don't think OCSP in a not so distant future have to be more technically costly than accessing a web-page. Including a signed answer.

Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is "comparable to putting a stamp on a letter".

Personally I don't think the VA-business model has much future as it complicates they way parties interact. It essentially requires two or three global VA-networks in the world to function and that seems very unlikely to happen. It feels like the VA business model is crafted according to the lines of credit-card authorizations, but that is a rather different type of business IMHO.

Pardon the slightly orthogonal input, but business & technology do have rather interesting connections...

Anders


OCSP and LDAP

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 02:01 PM
To: "Ambarish Malpani" <ambarish@xxxxxxxx>
cc: "IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: RE: OCSP and LDAP
the certificate typically contains some assertions (age, address, name, address, affiliation, etc) .... OCSP & CRLs are about the degree of possible staleness of the assertions/information contianed in the certificate .... not actual information itself

because the information is certified in the certificate ... at some time in the past .... by definition ... you aren't going to see dynamic information .... information in a certificate is about static information as of the time the certificate is created. OCSP & CRLs doesn't represent actual information .... it represents information about possibly how stale the static information is ... not the static information itself.

so a characteristic of the certificate offline paradigm is static information as of some point in the past. Online, real-time OCSP ... doesn't provide current &/or dynamic information .... it just provides some indication of how stale the static information in the certificate is.

An online, real-time infrastructure has the opportunity to transition to providing online, real-time, current, & dynamic information .... not limiting itself as to an opinion as to the degree of staleness contained in the static certificate.

The business issue .... is that going to the trouble & expensive of having an online, real-time infrastructure .... can be leveraged to provide real-time, online (& dynamic) information.

So as in some other scenario (non payment card) .... was the issue of gov. granting business licenses of various kinds. The brain-dead translation is to give them a gov. signed certificate representing that offline, paper license. Now people that want timely information in the non-electronic world .... go to online, real-time ... by calling and/or visiting the various agencies (better business bureau, local gov. office, etc) and check on the status of the license. Actually what most people do when doing real-time checks on a business .... isn't just that the business license is still valid ... but how many complaints, what kind of complaints, what kind of recommendations, disposition of complaints, any fines, etc. If they are going to all the trouble of having a real-time check .... they aren't after the OCSP version .... if they are going to all the trouble of a real-time check ... they want the real-time, dynamic data version of the informattion (not the old fashion, offline, static & possibly stale version of the data).

My assertions has not been that certificates (offline, stale, static information) are useless .... my assertions have been that if you are going to the trouble of having a real-time, online infrastructure .... that the value of that real-time online infrastructure is significantly enhanced by offering higher value information .... like real-time dynamic information. It isn't limited to the payment industry (lets say all electronic commerce) or licensing (all gov. sanction activities) .... I claim that for nearly all certification scenarios involving online, real-time ... the infrastructure goes to the trouble of having real-time dynamic data.

Lets take another example ... driver's license. If you get stopped .... the typical real-time, online response isn't about whether the license is revoked or not (that is trivial subset) .... it is how many traffic citations/warrents are outstanding .... number of parking tickets, and potentially some number of other pieces of real-time, dynamic information.

The issue isn't whether offline, stale, static certified infomration is useless. The issue is that in going to the trouble of having online, real-time facilities .... there is the ability and the value proposition to support online, teal-time dynamic information ... rather than offline, stale, static information.

All instances that I can think of where somebody is going to the trouble of some real-time, online checking .... they are getting real-time dynamic information ... not just a simple opinion about the possible degree of staleness of static, offline information.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

on 01/05/2003 12:15 PM wrote:
Hi Lynn,
Not sure why you associate OCSP with stale information. The responder can have as current information as you choose to provide it.

Once again, I believe it makes sense to have the interaction between the CA and the VA be CRLs. If there is more current information you have (than is present in the CRL), it makes sense to have that information at the VA for use until a new CRL is produced.

Ambarish

P.S. We have also had people use their OCSP responder to provide more than just certificate revocation information (eg. payment authorization) using extensions to OCSP.

---------------------------------------------------------------------
Ambarish Malpani 650.759.9045
Malpani Consulting Services ambarish@xxxxxxxx
http://www.malpani.biz


OCSP value proposition

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 02:33 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ambarish@xxxxxxxx, ietf-pkix@xxxxxxxx, madwolf@xxxxxxxx,
"Peter Gutmann" <pgut001@xxxxxxxx>
Subject: OCSP value proposition
ok, i'm a RP sitting here with a credential that contains some certified stale, static information .... that was designed to support an offline paradigm.

The RP believes there is some business/value operation involved which has some risk issues with the staleness of the information in the certificate.

A OCSP transaction provides the RP with some feeling as to the degree of staleness .... in theory to better mitigate risks associated with the value operation.

My assertions are

1) a online transaction can provide real-time, fresh, dynamic, and aggregated information (which is a superset of the stale, static information contained in the certificate) for approximately the same cost as a transaction about the staleness of the static certificate information. furthermore nearly every business/value operation in existence has some form of real-time, fresh, dynamic and aggregated information (for those mired in certificate paradigm ... view the online, real-time response containing this information as a one-time, immediately expiring certificate).

2) the superset of the stale, static information with real-time, fresh, dynamic, and aggregated information provides better quality risk management than an opinion as to the staleness of the certificate static information (at effectively the same cost).

3) given the same cost .... and greater value information for better risk management .... the cost/benefit analysis would nearly always benefit the real-time, fresh, dynamic aggregated response compare to an opinion about the degree of static information staleness.

4) the real-time, fresh, dynamic and aggregated information potentially provides the ability to piggy-back an actual business transaction as part of the underlying online operation (for little or not additional cost) .... this is the payment scenario.

5) for cost/benefit of risk management associated with real-time, fresh, aggregated, and/or dynamic may represent such a compelling business justification that all operations become online. For environment with all online operations, using real-time, fresh, aggregated, and dynamic information, then an offline certificate with stale, static information (that is a subset of real-time, fresh, aggregated and dynamic information) become totally redundant and superfluous. Certificates are at least redundant and superfluous for those transactions involving real-time, fresh, aggregated, and/or dynamic operations (if RP is getting the real-time superset information ... then the stale, static, subset information isn't needed).

So the question I believe was a value proposition for OCSP that

1) involves value that justifies having online, real-time infrastructure

2) doesn't involve payments or money (as per somebody else's earlier posting since it has already been shown that money infrastructure does a piggy-back transaction based on real-time, fresh, dynamic, and aggregated information).

3) only requires an opinion as to the staleness of static information (yes/no)

4) has no incremental business justification for real-time, fresh, dynamic and/or aggregated information.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

OCSP and LDAP

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 02:45 PM
To: "Ambarish Malpani" <ambarish@xxxxxxxx>
cc: "IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: RE: OCSP and LDAP
the thesis was that OCSP could provide a status indication as to the staleness of the static information in a certificate designed for offline operation.

an online service can provide almost any level of real-time, fresh, dynamic, and/or aggregated information. For a value business operation using online, real-time, fresh, dynamic, and/or aggregated information (that is a superset of the stale, static information in a certicate designed for offline operation) ... then both the certificate becomes redundant and superfluous and therefor an OCSP transaction as to the degree of staleness of the stale, static information becomes superfluous.

furthermore ... it has been trivial to show that for an operation involving transfer of money .... that the actual transaction for the transfer of money can be piggy-backed with the online, real-time, fresh, dynamic and/or aggregated information operation ... at effectively no additional cost .... and that then both a certificate and any OCSP are redundant and superfluous.

I can have online, real-time, fresh, dynamic, and/or aggregated information operation. Such information is a superset of offline, stale, static certificate-based information. If i'm using the online, real-time, fresh, dynamic, and/or aggregated information .... then the offline, stale, static certificate-based information is redundant and superfluous.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

OCSP and LDAP

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 04:50 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
    "IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: Re: OCSP and LDAP
but the whole point of an offline credential containing certified information is i can reference it offline. if i'm online .... i don't need a certificate.

in the non-certificate model .... i assert that i have account number #xxx and sign the assertion with hardware token.

that is sent off to the online infrastructure and it pulls up #xxx and verifies the signature with the public key in the online record.

the state of the account and all related information is pulled from the account. there is no offlne certificate containing any certified stale, static information.

in the payment transaction ... i make two assertions that I have account number #xxx and that i'll pay xyx .... I sign that assertion .... it is sent off .... the account #xxx is pulled up .... it checks the signature with the public key in the account record .... it checks the status of the account and decides about the payment and returns yes/no as to the payment (and whatever other information). No offline certificate with certified stale, static information is needed.

for the license ... I make an assertion that i have license #abc and sign the assertions with a hardware token. the police sends off the assertions .... which verifies the public key and pulls up the record .... either direclty containing all the real-time, fresh, dynamic, and/or aggregating information .... or contains enuf information to aggregate all the information. still no offline certificate with certified stale, static information is needed The police is using the online, realtime, fresh, dynamic, and/or aggregated information. The police doesn't have to resort to a offline credential containing a stale, static subset of the online, realtime, fresh, dynamic and/or aggregated information. It is purely an artificial contrivence to claim that a offline certificate with stale, static information provides any added value at the point when all of the online realtime, fresh, dynamic and/or aggregated information is available.

i only need a certificate with stale, static information for offline operations where i don't have access to online, real-time, fresh, dynamic, and/or aggregated information. If I have a superset of the stale, static information in a certificate .... then the certificate is redundant and superfluous for that operation. If the certifcate is redundant and superfluous .... then an OCSP operation that gives an opinion about the staleness of the redundant and superfluous stale, static information is also redundant and superfluous.

If the value proposition is such that I always resort to the online, real-time, fresh, dynamic and/or aggregated information .... then for those value propositions for an offline certificate with stale, static information is always redundant and superfluous. If the offline certificate with stale, static information is always redundant and superfluous ... then it would follow that an OCSP for a redundant and superfluous certificate is also redundant and superfluous.

so there is slight vulnerability issue here. not only is the certificate in somebody's position subject to being stale, static information ... but it is also potentially subject to counterfeiting (picture, name, address, birth date, etc). for low value operations with little risk .... the risk of counterfeited license is low. For high value operations with potentially more risk .... the "real" information is stored under strong security at the appropriate agency. The thing that is in somebody's hand is purely a stale, static offline copy of the real information stored online someplace. The law enforcement are bringing up the "real" information when they go onlne .... the stuff in your hand is basically a stale, static copy purely for low value, low risk, offline operations.

the claim that in an online environment .... that it is sufficient to have an authentication mechanism .... it isn't necessary in a real online environment to have any stale, static copy of the real information carried around on your person in a certificate for use in offline operations. If there are no offline operations .... then stale, static copies designed for use in offline operations are redundant and superfluous. For online operations, stale, static copies designed for offline use are redundant and superfluous when the real, online, fresh, realtime, dynamic and aggregated information is available.

-- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

"Anders Rundgren" on 01/05/2003 04:08 PM wrote:
>Lets take another example ... driver's license. If you get stopped
>.... the typical real-time, online response isn't about whether the
>license is revoked or not (that is trivial subset) .... it is how many
>traffic citations/warrents are outstanding .... number of parking
>tickets, and potentially some number of other pieces of real-time,
>dynamic information.

No problems.

The licensee authenticates to the "traffic police server" which uses OCSP to verify that the TTP-issued license is not revoked. Assuming the license was OK the server then invokes other "authorities" for any additional information needed using the identity as given in the license (certificate). The result is returned as a nicely formatted screen on the officer's PDA. Except for the fact that the screen is static [:-)], I don't see any particular staleness here. Unless for the possible reliance on CRLs you have a problem with. But CRLs are just an option.

But you do have a point. To put a lot of potentially stale information in a certificate is a bad idea. "Employee certificates" is an example of a broken scheme as they vouch for not less than three things: An individual, an organization, and an unspecified [= totally useless] association between these two entities. Here I really believe that your on-line, real-time paradigm will become the norm.

<snip>

Anders


OCSP and LDAP

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 05:04 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
"IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: Re: OCSP and LDAP
the driver's license in your hand isn't the real driver's license .... it is a stale, static copy made at some time in the past. the real driver's license is in some agency's database record. the issue about whether the real license is valid or not is stored there also. all the dynamic, fresh, aggregated, and/or realtime data is stored there ... or is pointed to by that record (if you want all the online, realtime, fresh, dynamic and/or aggregated information ... you have to read the real "license" record).

for low value &/or low risk operations ... the stale, static copy that you hold will be sufficient. for situations that justify the cost of an online transaction ... to get the real-time, fresh, dynamic, and aggregated real information ... they go online to get the real information.

somebody types in a driver's license number to the online system ... it could just spit back just a simple yes/no regarding the staleness of the static, r/o copy in the person's possesion. however, if somebody is going to the trouble of going online .... they type in the driver's license number to the online system .... and they get back the real license, with all the real-time, fresh, dynamic, and/or aggregated information. any information claims by the stale, static, static copy in the person's position .... at that point are redundant and superfluous.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

OCSP and LDAP

Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 05:15 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
"IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: Re: OCSP and LDAP
... aka ... i never said you can't have a certificate with stale, static, subset copy of the real information .... i just said that in an online environment where you have the real-time, fresh, dynamic, &/or aggregate of the real information ... then the stale, static, subset copy is redundant and superfluous.

for a particular business/value operation, if the stale, static, subset copy is redundant and superfluous ... then it seems to follow that an OCSP transaction giving an opinion about the staleness of redundant and superfluous information is also superfluous.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

OCSP and LDAP

Refed: **, - **
From: Lynn Wheeler
Date: 01/07/2003 06:42 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
"IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: Re: OCSP and LDAP
as been mentioned before ... it is relatively simple to see the information in certificates as form of distributed read/only cache entries ... with lots of similarities to cpu caches, database caches, filesystem caches, distributed/network databases, distributed/network filesystems, etc.

the data in the certificates is stale by defintion ... if it wasn't ... it wouldn't be necessary to have an OCSP that basically is asking if it is too stale.

some ten plus years ago i was at a acm sigmod conference and asked somebody what this x.500 stuff was ... and was told it is a bunch of networking types trying to re-invent 1960s database technology.

random past refs:
http://www.garlic.com/~lynn/aadsmore.htm#time Certifiedtime.com
http://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds of trust
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

OCSP and LDAP

Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/08/2003 05:37 AM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: ambarish@xxxxxxxx, anders.rundgren@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: OCSP and LDAP
on the other hand ... there some book someplace that makes the claim that relational set the state-of-the-art back 20 years.

I was somewhat involved having done some support infrastructure for system/r and then involved in the technology transfer of system/r from sjr to endicott for sql/ds (before the technology transfer back from endicott to stl for db2 .... note that SJR/bld28 & STL/bld90 are like 10 miles apart .... with both SRJ/STL on the west coast and endicott nearly on the east coast).

slightly related:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

some archeological tales:
http://www.garlic.com/~lynn/2000.html#18 Computer of the century
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?
http://www.garlic.com/~lynn/2001d.html#44 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#44 SQL wildcard origins?
http://www.garlic.com/~lynn/2002g.html#60 Amiga Rexx
http://www.garlic.com/~lynn/2002h.html#17 disk write caching (was: ibm icecube -- return of
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002k.html#9 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002l.html#71 Faster seeks (was Re: Do any architectures use instruction
http://www.garlic.com/~lynn/2002n.html#36 VR vs. Portable Computing
http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2002q.html#32 Collating on the S/360-2540 card reader?

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

ptut001@xxxxxxxx on 1/7/2003 10:52 pm wrote:
I've used that explanation too :-). The conversion went something like this:

Other person: "Why is X.500 so special? Why is no-one else doing this?"

Me: "Get your favourite book on database technology and look up 'Hierarchical databases'".

[Time passes]

Other person: "I looked in several books. Many didn't mention it at all, and one had a half-page historical note saying it's something that was obsoleted by better technology more than two decades ago".

Me: "Exactly".

Peter.


OCSP and LDAP

From: Lynn Wheeler
Date: 01/08/2003 05:51 AM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: ambarish@xxxxxxxx, anders.rundgren@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: OCSP and LDAP
total trivia:
from the previous aadsm5 references to:
http://www.garlic.com/~lynn/95.html#13

two of the people in the conference room went on to the small client/server startup involved in this thing called SSL & HTTPS ... one had been involved in the tech. transfer from SJR to Endicott for SQL/DS and one had been involved in the tech transfer back from Endicott to STL for DB2.

Of all the people in the meeting .... I believe only one is still working for the same employer they were then ... and that case isn't exactly considered employee ... most recently there has been some stuff about him getting ready to compete with some sailing team from "down under".

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

X.500, LDAP Considered harmful Was: OCSP/LDAP

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/26/2003 10:46 PM
To: Dean Povey <povey@xxxxxxxx>
cc: ambarish@xxxxxxxx, anders.rundgren@xxxxxxxx,
Tony Bartoletti <azb@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"Hallam-Baker, Phillip" <pbaker@xxxxxxxx>,
pgut001@xxxxxxxx, povey@xxxxxxxx
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
my original suggestion for SSL "certificates" stored in DNS .... was to just use signed something slightly more than signed public keys. as opposed to full x.509 asn.1 encoded certificates ... and piggyback it with the ip-address response. that easily fits within the 512-byte limit. if you want additional information .... you do the more detailed queries for the additional information associated with a domain name ... however you don't get all the additional information that might be bound to a domain name unless you expressly ask for it.

to some extent because certificates bind information statically at some point in the past with possibly no real anticipation for all the uses it might be put ... there is a tendency to try and pack as much as possible in the static binding. going to a much more dynamic infrastructure would mitigate significantly trying to maximize value of a static information certificate binding (and thereby creating worst case payload bloat for all cases).

nslookup example ...
> help
Commands:   (identifiers are shown in uppercase, [] means optional)
NAME            - print info about the host/domain NAME using default server
NAME1 NAME2     - as above, but use NAME2 as server
help or ?       - print info on common commands
set OPTION      - set an option
all                 - print options, current server and host
[no]debug           - print debugging information
    [no]d2              - print exhaustive debugging information
[no]defname         - append domain name to each query
    [no]recurse         - ask for recursive answer to query
[no]search          - use domain search list
[no]vc              - always use a virtual circuit
domain=NAME         - set default domain name to NAME
    srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2, etc.
root=NAME           - set root server to NAME
    retry=X             - set number of retries to X
timeout=X           - set initial time-out interval to X seconds
type=X              - set query type (ex. A,ANY,CNAME,MX,NS,PTR,SOA,SRV)
querytype=X         - same as type
    class=X             - set query class (ex. IN (Internet), ANY)
[no]msxfr           - use MS fast zone transfer
    ixfrver=X           - current version to use in IXFR transfer request
server NAME     - set default server to NAME, using current default server
lserver NAME    - set default server to NAME, using initial server
finger [USER]   - finger the optional NAME at the current default host
root            - set current default server to the root
ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE)
    -a          -  list canonical names and aliases
-d          -  list all records
-t TYPE     -  list records of the given type (e.g. A,CNAME,MX,NS,PTR etc.)
view FILE           - sort an 'ls' output file and view it with pg

============================

also some discussion in rfc2151/fyi30, Internet & TCP/IP Tools & Utilities, Section 3. Finding Information About Internet Hosts and Domains).
http://www.garlic.com/~lynn/rfcidx7.htm#2151
2151
A Primer On Internet and TCP/IP Tools and Utilities, Kessler G., Shepard S., 1997/06/10 (52pp) (.txt=114130) (FYI-30) (Obsoletes 1739)

from above:

One additional query is shown in the dialogue below. NSLOOKUP examines information that is stored by the DNS. The default NSLOOKUP queries examine basic address records (called "A records") to reconcile the host name and IP address, although other information is also available. In the final query below, for example, the user wants to know where electronic mail addressed to the hill.com domain actually gets delivered, since hill.com is not the true name of an actual host. This is accomplished by changing the query type to look for mail exchange (MX) records by issuing a set type command (which must be in lower case). The query shows that mail addressed to hill.com is actually sent to a mail server called mail.hill.com. If that system is not available, mail delivery will be attempted to first mailme.hill.com and then to netcomsv.netcom.com; the order of these attempts is controlled by the "preference" value. This query also returns the name of the domain's name servers and all associated IP addresses.

The DNS is beyond the scope of this introduction, although more information about the concepts and structure of the DNS can be found in STD 13/RFC 1034 [19], RFC 1591 [21], and Kessler [16]. The help command can be issued at the program prompt for information about NSLOOKUP's more advanced commands.


===

http://www.garlic.com/~lynn/rfcidx3.htm#1035
1035 S
Domain names - implementation and specification, Mockapetris P., 1987/11/01 (55pp) (.txt=122549) (STD-13) (Updated by 1101, 1183, 1876, 1982, 1995, 1996, 2136, 2181, 2308, 2535, 2845, 3425) (DOMAIN)

http://www.garlic.com/~lynn/rfcidx5.htm#1591
1591
Domain Name System Structure and Delegation, Postel J., 1994/03/03 (7pp) (.txt=16481)

somewhat related discussions:
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

povey@xxxxxxxx on 1/26/2003 6:10 pm wrote:
While I don't disagree with your argument about X.500, there are real practical problems with using DNS for storing Certificates (if that is indeed what you mean by a DNS linked PKI). RFC2538 notwithstanding, the problem is that storing large objects like Certificates in DNS generally necessitates TCP transfers as they will exceed the magic 512 byte limit at which servers will generally truncate packets. Using TCP means that DNS which is a generally stateless service, now has to keep connection state with clients opening up all sorts of room for DOS and simple performance problems with what is a critical service. In addition, it is common for admins to configure firewalls so that TCP DNS is filtered to prevent zone transfers.

Kansas kicks of satewide PKI project

From: Lynn Wheeler
Date: 01/29/2003 07:19 AM
To: Digital Signature discussion <DIGSIG@xxxxxxxx>
Subject: Kansas kicks of satewide PKI project
http://web.archive.org/web/20040703142016/http://www.washingtontechnology.com/news/1_1/daily_news/19935-1.html
also
http://web.archive.org/web/20040225115817/http://www.gcn.com/vol1_no1/daily-updates/21004-1.html

01/28/03
Kansas kicks off statewide PKI project
By Dipka Bhambhani
GCN Staff

Kansas today began issuing digital certificates to employees to use with a planned statewide public-key infrastructure from VeriSign Inc. of Mountain View, Calif.

Ultimately, Kansas plans to issue certificates to all its employees for use on the PKI created by VeriSign Inc. of Mountain View, Calif., said Ron Thornburgh, secretary of state for Kansas. The statewide PKI effort has been in development for six years with representatives from 15 organizations.

Kansas took a statewide approach to avoid having to integrate separate systems later, said Janet Chubb, assistant secretary of state.


... snip ...
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/05/2003 08:37 AM
To: Stephen Kent <kent@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, Olaf.Schlueter@xxxxxxxx,
    pgut001@xxxxxxxx (Peter Gutmann)
Subject: Re: Antwort: Re: Real-time Certificate Status Facility for
    OCSP - (RTCS)
i would claim in order to activate a digital signature, that the user needs to perform the RA function ... sending a signed message ... nominally containing a copy of the public key and some other identification information ... and this needs to be done regardless of whether the private kye originates with the user or is pushed out to the user. in the pre-push case, just because a private key push agency .... also acting as a CA, happens to pre-push a copy of the certificate prior to the RA function is an anomoly of the process.

in effect, what binds/activiates the digital signature process is the RA operation .... not the certificate .... the existance of a certificate is an implementation anomoly of the overall business process.

my bias has always been that the digital signature binding process is represented by the binding in the RA process .... independent of any existance of a certificate used in scenarios for trusted key distribution for offline environments ... aka the RA binding for the digital signature proccess is independent of the existance of a certificate as one means of representing that the RA business process has occured. in my AADS claims, online methods of indicating that valid RA process has been satisfied can be superior to generation of certificates as a representation of a valid RA business process.

I would claim that the direct equating of certificates to valid digital signatures contributes to the confusion. the RA binding process is what is used for establishing the basis for valid digital signatures. certificates (should be) just one method of representing that such a RA binding business process has occured. The confusion isn't that an agency can generate a private key and a certificate and push both out to the end user .... the confusion is the automatic acceptance that because a certificate exists ... it is equivalent to a valid digital signature binding process; the certificate should be just considered one way of representing a RA-binding process having been performaned.

of course, random refs:
http://www.garlic.com/~lynn/x959.html#aads

as noted in other recent threads there is sometimes confusion of asymmetric cryptography with the business processes of information hiding/secrecy and the business process of digital signature authentication. frequently for digital signatures, the business process may require that the private key never be known by anybody (and can only exist in a unique hardware token) .... while at the same time information hiding/secrecy will require private keys be escrowed (access to valuable corporate assets only accessable via a specific private key will mandate escrow for business continuity purposes). the technology is the same in both business processes .... but there are different secrecy requirements with regard to the treatment of the private key.

asymmetric crypto vis-a-vis public key business process ... hiding/secrecy and authentication/digital signature:
http://www.garlic.com/~lynn/2001g.html#14 Public key newbie question
http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure)
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#78 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003b.html#30 Public key encryption
http://www.garlic.com/~lynn/2003b.html#41 Public key encryption
http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for use with Outlook

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

kent@xxxxxxxx on 2/4/2003 7:02 pm wrote:
Olaf,

><SNIP>
>In Germany the german signature law is identifying a fourth case:
>4. the cert is in the repository, but not active yet (cert invalid,
>maybe valid in the future)
>
>This case is required (by law) if a CA issues not only certificates
>but private keys as well to the end user. Think of a bank producing
>and delivering a smartcard with keys and certificates on it to
>you. As long as you did not confirm the receipt of the card to the CA
>the CA must protect you by having the certificate "on hold" so during
>transport no valid signatures can be created. This may be handled by
>an "onHold" status on a CRL but is currently deployed in Germany
>using white list technology.

This seems an unnecessary complication. The CA could simply wait to post the cert to a directory until the user acknowledges receipt. I'm not in favor of adding complexity when there are other, simpler solutions to a problem.

>The second reason why german electronic signature technology is
>requiring a white list check is another obligation by law, namely
>that it is not allowed to render correctly issued user certificates
>invalid due to a CA key compromise (or any other kind of CA ceases
>operation). This is again achieved with white list technology and
>status information signed by a key with independent security. RTCS
>would fit well in here.

My response to Simon addresses this issue, i.e., German law seems to have mandated a solution to a problem that is not technically justified, given the alternatives. PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised.

Steve


A challenge

From: Lynn Wheeler
Date: 02/10/2003 05:18 PM
To: "Simon Tardell" <simon@xxxxxxxx>
cc: "'Anders Rundgren'" <anders.rundgren@xxxxxxxx>,
"'Denis Pinkas'" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx,
    "'Stephen Kent'" <kent@xxxxxxxx>, Olaf.Schlueter@xxxxxxxx
Subject: RE: A challenge
in fact ... any trusted source for the key can be used to validate the signature. a major point of the certificate is a business process that binds something else to the meaning of the signature (especially in an offline environment when there aren't recourse to online authoritative reference).

in the asuretee scenario ... the same hardware token (key) can be registered (aka the registration authority business process) with multiple different authoritative agencies .... potentially providing different bindings for signatures based on the context that the signature is used in.

in the encryption scenario (as opposed to the digital signature case), the sender already needs to have a table of public keys (which may or may not be in certificate form .... or stored already in un-encoded form for convenient usage) ... and must select the recipient's public key from the table.

a similar process is also possible in the digital signature case for something like a x9.59 financial transaction .... the financial institution can have pre-decoded the certificate and stored it in the account record at the time the consumer registers the account. It is then no longer necessary for the client to transmit the certificate as part of a digitally signed x9.59 financial transaction.

discussion of previously registered certification .... as well as (digital signature) certificates that have been compressed to zero bytes
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 Relying-Party Certification Business Practices

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

"Simon Tardell" on 2/10/2003 8:35 am wrote:

Anders,
> To have redundant certificates in case the CA goes haywire
> seems like a very peculiar solution and will force users to
> select the proper certificate. Which is?

Not at all. A signature is made with a key, not a certificate. As long as the identity of the certificate is not signed into the message, any certificate that corresponds to the right key can be used to validate the signature. The certificate may be sent with the signed message or obtained from somewhere else. It is largely the headache of the verifier.

The certificate that is used to verify the signature may even be issued after the signature is made. (And in fact, this would be a reasonable possible consequence of having CA redundancy -- after some time it could happen that both CAs that certify a certain key-identity-binding are replacement CAs deployed after the first signatures were made with the card)

For some reason the common paradigm is to let users chose a certificate associated with a key to imply the key. This practice requires the certificate to be present at the client. Or rather, a certificate. The certificate could be e.g. a self-signed cert (issued by the smart card itself at production time just to supply a GUI handle to applications looking for, and to supply a subject name for the end entity to claim, if the application needs one). This would remove the need to ever update the smart card. Or, as Sun would say, the network is the computer.

Simon

Simon Tardell, cell +46 70 3198319, simon@xxxxxxxx


A challenge (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/11/2003 09:23 AM
To: "Simon Tardell" <simon@xxxxxxxx>
cc: "'Anders Rundgren'" <anders.rundgren@xxxxxxxx>,
    "'Denis Pinkas'" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"'Stephen Kent'" <kent@xxxxxxxx>, Olaf.Schlueter@xxxxxxxx,
    epay@xxxxxxxx
Subject: RE: A challenge (addenda)
ref:
http://www.garlic.com/~lynn/aadsm13.htm#13

in fact, i would assert that is one of the short comings of mistaken the certificate being the binding ... as opposed to representing the business process of having done the binding.

in lots of businesses ... they will do their own binding business process .... based on their own business requirements. that is somewhat the appearance of the relying-party-only certificates as opposed to the earlier, one-size-fits-all, identity x509 certificates.

the issue is that the relying-party-only certificates are very analogous to a bank issuing a payment card .... originally one for every account or type of account. this is in the old offline days .... the merchant (standing in for the bank) in an offline environment examined the card and checked it against a paper booklet negative list mailed out once a month or so. in the transition to the online environment, a magstripe was placed on the back of the certificate .... and online transactions were being performed directly with the bank. this representing somewhat of a schizophrenia identity for the piece of plastic .... since it now carried the characteristics of operating both in the offline environment (the plastic credential and the paper booklet) or in an online environment (the magstripe on the back).

From a consumer perspective ... the incomplete migration to totally online .... has had a down side .... potentially tens of plastic cards needing to be carried around. The magstripe is just on the verge of not having to be unique. It still is shared-secret based (account number and pins) which standard security requires unique shared-secret for different security domains.

A migration to totally online and a migration to non-shared-secret (say digital signature public key) would eliminate the security requirement for 1) unique physical certificate/credential that is used in offline situations by stand-in parties/merchants responsible for examining the validity of the (plastic) certificate and 2) unique shared-secret.

The assertion is then that a single hardware token performing digital signature authentication can be used as binding device in multiple different contexts (since there is not the uniqueness security requirement that exists for shared-secret paradigms) and that the token would only require a certificate representing each of those binding contexts ... if the token were to be used in offline operations (requiring validation by 3rd parties not having access to the responsible binding authority). As long as the token was used in online transactions involving the business process that was also the binding authority .... or in business processes with entities that had online access to the binding authority ... then certificates representing such binding business processes are redundant and superfluous.

So the scenario is some future environment that is extensively digitally signature authentication oriented with some token. Continuing to emulate the old offline paradigm where a unique token/certificate exists for each context potentially means that individuals carry hundreds of such tokens. This is somewhat analogous to the evolving copy protection paradigm of the early 80s where each application required that a unique floppy disk had to be inserted. If this were to continue into todays environment an individual would have hundreds of copy protection floppy disks .... and constantly swapping floppy disks ... similarly one could imagine having hundreds of hardware tokens and having to constantly swap them.

Now there is some possibility of just returning to the simple, one-size-fits-all, identity x509 certificate. However, there is still the idea of binding a person to a specific bank account. Just because a person has a x509 identity certificate doesn't mean that they can draw money from every account at every bank (or the existence of a x509 certificate doesn't equate to being permitted to perform all possible business operations). If there is a single certificate ... and it represents all possible binding operations ... then either the information about all such bindings has to be carried in the same certificate ... or the bindings have to be available at some online location. So doing the mapping of the offline certificate paradigm to an online binding environment .... would imply that some value from the certificate is registered in the online binding registry/account-record. However, if some value is to be registered .... it is possible to have an account number and the binding registry directly registers the public key. This bypasses the levels of indirection involved in registering something about a certificate which is offline representation of some other business process that binds/registers something about the public key. If I were going to register something about a certificate in an online binding registry (say "is a specific entity entitled to withdraw money from this specific bank account") .... and a public key certificate is just an offline representation of some other online binding registry/authority (that just possibly isn't always online or directly accessible) ... I assert that it is possible to register the public key directly and dispense with the levels of indirection related to registering anything about the certificate.

So lots & lots of certificates ... each uniquely carrying some collection of possible binding attributes (like permissions, authorizations, etc). Or a few certificates .... that only carry a very few binding attributes related to a public key. Then individual operations carry online account records with the actual permissions and a mapping to some value in a certificate. However, it is possible in such situations to eliminate the indirection of registering the certificate that maps to the public key ... and just register the public key. Normally, levels of indirection help when they allow change w/o affecting all the binding registries .... aka in the internet domain name system .... I can use the host name www.something ... and not need to worry about it may having dozens of different ip addresses that can change over time. However, if i'm dealing with a certificate indirection infrastructure that I know is a direct mapping to a single public key and the same certificate will never mask a remapping to a totally different public key, then I can bypass the certificate indirection and just record the public key.

One such situation would be a generic employee certificate .... there are lots and lots of them .... all mapping to different public keys. There is an environment that doesn't have (or need) direct access to the online employee binding registry and only cares whether somebody has a valid employee binding (represented by their generic employee certificate) but doesn't actually care who the employee is (and the situation is low-value enough that it doesn't require real-time access to the real employing binding registry). However, this has the down-side attribute that it represents the lots & lots of certificate paradigm. a unique generic certificate is required for each unique (low-value) domain (work, home, ISP login, specific website, etc). As soon as something like ISP login requires specific authorization information .... it is either in the certificate ... or in an online account record. If it needs to register a unique value from a certificate that is unique for each authorized public key ... then it can go ahead and register the public key directly and dispense with any registering of anything related to a certificate (and some other agency's binding operation).

An ISP family certificate would work if it listed a dozen different public keys ... and the certificate could change the listed public keys in a trusted and reliable way that the ISP need never be aware that it was happening. However, in the internet domain name scenario this works because it is an online registry .... there aren't these offline credentials (representing the binding process) with long lifetimes floating around that can go bad and potentially need constant checking for revocation.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

A challenge

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/12/2003 01:47 PM
To: Torsten Hentschel <the@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, epay@xxxxxxxx
Subject: Re: A challenge
I assert that the traditional smartcards are somewhat like dinosours ... the signal just hasn't reached the brain yet.

I assert that the basic smartcard design point was during the '80s for a portable computing device .... that predated the availability of portable input/output capability. Basically you carried all the computing around in the 7816 smartcard form factor and used it at generic input/output stations. However, that market niche had disappeared sometime in the early 90s with the advent of portable input/output capability in the form of cellphones and PDAs. I would guess that up to that point there had been tens of billions of dollars in the technology that all had to be written off. To some extent the smartcard continues on with a little bit life of its own .... in part the investment has totally been written off .... and with zero-sum budgetting .... even if you only could leverage the earlier investment at a few cents on the dollar ... the technology continues to linger around.

So one of the places to leverage essentially the 7816 investment was supporting transferrable personality for cellphones. However, in the past year or two there have been articles on the incremental cost that providing such a reader represents in cellphone manufactur. Furthermore, this transferrable personality implementation still has several gaps .... the phone can be lost/stolen, there can be physical/electronic failure in the smartcard, and even the contact interface represents additional points of failure for the cellphone. The story line went something like an online backup/restore of the personality subsumes all the function of the smartcard as well as addresses all the additional shortcomings .... while negating the need for having the additional cost of the smartcard interface (as well as eliminating a point of failure in the cellphone). The issue is that even with only needing a few cents on the dollar (compared to the original 7816 investment) .... the smartcard in the cellphone still can't address all the requirements .... and the online back/restore which does address all the requirements then, obsoletes the necessity for the smartcard. And, as per the cellphone business discussions, cellphone manufactures can save some additional pennies on the cellphone manufactur as well as eliminating a point-of-failure (the contact infrastructure for sliding the card in/out).

There is a requirement to possibly uniquely identify the use of the cellphone. In the digital signature world ... that somewhat maps to a hardware token with an on-chip generated key-pair .... and the private key never leaves the device. This can be built into the cellphone .... either as ROM in an existing chip .... or as a separate chip somewhat like the TCPA strategy.

So a scenario is that as part of online restore into a new cellphone .... either a previous key-pair is backed-up and restored .... or that the device unique key is then re-registered in all the places that the previous cell phone had been registered. And as per my previous post in the thread ... the registration/binding business process is actually independent of whether or not a certificate is issued ... aka the original certificate design point (from somewhat the same '80s era as original smartcard) was a way of representing the registration/binding business process for an offline environment (which had no direct access to the authoritative registry).
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)

One problem is that even if the smartcard was purely restricted to the protection and digital signature use of a private key .... there still is the whole unresolved issue of lost/stolen devices ... and any moving parts (even just slipping card in/out past contacts) are more prone to failure than purely electronic operation. Note this is also given as one of the reasons for the migration to ISO 14443 and away from ISO 7816 is because of the mechanical failure issues ... especially in high-traffic areas. This brings up the whole issue of possible competing contactless technologies coming to bear .... 14443, 802.11, bluetooth, cellphone, etc.

some tcpa related discussions
http://www.garlic.com/~lynn/2002i.html#71 TCPA
http://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA
http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?

also
http://www.garlic.com/~lynn/x959.html#aads

has URL to a talk on assurance that i gave at the TCPA track at past intel developer's conference.

-- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Torsten Hentschel on 2/12/2003 1:31 am wrote
Hi Anders,

... snip ...

> ============================================
> But frankly I see no future in smart cards of the type Germany
> is investing in. A mobile phone is such a tremendously
> more powerful "container" that allows users to do things
> that smart card owners cannot even _dream_ about. Since
> mobile phones are on-line by definition, static key and
> certificate schemes then become rather irrelevant.
> ============================================

Well, mobile phones contain smart cards, don't they? I do absolutely not see the dead end here.

Kind regards,

Torsten
--
Torsten Hentschel
[The positions of mine as outlined above are not neccessarily


A challenge

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/13/2003 09:27 AM
To: epay@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, "Torsten Hentschel" <the@xxxxxxxx>
Subject: RE: A challenge
my previously post in this thread was more on the semantics of certificates
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)

rather than the most recent post
http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge
which is about 7816 contact smartcard. one of the issues is that 7816 also pretty much dictates the packaging and form factor. migration away from 7816 contact to any of the contactless/wireless conventions also can totally open up the packaging and form factor issues.

my certificate assertion wasn't that you can't have certificates representing a binding/association registration process, my assertion was that the certificates .... were actually that ... just a representation of a binding/association registration process (along with a side note that in an online environment the use of certificates as a representation of the binding/association registration process would frequently redundant and superfluous ... not that it wouldn't work).

My primary points were 1) that it seems that sometimes that the certificates are mistaken for the binding/associationr registration business process ... as opposed to just a representation of the binding/association registration business process (originally targeted for recipients who would never have been involved in any binding/assication registration business process) .... and 2) that sometimes such semantic confusion can complicate processes with regard to and which are addressing the binding/association registration business process and which are addressing just the management of things that represent that binding/association registration business process (especially in an online environment when having separate representations can be redundant and superfluous).

However, just because something may be redundant and superfluous doesn't mean that it can't work.

The issue in something like login .... is supposedly something has been registered to allow login .... in the PKI/certificate case, presumably what has been registered is some information that is bound in a PKI certificate (name, serial number, etc) ... in addition, the login process has the public key registration of acceptable certification authorities (that can be used to validate acceptable certificates to the login process). I've never claimed that doesn't work ... I've just claimed that frequently it is possible to show semantic equivalence between the login process registration of some value out of a certificate and the login process registration of the public key directly;

The PKI registration process provides a type of information mapping indirection (somewhat like DNS provides a real-time mapping between hostnames and ip-address) .... where the CA digital signature asserts to the equivalence of the information (like a person's name or userid) bound in a certificate and a public key. The login process then has a set of registered CA public keys. In the PKI scenario, the login process gets a signed message that has an appended digital signature and an appended certificate. The login process finds the registered CA public key and validates the certificate, it then uses the public key in the certificate to validate the signed message. At this point it presumably has a proven equivalence between the entity sending the message and some bound information in the certificate (like a name). The login process can then have its own registry that maps between names found in certificates and userids .... and uses that to establish a valid login for that userid. The informaiton assurance mapping goes

I've never asserted that it doesn't work. I have asserted that in situation where the login process has its own registery and mapping; that directly registering an entity's public key bound to a userid .... can be equivalent to a entity registering their public key with a CA, the CA signing a certificate that equates a name in a certificate with that public key, and then the login process registering a name in a certificate bound to a userid. The issue isn't that the levels of PKI information indirection (between public key and userid) don't work, the point was purely that they may be redundant and superfluous.

This is somewhat equivalent to the IETF pk-init draft for Kerberos which provides for both certificate (aka PKI) based registration as well as certificate-less based registration .... aka directly registering the entity's public key. The business process of registering a name from a certificate as equivalent to a userid .... can be shown to be the same as directly registering a public key as equivalent to a userid. The issue then is whether all the additional business processes in support of the various registering process providing information indirection between the name in the certificate and the entity's public key provides real value or is purely redundant and superfluous (given that there has to be a complex infrastructure for not only creating the certificates .... but once created these certificates now also have to be managed).

Now the intersection with certifications and smartcards (actually hardwoare token) .... was whether there was a unique token/certificate pair for every environment or whether there was one (or a very small number of) token(s) could be used across a multitude of environments. If the environment supported a registration process, then the above assertion that public key can be directly registered would support that the public key of a single token could be registered in multiple environments. The counter-argument is some future environment that has migrated to hardware token authentication potentially requiring a unique token per environment and an entity possibly having to manage hundreds of such tokens.

So an additional assertion is an ideal place for certificates is where there isn't an additional registration process and the certificate is sufficent for establishing both authentication as well as permissions (aka all/any generic employee certificate gets an entity through the door).

A corresponding scenario would be a system login that has no userid directory/registration and when presented with a login message with an attached certificate .... it is possible for the login process to establish the complete user environment from just the contents of the certificate (not requiring a userid directory/registration at all).

The problem is that tends to require a unqiue certificate for each environment ... which may or may not imply a corresponding unique hardware token. If it requires a unique hardware token, then the future possibility is that people walk around with hundreds of hardware tokens.

Moving it out of the digital signature domain but still in the area of authentication might be biometrics. There is the possibility that a login process directly registers a person's fingerprint in the userid directory. The person then types in their userid and applies their finger to a fingerprint sensor. I assert that the direct registration of a person's fingerprint in a userid directory is equivalent to the direct registration of a public key in the userid directory. However, the downside is that a person's fingerprint is, in effect, a shared-secret ... anybody copying the fingerprint representation and being able to regenerate it can impersonate that entity. The upside of public key registration is that it isn't a shared-secret, knowledge of the public key isn't sufficient to impersonate.

So sort of a summary .... 1) understanding that the binding/registration process is indenpendent of certificates that represent that process can result in better designs dealing with the two sepaate issues and 2) when there are additional registries (like userid directories) it is possible to view certificates as a type of information indirection and that such levels of indirection may be redundant and superfluous (not that they can't work just that they are redundant and superfluous).

some kerberos related threads:
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and somewhat topic drift ... redundant and superfluous may represent additional complexity and cost that are hard to justify. From recent discussion about DNS, KISS, theory, and practice:
http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi
http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment
http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment

-- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

tjones@xxxxxxxx on 2/12/2003 8:21 pm wrote:

For better, or worse, the current sc logon to o/s's uses a cert in the sc. It could be argued that the sc really only needs to cache the user's name in an insecure manner, but the point is that a PKI is used to authenticate the user w/ the sc. It seems to work. It's hard to imagine how it could be improved by some structure other than a PKI. There is no biz rule associated w/ the authentication.

I doubt that u can argue that it does not work. I am sure that a better sol'n is possible, that is always true.

So, let's just use sc w/ cert for logon authN. Ok? ..tom


A challenge

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/13/2003 10:22 AM
To: Al Arsenault <awa1@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, ietf-pkix@xxxxxxxx, Torsten Hentschel <the@xxxxxxxx>
Subject: Re: A challenge
the article from the cellphone manufactures .... that it was less expensive to provide a mechanism to save the current personality and load it into a new phone than it was to manufactur the slot for the smartcard reader interface ... with a overall infrastructure cost savings. the corresponding assertion was that the current smartcard & smartcard interface was as inexpensive as it was because of the significant investment that was made for generic, unbiquitous smartcard use .... not solely restricted to cellphone personabilities. and finally people could use the personality save/restore to address issue where the smartcard is lost/stolen/damaged.

My other assertion was that the existing operation may linger for some time .... since the original smartcard investment has appeared to be written off .... and smartcard use can essentially be had for a few cents on the dollar. The transition to save/restore requires new investment in the save/restore infrastructure .... which means that the cost savings in eliminating the smartcard reader in cellphones would have to cover the save/restore infrastructure investment (and/or people find the additional benefit of having lost/stolen/damaged coverage).

Note that the cost savings of using a common smartcard infrastructure is so great that the cellphones and the simms share the same manufacturing components .... down to simms being manufactured as smartcards ... and then the simms punched out of the plastic smartcard form factor. If the other uses of smartcards migrate to various contactless/wireless paradigms for various reasons .... that could mean that cellphone market segment would carry more of the smartcard infrastructure costs (even at a few more cents on the dollar) making it easier to justify the funding of a save/restore infrastructure transition.

I didn't say smartcards were wrong. I said that they had a design point based on the technology from the '80s ... and that changed by the early '90s .... effectively making the technology assumptions and requirements from the '80s no longer valid.

I wasn't making them (OSI comments) very loud in 1983 ... I was doing some other things, although there were jokes about OSI being from pre-1970s, telco, point-to-point copper, high error rate, low bandwidth design point "people" ... aka by the time OSI standard was passed it was also obsolete. While i was doing a little tcp/ip stuff in the 1983 era .... it wasn't a primary focus and I didn't get involved into any OSI issues into slightly later.

I was starting to get more vocal about OSI by possible 1985 .... I was starting to become more vocal about it. By interop '88 I was pretty vocal .... there were all these things in there with OSI, x.400, complex monitoring. One of the things at interop '88 ... i would guess that there was even some significant percentage of the IETF community was supporting various of the alternate candidates to SNMP. I had a couple workstations in booth kiddy-corner from the booth where case was "officially" located ... and was able to get Case to install SNMP on the workstations to demo .... even tho large portions of the rest of the booths had various SNMP alternatives.

I was also on the XTP technical advisory board and working on HSP. The majority of the people in X3S3.3 were giving us really bad time because X3S3.3 had responsibility for standards related to OSI levels 3&4 ... and the official charter is that you can't have standards that violate OSI levels 3&4. My response was 1) ISO & ANSI are already totally schizophrenic because ethernet standard thru IEEE and recognized as standard at ISO combined levels 1, 2, and part of 3 ... i.e. the MAC interface includes a portion of routing from level 3. HSP was going to go directly from transpart/level4 to LAN interface in the middle of level3. Core X3S3.3 basically said that you couldn't have protocol standard work in X3S3.3 that specified an interface to MAC/LAN .... because that violated OSI. I've had more than a few choice words about gosip also.

slightly related .... my wife and I were operating a backbone at the time of NSFNET1/T1 bid ... and weren't allowed to bid ... but a NSF audit of our backbone claimed it was at least five years ahead of all the NSFNET1/T1 bids to build something new. We were also doing some interesting/non-traditional things with crypto at the time ... but that is another story. However we did come up also with 3-layer architecture .... somewhat grew out of a response that my wife wrote and presented to a certain TLA gov agency RFI for enterprise distributed computing environment. That got us into trouble from various factions that were trying to put the client/server genie back into the bottle:
http://www.garlic.com/~lynn/subnetwork.html#3tier

OSI was possibly a bad choice to choose as an example. However, something that I was really agitated about in the early 1980s time-frame was that the traditional mainframe computing environment was starting to commoditize .... first with mid-range computers and then with PCs and workstations. Maybe another example is this thing called electronic commerce.

lots of threads related to OSI "blech":
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

some recent discussions about interop '88
http://www.garlic.com/~lynn/subnetwork.html#interop

past threads about high speed networking in the '80s
http://www.garlic.com/~lynn/subnetwork.html#hsdt
http://www.garlic.com/~lynn/subnetwork.html#internet
http://www.garlic.com/~lynn/subnetwork.html#bitnet

random past specific mentions regarding gosip:
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom.
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2001e.html#17 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet
http://www.garlic.com/~lynn/2002m.html#59 The next big things that weren't
http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?

-- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Al Arsenault on 2/13/2003 5:43 am wrote:

Lynn,

Interesting message from you, as always. Fascinating predictions on the future. Only a few issues need to be raised, IMHO. :-)

One of those issues relates to the whole "secure backup and restore" or "secure download" of credentials. That's currently an unsolved problem. Fortunately, IETF has a working group - SACRED - addressing that issue. While SACRED started out a couple of years ago with a lot of interest and enthusiasm, interest seems to have waned. There are only a few people actively participating, and the group is about to wrap up with its solution. While I am others hope that the proposed solution will succeed and solve parts of the problem, it's not a complete solution (e.g., it addresses only device - credential server interactions; it doesn't support device - device operation). So consider this message a plea for others interested in this area to get involved in this work.

Until SACRED or some similar solution becomes widely implemented, smartcards - e.g., SIMs or WIMs in phones - aren't going away. The business model in many parts of the world relies on a large number of customers replacing their handsets frequently. In many areas I'm familiar with, it's common for a large set of people to replace their handsets every few months, so that they always have the latest, smallest, most colorful, "coolest" device. The whole notion of a smart card supports this model, by allowing the user to get a new handset and dispose of the old one while maintaining the same service WITHOUT INTERACTING with the mobile operator, because those interactions with the carbon-based life forms who staff the operator outlets represent one of the highest costs in the system. With a SIM/Smart card that can be moved from one handset to another, there's no need to involve any other carbon-based life form. Since there's now no way to securely move the credentials electronically that's widely interoperable (lots of us have our own, somewhat proprietary schemes), for most mobile operators/service providers the smart card remains the method of choice.

An automated - read as "efficient and low cost" way to securely register new devices into the system is also a requirement, and it's also currently an unsolved problem. Oh, there are other standards groups working on it, but I'm not sure they're going to have good solutions any time soon.

So it's nice to sit here and make statements that "this technology was just wrong, and 20 years from now everyone will acknowledge that it's obvious", but tell me Lynn, how many statements about ISO vs. TCP/IP did you make in 1983?

Al Arsenault
Diversinet Corp.


A challenge

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/14/2003 10:31 AM
To: Al Arsenault <awa1@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, ietf-pkix@xxxxxxxx,
Torsten Hentschel <the@xxxxxxxx>
Subject: Re: A challenge
one of the factors driving 7816 standardization/commoditization in the '80s was that 7816 was a portable computing device ... but was dependent upon somewhat ubiquitous deployment of (stationary) input/output stations.

the spread of integrated portable input/output technology (cellphones & pds) in the early '90s started to chip away at the original 7816 target market (i.e. portable computing devices w/o requirement for ubiquitous input/output stations.

further eroding this target market is the spread of numerous contractless/wireless technologies. a big part of the 7816 standardization was the requirement for physical interoperability between the portable 7816 devices and the input/output stations. contactless technologies enable arbitrary form-factors .... further chiping away at the 7816 market segment. one of the targets for iso 14443 is a current primary 7816 market segment, point-of-sale .... where the contact infrastructure is showing failures .... especially in high-traffic areas. contactless/wireless breaks the requirement for form-factor specific implementation (required by contact interoperability) and starts to allow interoperability with devices regardless of their form factor.

for the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aadsstraw

in '98 timeframe, i had somewhat facetiously claimed that i would take a $500 milspec part and cost-reduce it by two-orders of magnitude while improving the integrity.

at an assurance panel in the TCPA track at the intel developer's conference, i claimed that the chip met all the function/requirements of the TPM (and was finalized much earlier) and was equivalent to the best of integrity from gov. agencies. One of the TCPA people in the audience commented that wasn't fair since I didn't have a committee of 200 people helping me. One of the people on the panel from a gov. TLA replied that it was possibly true except in the area of radiation hardening. other past tcpa related posts:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#14 Challenge to TCPA/Palladium detractors
http://www.garlic.com/~lynn/aadsm12.htm#15 Challenge to TCPA/Palladium detractors
http://www.garlic.com/~lynn/aadsm12.htm#16 Feasability of Palladium / TCPA
http://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#63 Intertrust, Can Victor Shear Bring Down Microsoft?

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

A challenge

From: Lynn Wheeler
Date: Fri, 14 Feb 2003 11:12:15 -0700
To: epay@xxxxxxxx
Cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"Torsten Hentschel" <the@xxxxxxxx>
Subject: RE: A challenge
the point was offline from the registry

in login there is either

1) registry in the unit requiring logging in which contains a binding between some identity and the permission's (i.e. what things can log in and do).

2) or a purely ROM logging-in process that accepts any and all certificates signed by some prespecified CA .... and will perform whatever operations indicated by the certificate.

in previous posting outlining a logging in scenario where there is some local registry in the device .... that is also certificate based .... the local device registry has both the list of acceptable public key certificates as well as some list of acceptable identification information from one or more certificates. The person presents a certificate, an attempt is made to validate the CA signature from the list of valid CA public keys in the registry .... and then some identification information contained in the certificate (say a person's name) is used to look up a registry entry for "certificates" that are allowed to log in and possibly their mapping to permissions and authorization. The public key from the certificate can be used to validate a signed message .... either before or after the lookup to see if there is a userid registry entry that corresponds to some identification field in the certificate (say person's name).

My assertion is that in the case where there is registry of valid userids with a mapping to a value in the certificate .... the whole infrastructure is equivalent to "information indirection" paradigm provided by the certificate infrastructure.

Say I buy a mobile device .... and want to establish my "ownership" by registering my certificate in the device as the true owner. So in the device are:

1) table of CA public keys
2) certificate with my public key and maybe my name signed by one of the CAs
3) login message
4) my signature on the login message

I assert that the levels of indirection can be totally eliminated by instead replacing the table of CA public keys with a table of "owner" public keys .... and mapping the table of "owner" public keys directly to permissions.

The table of CA public keys are eliminated and replaced with a table of owner "public keys". The registry mapping some certificate field unique identifier to permissions is eliminated and instead the registry of permissions are mapped directly to owner "public keys". The information indirection provided by the CA PKI infrastructure and the certificates are eliminated.

The issue with regard to being offline from the registry is where there is no local registry which maps a certificate field to local device permissions. The local device has no access to the registry mapping certificate field to permissions ... and therefore must totally rely on information within the certificate as to what permissions are entitled.

This "offline" infrastructure has only a CA table of public keys in the device. Certificates are presented signed by any of the acceptable CAs. The device then extracts all permissions directly from the certificate because it doesn't have online (or otherwise) access to the registry of permissions for this device.

So my original assertion is that if the device has access (online or otherwise) to the registry of permissions for the device .... the indirection infrastructure provided by PKI certificate based operation can be collapsed to replacing the CA table of acceptable public keys with a separate registry of permissions to a single combined registry table containing the acceptable public keys and the associated permissions.

So looking at PKI from the reverse standpoint, a PKI is an extension of the single combined registry table to a two level structure (in its basic form). The simple door entry scenario previously described is a singled combined registry table .... where the "owner" is directly mapped to permissions. The permission "owner" is able to authorize agents or surrogates by way of certificates. An "owner" can directly enter by signing a message with their public key ... or they can authorize others to enter by signing certificates containing the surrogate/agent's public key. The door entry validates the surrogate certificate as coming from a valid owner ... and then validates the agent/surrogate's digital signature. The door entry system doesn't require any access to any registry containing any information regarding anything about the surrogate/agent.

The assertion is that anytime that the local environment needs a local registry regarding specific surrogate/agent operation .... then the certificates are a form of information indirection and likely redundant and superfluous .... since the surrogate/agent's public key can be directly added to the single permissions table. Logically permissions are a single table. For arbritrary implementation reasons the table of permissions for CA public keys .... may be implied permission of only signing certificates for delegating authority to surrogate/agents. However, the permission table may be expanded for CA public keys to the type of delegation that specific CA can perform.

However, as soon as there has to be a local decision with regard to a surrogate/agent permissions in a local registry directly accessable by the device .... then I claim that the levels of indirection provided by a certificate can be eliminated and the surrogate/agent's public key be directly registered.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

tjones@xxxxxxxx on 2/14/2003 9:31 wrote:

Note that the point of logon is that mobile computers need to work off-line.

So any logon proceedure needs to accomodate off-line as well as on-line.

As you point out, cert were designed in an off-line scenario. Seems to fit the problem nicely.

If we don't have smart cards with certs in them, we need to put the cert (binding) in every mobile device that would use that info.

That would assume that the mobile device was more secure than the smart card/cert combo, and had more current info.

My experience w/ mobile devices, including cell phones, leads me to believe that neither of these is true.

..tom


surrogate/agent addenda (long)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/14/2003 03:02 PM
To: epay@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, "Torsten Hentschel" <the@xxxxxxxx>
Subject: surrogate/agent addenda (long)
I claim that I can model an operational environment in terms of entities and permissions (for simplification attributes are also modeled as a kind of permission).

Registry is defined to be the method that an operational environment uses to map entities to permissions. A registry may be a single operational thing or it may be made up multiple things both explicit and implicit.

Digital signatures and public keys are used to authenticate entities to the operational environment. The operational environment uses public keys in the registry to represent entities (since they are unique to the authentication of the entity). The mapping between public keys and permissions is a function of the registry entry.

CA/PKI further extends the kinds of permissions to "delagation". A CA entity/public key is given the permission of delegation.

A CA uses its own registry to provide a mapping between entities, public keys, and permissions. A CA then signs a stale, static copy of some of the fields in its registry and calls it a certificate.

An operational environment can authenticate delegated permissions from a signed certificate by using the public key of a CA entity from its own registry. Just for some convention I'll call delegation entities: surrogates/agents. Full blown PKI defines the possibility of a multi-level delegation as a trust hierarchy.

So my repeated assertion is that if the operational environment accesses a surrogate/agent registry entry (local, remote, online, etc) then the corresponding surrogate/agenty certificate can be shown to be redundant and superfluous.

So, I've managed to explain this redundant and superfluous characteristic in a number of different ways:

1) a registry entry can contain anything that a certificate can contain, therefor all fields that can occur in a certificate can also be placed in a surrogate/agent registry entry. Also, for every field that can exist in a certificate can be placed in a registry entry. When all fields from a certificate are placed in a registry entry, the certificate can be compressed to zero bytes. These certificates aren't actually redundant and superfluous, they are just zero bytes.

2) the creation of a registry entry for a surrogate/agent is equivalent to a registration authority business process. anything that is done during a CA's RA process can be done during the creation of a registry entry for the surrogate/agent. If necessary, this can be viewed as caching the certificate in the surrogate/agent registry entry. Then while the certificate isn't strictly redundant and superfluous, any transmission of the certificate is redundant and superfluous since the operational environment already has access to the cached entry. This is especially useful when the inclusion of a certificate in a transmission represents a painful bloating of the total transmission size.

3) when there is a directly accessable registry entry (local, remote, online, etc) for a surrogate/agent, then the certificate may just represent information indirection .... somewhat like DNS system mapping of hostname to ip-address. the registry entry contains some value that can be matched to a field in the certificate. This provides a indirection mapping between the permissions in the registry entry and the entity's public key in the certificate (authenticated & deligated by the CA signatures and the CA entry in a directly accessable registry entry). However, since any value that can occur in a certificate can also be placed in the registry entry, the public key from certificate entry can be directly placed in the surrogate/agent registry entry, eliminating the indirection provided by the certificate and making the use of the certificate redundant and superfluous.

4) an operational environment may require direct access to a surrogate/agent registry entry (local, remote, online, etc) because of permissions expressed in terms of aggregation information (information that is maintained in the registry entry that represents information aggregation and is a difficult paradigm for a stale, static certificate) or permissions expressed in terms of real-time or near real-time information (again difficult paradigm for a stale, static certificate).

5) If a stale, static certificate provides an identifier that is used to index a surrogate/agent registry entry (local, remote, online, etc) then it is also possible to include the same identifier as part of the message digitally signed by the surrogate/agent. As before, such a surrogate/agent registry entry can include anything that a certificate can include, including the public key of the surrogate/agent. By directly placing the public key in the surrogate/agent registry entry, and directly accessing the surrogate/agent registry entry using an identifier from the signed message, then the signed message can be authenticated using the public key from the directly accessed surrogate/agent registry entry. The directly accessed surrogate/agent registry entry can contain any other field that might exist in the certificate, including all possible permission values. Since the digital signed message can be authenticated without having to resort to the certificate and since the directly accessed surrogate/agent registry entry can contain any field that a certificate can contain, the stale, static certificate transmitted as part of the message is redundant and superfluous.

The simplest scenario for a stale, static certificate is in an operational environment that only accesses a CA delegation registry entries and permissions are solely established on the basis of the contents of the CA registry entry and the contents of the certificate. This is the employee certificate that is used for door entry. The door entry operational environment only contains the public key of one or more CAs. The door is opened purely based on being able to validate the CA's signature on the certificate and then validate the employee's signature using the public key in the certificate. For opening the door, there is no recourse to any employee specific entry. This is the typical "offline" door operation typical of low value situations. Higher value door operations tend to be "online" in the sense that they directly access employee specific registry information. Such online permission entry can be based on timely information (like has the employee been fired within the past couple hours) or aggregation (what other things has the employee done in the recent past). It is in the accessing of the employee registry entry (local, remote, online, etc) for timely and/or aggregated information that makes the use of the stale, static certificate redundant and superfluous.

Similarly a portable device can either be "offline" in the sense that its operation is totally determined from just a CA public key registry and a stale, static certificate (and doesn't have direct access to the surrogate/agent registry entry). Lets say there are large number of "public" portable device and anybody can utilize any device so long as they have a valid certificate for device useage. However, a certificate can become redundant and superfluous if the device has a surrogate/agent specific registry entry that it references (since it is possible to register any information that might be found in a certificate, in a surrogate/agent registry entry). A portable device that might contain a surrogate/agent specific registry entry might be a owner-specific paradigm (i.e. the surrogate/agent registry entry in the device corresponds to the owner). A onwer-specific paradigm could be implemented with certificates if the certificate contained the device specific identifier. The device would only work when a certificate was presented that contained the device-specific identifier in one of the certificate fields.

Lets say we are looking at a hardware token implementation as keys for automobiles. For an owner specific paradigm there can be a certificate/PKI based implementation or a certificate-less based implementation. In the PKI-based implementation the automobile's internal permission registry table contains one or more CA public keys. The car starts for any hardware token that has a digital signed certificate that specifies the specific automobile serial number and authenticated by any of the CA public keys (and of course the hardware token signs a valid message that is authenticated from the public key in the certificate). The certificate-less implementation replaces the CA public keys in the automobile's internal permission registry table with public keys of the owner's hardware tokens. Then only the directly listed hardware tokens are able to start the automobile. In the certificate-less scheme, there would be a administration mode used in conjunction with a valid hardware token to add/delete public keys in the automobile's registry.

In the PKI-based implementation for "owned" automobile operation, it becomes somewhat more problamatical to invalidate hardware tokens (aka certificates) for the automobile. One method would be to create registry entries for invalidated certificates (aka public key/hardware token). However, I would assert as soon as surrogate/agent specific entries are required for invalidated public keys .... then the infrastructure has been established making certificate-less operation KISS (aka stale, static certificates being redundant and superfluous). Just create a positive list/registry of public keys .... possibly totally eliminating the delegation permission associated with CA public keys. The automobile registry than has permissions like administrative mode, start automobile, open trunk, open doors, etc for each public key (aka hardware token).

It is problamatical whether CA public keys would be retained in the automobile registry solely associated with manufacture and service operation. Standard automobile operation would be straight certificate-less with the owner's hardware tokens being directly registered in the automobile's registry table. However, there might be non-ownership related permissions like various service operations. There could be a manufacture CA delegation permissions associated with service operation and independent of automobile serial/identification. The manufacture's public key would be in the automobile's table with delegation permissions. The manufacture would sign public key certificates for service operations, enabling service specific permissions for all cars from the manufacture.

However, CRLs really become a nightmare in this situation. I would contend that a much KISS solution is that the service operation goes online with the manufacture (in much the same way that POS terminal do online transaction) and that the automobile authenticates the service operation by accessing the manufacture's online database. The manufacture's public key is still in the automobile registry .... not for purposes of validatting certificates but for purposes of validating online communcation with the manufacture for authentication of real-time service organization delegation. As a result, the operation is online with direct access to registry entries for service organizations and therefor service organization certificates are redundant and superfluous.

past references regarding compression of certificates to zero bytes:
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 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#kiss6 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#6 Public Key Infrastructure: An Artifact...
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#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates

past references to methodology of registry operation caching certificate kind of information (making certificate transmission redundant and superfluous)
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm4.htm#8 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC)
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2003.html#52 SSL & Man In the Middle Attack

past discussions of stale, static certificate issues vis-a-vis aggregated/timely information:
http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against Virtual Banks (fwd)
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
http://www.garlic.com/~lynn/aadsmore.htm#client2 Client-side revocation checking capability
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
http://www.garlic.com/~lynn/aadsm2.htm#arch4 A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#availability A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#mauthauth Human Nature
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm4.htm#01 redundant and superfluous (addenda)
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki24 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your account-authority model (small clarification)
http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital Signatures ... in support of x9.59
http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#x9flb12 LB#12 Protection Profiles
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
http://www.garlic.com/~lynn/aadsm12.htm#20 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#0 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#2 OCSP value proposition
http://www.garlic.com/~lynn/aadsm13.htm#3 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#6 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/98.html#0 Account Authority Digital Signature model
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#42 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
http://www.garlic.com/~lynn/2001.html#67 future trends in asymmetric cryptography
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#68 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/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

A challenge

Refed: **, - **, - **
From: Lynn Wheeler
Date: 02/16/2003 05:56 AM
To: Al Arsenault <awa1@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>, epay@xxxxxxxx,
ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx,
    Torsten Hentschel <the@xxxxxxxx>
Subject: Re: A challenge
somewhat addenda to question about '83 OSI .... while iso/x3s3.3 couldn't have a work item for standard that violated OSI (i.e. HSP, high-speed protocol .... direct from level4/transport to LAN/MAC interface which sits in the middle of level3/network) .... x3s3.3 could have a work item that studied HSP.

note also that IP also violated OSI ... since it is a layer that sits between level4/transport layer and level3/network layer .... the inter-networking layer. however, IETF doesn't have any qualms about having IP interface directly to LAN/MAC.

as before ... internet archeological references from 82/83:
http://www.garlic.com/~lynn/rfcietf.htm#history 20th anniversary of the internet!
http://www.garlic.com/~lynn/2002p.html#38 20th anniversary of the internet
http://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet
http://www.garlic.com/~lynn/2002q.html#22 20th anniversary of the internet

and a little more thread drift, a recent archeological reference to something else that i was doing about that time
http://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?

and the whole thing about thread between loosely-coupled, sysplex, high availability, cluster, supercomputers, and electronic commerce:
http://www.garlic.com/~lynn/2001i.html#52

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Encryption of data in smart cards

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 12 Mar 2003 11:50:06 -0700
To: raghu@xxxxxxxx
Subject: Re: Encryption of data in smart cards
Cc: cryptography@xxxxxxxx
At 10:39 AM 3/11/2003 +0530, N. Raghavendra wrote:
Can anyone point me to sources about encryption of data in smart cards. What I am looking for is protocols for encrypting sensitive data (e.g., medical information about the card-holder), so that even if the card falls into malicious hands, it won't be easy to read that data.

a lot of cards use derived (symmetric) keys ... similar to the derived key per transaction X9 standards. they are used to protect data from outside examination and in multi-function cards to provide protection domains between the different applications on a card.

typically there is a system wide key that you would find in a secure terminal (like transit systems) that read data, decrypt it, update it, re-encrypt it and write it back to the card. this handles situations involving attacks with fraudulent readers that load fraudulent value on the card. given the possibility of a brute force attack on the infrastructure (aka getting the data out of one card, and finding the master system key) ... many systems go to some form of derived keys. They typically amount to one-way function that combines the system-wide key with something like an account number from the card that results in the derived key. A brute force attack on the card data .... will only result in obtaining the card-specific, derived key .... and not the system-wide master key. All secured readers, knowing the system wide key and some card identification can always calculate the derived key for a card.

misc. derived key stuff ...
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC)
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders?

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Certificate Policies (was Re: Trivial PKI Question)

From: Lynn Wheeler
Date: 03/13/2003 10:30 AM
To: Al Arsenault <awa1@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, Margus Freudenthal <margus@xxxxxxxx>
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
a similar argument was used with regard to plastics cards turned smartcards .... however the most common failure was lost/stolen wallet containing all such cards. there was absolutely no difference with management issues whether there was a signle card or multiple cards .... for the most common failure/exploit.

postulated was that the next most common failure (fraud, exploit, availability, etc) might be hardware failure. however, the hardware failure scenarios statistics didn't mandate a one-for-one mapping between token & function .... it would just indicate that some might want no-single-point-of-failure (two tokens, or at most three).

I would assert that if you need/require multiple certificates .... that there is effectively nearly the same management process ... regardless of whether a single key or multiple keys are involved. You have to a mapping between key to which certificate .... whether it is one-to-one or one-to-many .... and you have to have a notification process for each certificate. The issue then isn't the management of the information .... it is just how many that might have to be notified for each key compromise ... not the management problem of keeping track of all that might have to be notified. It is slightly different if the information hasn't been managed and it is necessary to reconstruct it after a compromise ... then if there is only a one-to-one mapping .... then the scope of reconstruction may not be as bad ... since the search for key-to-certificate mapping stops after the correct certificate has been identified ... and the search for notification process stops ... after the process for the specific certificate is found.

issue with regard multiple or single key compromise .... would be if the compromise modes have common components. For instance are all private keys carried in the same hardware token or same encrypted file. If the most common compromise/failure mode for keys .... are common multiple key failure ... aka attack on encrypted file containing all private keys .... then all certificates have to be revoked .... regardless of whether there is a one-to-one policy or a one-to-many policy is allowed (aka similar to the most common failure mode for cards .... the lost/stolen of wallet/purse ... where all cards are taken .... and there is no differentiation in this failure mode whether there were single card or multiple cards .... all cards fail). semantic note: common is used in the sense of most frequent ... as well as the sense of affecting all keys.

I would also strongly assert that many policies are left over from shared-secret key policies .... each infrastructure requiring a unique key because of vulnerabilities specifically associated with shared-secret key.

I would contend that many of the vulnerabilities significantly changed transitioning from shared-secret key infrastructure to public key infrastructure .... and the vulnerability thresholds needed for various organizations would still be met if the same public key were used in different infrastructures ... aka many infrastructures never bothered really redoing failure/vulnerability analysis. Possibly in the transition from shared-secret to public; some bureaucrat just says that there is a policy regarding keys .... and of course all keys are the same. Bureaucratic policies have a life of their own.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Al Arsenault on 3/13/2003 7:40 am wrote:
><snip>
> When using multiple CA-s, what prevents you from issuing multiple
> certificates to the same key?

From a technical standpoint, typically nothing prevents this. It's not commonly done because:

a. There's more of a management problem; e.g., if the key is ever compromised for whatever reason, you have to track down ALL of the certificates it was bound to and revoke them; and

b. Policies typically restrict it.

But it could easily be done (and has in some specialized cases).

Al Arsenault
Chief Security Architect
Diversinet Corp.


Encryption of data in smart cards

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 13 Mar 2003 14:08:04 -0700
To: John Kelsey <kelsey.j@xxxxxxxx>
Subject: Re: Encryption of data in smart cards
Cc: Krister Walfridsson <cato@xxxxxxxx>,
Werner Koch <wk@xxxxxxxx>, cryptography@xxxxxxxx
At 01:13 PM 3/13/2003 -0500, John Kelsey wrote:
At 11:08 PM 3/12/03 +0100, Krister Walfridsson wrote:
>...
>This is not completely true -- I have seen some high-end cards that use
>the PIN code entered by the user as the encryption key. And it is quite
>easy to do similar things on Java cards...

With any kind of reasonable PIN length, though, this isn't all that helpful, because of the small set of possible PINs. And smartcards don't generally have a lot of processing power, so making the PIN->key mapping expensive doesn't help much, either.

/Krister

--John Kelsey, kelsey.j@xxxxxxxx


note however, that PIN could be possibly in infrastructure with real secret key and encryption done with derived key. the derived key one-way function is attempting to protect the infrastructure-wide secret key from brute force key search on specific piece of data. The issue is how many bits in a PIN is required to protect the secret key in a one-way function (involving the secret key and the PIN). A simple derived key is sufficient using the secret key and public account number. Adding a (privately known, card specific) PIN to such a derived key function:

1) doesn't increase the ease of attack on the secret key

2) doesn't affect brute force attack on the derived key

3) makes it harder to use a lost/stolen card

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Certificate Policies (addenda)

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 03/13/2003 02:41 PM
To: ietf-pkix@xxxxxxxx
cc: Al Arsenault <awa1@xxxxxxxx>, Margus Freudenthal <margus@xxxxxxxx>
Subject: Re: Certificate Policies (addenda)
note something related was discussed in sci.crypt regarding certification of quality:
http://www.garlic.com/~lynn/2003d.html#71 SSL/TLS DHE suites and hsort exponents

aka CA basically certifies the validity of some assertion in the certificate. there has been little or no activity in the area of quality. One is tempted to mention the joke in risks forum this week about the person lost in a ballon
http://catless.ncl.ac.uk/Risks/22.63.html

we had been somewhat involved in the most prevalent certification in the world today ... aka SSL domain name certificates for e-commerce:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

at the time, included having to perform due diligence visits on the major certification players for SSL domain name certificates for e-commerce.

we strived to get some quality issues introduced into the certification process with no success.

a significant issue is/was that certificates are primarily a pardigm for offline, stale, static data. Risk and trust management has been moving the state-of-the-art to a timely, dynamic data paradigm .... and it is trivially shown that any environment that supports timely, dynamic data paradigm ... also supports stale, static data as a subset. It wasn't so much that there weren't any players in the risk & trust management arena .... is was that they had just about all moved into a timely, dynamic data paradigm. While it is possible to proove that a infrastructure that involves timely, dynamic data .... can support as a subset all the characteristics of stale, static data .... it is not possible to proove that an offline, stale, static paradigm subsumes timely, dynamic data .... aka in a paradigm with timely, dynamic data it is trivial to show that offline, stale, static certificates are redundant and superfluous.

By comparison the certification authorities are just looking to certify some assertions regarding stale, static data (usely by checking with some totally different organization that is actually responsible for the accuracy of the assertions).

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 15 Mar 2003 16:15:22 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: How effective is open source crypto?
Cc: cryptography@xxxxxxxx
having worked on some of the early e-commerce/certificate stuff ... recent ref:
http://www.garlic.com/~lynn/aadsm13.htm#25 Certificate Policies (addenda)

the assertion is that basic ssl domain name certificate is so that the browser can check the domain name from the url typed in against the domain name from the presented (trusted) certificate ... and have some confidence that the browser is really talking to the server that it thinks it is talking to (based on some trust in the issuing certification authority). in that context ... self-certification is somewhat superfluous ... if you trust the site to be who they claim to be ... then you shouldn't even have to bother to check. that eliminates having to have a certificate at all ... just transmit a public key

so slight step up from MITM attacks with self-signed certificates would be to register your public key at the same time you register the domain. browsers get the server's public key from dns at the same time it gets the ip-address (dns already supports binding of generalized information to domain ... more than simple ip-address). this is my long, repetitive argument about ssl domain name certification ....
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

i believe a lot of the non-commercial sites have forgone SSL certificates .... because of the cost and bother.

some number of the commercial sites that utilize SSL certificates .... only do it as part of financial transaction (and lots of them .... when it is time to "check-out" .... actually transfer to a 3rd party service site that specializes in SSL encruyption and payments). The claim by many for some time .... is that given the same exact hardware .... they can do 5-6 times as many non-SSL (non-encrypted) HTTP transactions as they can do SSL (encrypted) HTTPS transactions .... aka they claim 80 to 90 percent hit to the number of transactions that can be done switching from HTTP to HTTPS.

a short version of the SSL server domain name certificate is worry about attacks on the domain name infrastructure that can route somebody to a different server. so SSL certificate is checked against to see if the browser is likely talking to the server they think they are talking to. the problem is that if somebody applies for a SSL server domain name certificate .... the CA (certification authority) has to check with the authoritative agency for domain names .... to validate the applicants domain name ownership. The authoritative agency for domain names is the domain name infrastructure that has all the integrity concerns giving rise for the need for SSL domain name certificates. So there is a proposal for improving the integrity of the domain name infrastructure (in part backed by the CA industry ... since the CA industry is dependent on the integrity of the domain name infrastructure for the integrity of the certificate of the certificates) which includes somebody registering a public key at the same time at a domain name. So we are in catch-22 ....

1) improving the overall integrity of the domain name infrastructure mitigates a lot of the justification for having SSL domain name certificates (sort of a catch-22 for the CA industry).

2) registering a public key at the same time as domain name infrastructure ... implies that the public key can be served up from the domain name infrastructure (at the same time as the ip-address .... eliminating all need for certificates).

There is a description of doing an SSL transaction in single round trip. The browser contacts the domain name system and gets back in single transmission the 1) public key, 2) preferred server SSL parameters, 3) ip-address. The browser selects the SSL parameters, generates a random secret key, encrypts the HTTP request with the random secret key, encrypts the random secret key with the public key ... and sends off the whole thing in a single transmission .... eliminating all of the SSL protocol back&forth setup chatter. The browser had to contact the domain name system in any case to get the ip-address .... the change allows the browser to get back the rest of the information in the same transmission.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 16 Mar 2003 10:17:39 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto?
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
    Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 08:40 AM 3/16/2003 -0800, Eric Rescorla wrote: You still need a round trip in order to prevent replay attacks. The fastest that things can be while still preserving the security properties of TLS is:

ClientHello       ->
ClientKeyExchange ->
Finished          ->
<-  ServerHello
<-  Finished
Data              ->

See Boneh and Schacham's "Fast-Track SSL" paper in Proc.ISOC NDSS 2002 for a description of a scheme where the client caches the server's parameters for future use, which is essentially isomorphic to having the keys in the DNS as far as the SSL portion goes.

In any case, the optimization you describe provides almost no performance improvement for the server because the load on the server derives almost entirely from the cryptography, not from transmitting the ServerHello [0]. What it does is provide reduced latency, but this is only of interest to the client, not the server, and really only matters on very constrained links.

-Ekr

[0] With the exception of the ephemeral modes, but they're simply impossible in the scheme you describe.


Sorry, there were two pieces being discussed.

The part about SSL being a burden/load on servers ....

and the shorten SSL description taken from another discussion. The shorten SSL description was (in fact) from a discussion of the round-trips and latency ... not particularly burden on the server. In the original discussion there was mention about HTTP requires TCP setup/teardown which is minimum seven packet exchange .... and any HTTPS chatter is in addition to that. VMTP, from rfc1045 is minimum five packet exchange, and XTP is minimum three packet exchange. A cached/dns SSL is still minimum seven packet exchange done over TCP (although XTP would reduce that to three packet exchange).

So what kind of replay attack is there. Looking at purely e-commerce ... there is no client authentication. Also, since the client always chooses a new, random key .... there is no replay attack on the client ... since the client always sends something new (random key) every time. That just leaves replay attacks on the server (repeatedly sending the same encrypted data).

As follow-up to doing the original e-commerce stuff ... we then went on to look at existing vulnerabilities and solutions .... and (at least) the payment system has other methods already in place with regard to getting duplicate transaction .... aka standards body for all payments (credit, debit, stored-value, etc) in all (electronic) environments (internet, point-of-sale, self-serve, face-to-face, etc), X9.59
http://www.garlic.com/~lynn/x959.html#x959 (standard)
http://www.garlic.com/~lynn/x959.html#aadsnacha (debit/atm network pilot)

Replay for simple information retrieval isn't particularly serious except as DOS .... but serious DOS can be done whether flooding is done with encrypted packets or non-encrypted packets. Another replay attack is transaction based ... where each transaction represents something like performing real world transaction (send a shirt and debit account). If it actually involves payment ... the payment infrastructure has provisions in place to handle repeat/replay and will reject. So primarily what is left .... are simple transaction oriented infrastructures that don't have their own mechanism for detecting replay/repeats and are relying on SSL.

I would also contend that this is significantly smaller exposure than self-signed certificates.

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (addenda)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 16 Mar 2003 10:40:52 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (addenda)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
    Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
... small side-note .... part of the x9.59 work for all payments in all environments .... was that the transaction system needed to be resilient to repeats and be done in a single round-trip (as opposed to the transport).

there needed to be transaction resiliency with respect to single round trip with something like email that might not happen in strictly real-time (extremely long round-trip delays).

Real-world systems have been known to have glitches ... order/transaction generation that accidentally repeats (regardless of whether or not transport is catching replay attacks).

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (bad form)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 16 Mar 2003 11:26:59 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (bad form)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 09:30 AM 3/16/2003 -0800, Eric Rescorla wrote:
Correct.

It's considered bad form to design systems which have known replay attacks when it's just as easy to design systems which don't. If there were some overriding reason why it was impractical to mount a defense, then it might be worth living with a replay attack. However, since it would have only a very minimal effect on offered load to the network and--in most cases--only a marginal effect on latency, it's not worth doing.

-Ekr

--
[Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/


so, lets look at the alternatives for servers that are worried about server replay attacks:

client has public key & crypto-preferred info (dns or cached), generates random secret key, encrypts request, encrypts random secret key, single transmission

server gets request ... application has opened the connection with or w/o server replay attack. if the application, higher level protocol has its own repeat checking .... it has opened the connection w/o server replay attack. and the server sends the request up the stack to the application. If the application has opened the connection with server replay attack, the protocol sends back some random data (aka its own secret)... that happens to be encrypted with the random key.

The client is expecting either the actual response or the replay attack check. If the client gets the actual response, everything is done. If the clients gets back the replay attack check .... it combines it with something .... and returns to the server.

The difference is basic two packet exchange (within setup/teardown packet exchange overhead) plus an additional replay prevention two packet exchange (if the higher level protocol doesn't have its own repeat handling protocol). The decision as to whether it is two packet exchange or four packet exchange is not made by client ... nor the server ... but by the server application.

Simple example for e-commerce is sending a P.O. along with payment authorization ... the transmitted P.O. form is guaranteed to have a unique identifier. The P.O. processing system has logic for handling repeat POs ... for numerous reasons (not limited to replay attacks).

Single round-trip transaction:
ClientHello/Trans->
<- ServerResponse/Finish
Transaction w/replay challenge:
ClientHello/Trans->
<-Server replay challenge
ClientResp->
<-ServerResponse/Finish
Now, ClientHello/Trans can indicate whether the client is expecting a single round-trip or additional data.

Also, the ServerResponse can indicate whether it is a piggy-backed finish or not.

So, the vulnerability analysis is what is the object of the replay attack and what needs to be protected. I would contend that the object of the replay attack isn't directly the protocol, server, or the system .... but the specific server application. Problem of course, is that with generic webserver (making the connection) there might be a couple levels of indirection between the webserver specifying the connection parameters and the actual server application (leading to webservers always specifying replay challenge option).

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (aads addenda)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 16 Mar 2003 13:48:02 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (aads addenda)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
    Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
we did something similar for AADS PPP Radius
http://www.garlic.com/~lynn/x959.html#aads

radius digital signature protocol has replay challenge.

so adding radius option to webserver client authentication stub (infrastructure can share common administration client authentication across all of its environments). then client clicks on https client authentication, generates secret random key, encrypts request for client authentication with random key, encrypts random key with server public key, sends off single transmission. Server responds with radius connect request .... which includes replay challenge value as part of message (encrypted with random key). Client responds with digital signature on the server radius message (and some of its own data, encrypted with random key).

Basically use the same packet sequence as in transaction w/o replay challenge ... since higher level protocol contains replay challenge. Then can use same packet sequence for webserver TLS and encrypted PPP (and works as VPN; possibly can define also as encrypted TCP) .... along with the same client authentication infrastructure

Infrastructure can use the same administration (RADIUS) infrastructure for all client authentication .... say enterprise with both extranet connections as well as webserver .... or ISP that also supplies webhosting. The same administrative operation can be used to support client authentication at the PPP level as well as at the webserver level.

The same packet exchange sequence is used for both PPP level encryption with client authentication as well as TLS for webserver level encryption with client authentication.

The higher level application can decide whether it already has sufficient replay/repeat resistance or request replay/repeat resistance from lower level protocol.

So regardless of TLS, PPP, or TCP, client authentication (using same packet sequence as transaction, w/o lower level replay challenge):

1) client picks up server public key and encryption options (from cache or DNS)

2) client sends off radius client authentication request, encrypted with random secret key, encrypted with server public key ...

3) server lower level protocol handles the decryption of the random secret key and the decryption of the client request (which happens to be radius client authentication .... but could be any other kind of transaction request) and passes up the decrypted client request

4) server higher level protocol (radius client authentication) responds with radius replay challenge

5) client gets the replay challenge, adds some stuff, digitally signs it and responds

6) server higher level radius client authentication protocol appropriately processes


Same server public key initial connect code works at TLS, PPP, and possibly TCP protocol levels. The same server public key initial connect code supports both lower-level replay challenge and no replay challenge.

Same radius client authentication works at TLS, PPP, and possibly TCP protocol levels. Same client administrative processes works across the whole environment.

aka .... the radius client authentication protocol is just another example (like the purchasse order example) of the higher level protocol having its own replay/repeat handling infrastructure (whether it is something like log checking or its own replay challenge).

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (bad form)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 16 Mar 2003 15:21:56 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (bad form)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
        Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
Eric Rescorla wrote:
You've already missed the point. SSL/TLS is a generic security protocol. As such, the idea is to push all the security into the protocol layer where possible. Since, as I noted, the performance improvement achieved by not doing so is minimal, it's better to just have replay protection here.

-Ekr

--
[Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/


well i was looking it as a protocol specification analysis .... not just as an SSL/TLS solution. the other common reaction has been it isn't necessary to consider the optimal transaction case (which may be significant percentage of the cases) because the underlying TCP is already doing a minimum 7-packet exchange. And then the response is well we don't need no stinking, optimized, reliable transport ... because the upper layers have such horrible packet chatter.

so traditionally from a protocol specification analysis standpoint .... it is bad to jumble/mix-up objectives. objectives should be clearly delineated. nominally SSL is 1) server authentication, 2) encrypted channel, 3) replay attack .... all mushed together.

so I would claim that I was clearly delineating and calling out the separate characteristics .... as well as doing a protocol analysis that could be common generic security solution (code & packet exchange) ... whether at the TLS level, the TCP level, or the PPP level.
http://www.garlic.com/~lynn/aadsm13.htm#30 How effective is open source crypto? (aads addenda)

We ran into some of this on the original SSL e-commerce activity (on the backend for the original payment gateway).... needing to deploy symmetrical authentication .... even tho the specification and code didn't exist:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (bad form)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 16 Mar 2003 16:06:44 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (bad form)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
    Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 02:40 PM 3/16/2003 -0800, Eric Rescorla wrote:
analysis of SSL performance makes pretty clear that that's not the relevant issue 99% of the time. And since you propose to impose a significant dependency on DNS in order to fix that non-problem, that analysis is particularly relevant.

Premature optimization is a bad thing.


nope .... actually i was pointing out that the server authentication part of SSL .... which is somewhat where the original comment about self-signed certificates came in (in the original post starting this thread) .... was in response to integrity concerns with the domain name infrastructure.

however, the authoritative agency for domain name ownership is the domain name infrastructure. Typically when somembody submits a request to a certification authority for a SSL domain name certificate, the certification authority validates the request by contacting the domain name infrastructure to validate that the person requesting the SSL domain name certificate owns the domain name (aka that is how certification is done .... a certification authority validates some assertion that goes into a certificate with the authoritative agency responsible for the validity of the information).

so the CA industry has also somewhat noted that there may be integrity issues with the domain name infrastructure .... and one of the suggestions is to have a public key registered as part of registering the domain name .... in order to improve the integrity of the domain name infrastructure .... so that the CA industry can rely on the integrity of the domain name infrastructure when certifying and issuing SSL domain name certificates.

So a simple observation is that

1) if the CA industry wants public keys registered as part of domain name registration as part of improving the integrity of the domain name infrastructure for use by the CA industry

2) improvements in the integrity of the domain name infrastructure for the CA industry .... actually improves the integrity of the domain name infrastructure for everybody.

3) if the integrity of the domain name infrastructure is improved for everybody .... the concerns about the integrity of the domain name industry giving rise to the requirement for SSL domain name certificates are reduced.

4) if the concerns needing SSL domain name certificates are reduced significantly then it is hard to financially justify a trusted SSL domain name certificate infrastructure

5) if the financial justification for a trusted SSL domain name certificate infrastructure is eliminated ... then how do you address the other facet of SSL which uses the certficate public key as part of random secret key exchange

6) so there now needs to be some trusted public key distribution that doesn't rely on trusted SSL domain name certificate infrastructure

7) well if there is now public key registration as part of domain name registration, and the integrity issues of the domain name infrastructure with regard to trusted information are supposedly addressed; then would it be possible to use a trusted domain name infrastructure information distribution for public key distribution also

8) if you were using DNS for trusted information distribution (ip-address, public key, server characteristics) what other opportunities are there for enhancing the establishment of encrypted information exchange.


This didn't start from the standpoint of optimizing SSL.

This started from the standpoint that some facets of the CA industry has been advocating addressing some of the issues that give rise to needing SSL domain name certificates. There is this chicken&egg or catch22 for the CA industry with respect to SSL domain name certificates.

1) There has to be enough integrity concerns regarding the domain name infrastructure to establish the financial justification for doing the whole SSL domain name certificate certification process.

2) However, the CA industry is dependent on the integrity of the domain name infrastructure in order to perform the certification process for trusted SSL domain name certificate

3) If the CA industry sowed the seeds for eliminating the financial basis for trusted SSL domain name certificates (eliminating people worrying about which server am i really talking to; aka the server authentication) .... how is trusted public key distribution accomplished so that the encrypted channel part of SSL is still accomplished.

4) if the domain name infrastructure was now trusted for information distribution and the domain name infrastructure had public keys registered (as per the CA industry suggestion).... then could the domain name infrastructure be used for trusted public key distribution.

5) if the domain name infrastructure was used for trusted public key (and other information) distribution what other changes could be made in the protocol.


--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (bad form)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 16 Mar 2003 16:52:08 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (bad form)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 03:21 PM 3/16/2003 -0800, Eric Rescorla wrote:
Yes, you've described this change before. And as I've said before, it's a very marginal improvement in protocol performance with the massive downside that it introduces a dependency on the (nonexistent) secure DNS infrastructure.

-Ekr

--
[Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/


however ... note that the whole current CA SSL domain name certificates .... is based people worried about the integrity of the domain name infrastructure. The whole SSL domain name certificate house of cards is based on the very same domain name infrastructure .... that supposedly justifies having SSL domain name certificates .... it is just those facts are obfuscated by a whole lot of protocol chatter and crypto mumbo, jumbo.

1) the original post in this thread was about self-signed certificates

2) with regard to server authentication, if you can't rely on the sever to correctly tell the client who the server is, then the client surely can't rely on the server's self-signed certificate to tell the client who the server is.

3) a big part of the financial justification for paying money for trusted SSL domain name certificates is some confidence that the client is talking to the correct server.

4) a CA, in order to prove that the entity requesting an SSL domain name certificate actually owns the domain name in question has to contact the authoritative agency for domain names, the domain name infrastructure.

5) if the domain name infrastructure has significant integrity issues why would a CA bother to verify that the entity requesting a specific domain name actually owns that domain name.

6) the CA industry can either

a) stop bothering to contact the domain name infrastructure .... just immediately issue the SSL domain name certificate

b) try and improve the integrity of the domain name infrastructure (aka like suggestion for adding public keys)


so i somewhat interpret your comments as we should only consider changing what is currently being done .... so long as it doesn't impact the current protocol chatter. any discussion about self-signed certificates is perfectly valid .... because the SSL protocol chatter wouldn't have to change .... ignore the fact that it now raises some question as to the validity of the SSL server authentication function.

I just claim that the existing SSL domain name certificates actually have similar issues with regard to the validity of the SSL server authentication function ... because the CA certification function for producing SSL domain name certificates is dependent on asking the domain name infrastructure. There may be exactly the same integrity issues with regard to data in a self-signed certificate and a CA-issued certificate .... it is just that the CA-issued certificate has a whole lot of business processes between the certificate creation and the actual point of the integrity problems (tending to obfuscate the issues).

The ancillary claim is that some in the CA industry actually understand this .... therefor the proposal that public keys be registered with the domain name infrastructure at the same time that a domain name is registered.

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (bad form)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 17 Mar 2003 07:41:01 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (bad form)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 10:30 PM 3/16/2003 -0800, Eric Rescorla wrote:
The problem is that you're acting as if the "domain name infrastructure" is a unitary thing. It's not. The problem is that the DNS is untrustworthy, not that the information on which it's based is untrustworthy. However, Verisign, at least, has access to the original data and doesn't have to worry about DNS tampering, so they are perfectly capable of issuing certificates based on valid data.

-Ekr

--
[Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/


the exploit/vulnerability of the DNS database, that is of concern to the CA-industry, is a exploit/vulnerability of the DNS database. Once the database entry has been compromised .... it makes little difference whether there is direct access to the database entry .... or there some other kind of transaction against the database. I assert that once the exploit has happened, the results seen by Verisign and any other CA vendor .... referencing the same domain entry .... will be the same .... independent of whether Verisign has access to the original data or not.

the countermeasure (that i've repeatedly mentioned ... that is somewhat motivated by the CA-industry .... regardless of whether there is direct access to the original data or not) of registration of a public key in the database entry, at the same time the domain name database entry is created, is to address the exploit/vulnerability against the database entry.

the point is that certificates are basically issued against the dns database entry ... it turns out in database useage .... once the database entry has been compromised .... and you have an infrastructure that builds something based on the database entry .... then it matters little how the database entry is accessed.

So DNS database entries are built by somebody, someplace contacting some company that performs registration of domain names. There are lots of those companies and they tend to be responsible for the database entry contents for the domain names that they register. Again this particular exploit/vulnerability isn't against the accessing of the database entry .... it is against the updating of the database entry .... and then later uses that are dependent on values in the database entry.

From the nature of the countermeasure involving registration of a public key in the database entry, somebody familiar with public key infrastructures might conjecture that the purpose of the public key registration is to authenticate subsequent updates to the database entry.

slightly related
http://www.garlic.com/~lynn/aadsm13.htm#8 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#9 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#21 A challenge
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (bad form)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 17 Mar 2003 08:59:44 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (bad form)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 10:30 PM 3/16/2003 -0800, Eric Rescorla wrote:
The problem is that you're acting as if the "domain name infrastructure" is a unitary thing. It's not. The problem is that the DNS is untrustworthy, not that the information on which it's based is untrustworthy. However, Verisign, at least, has access to the original data and doesn't have to worry about DNS tampering, so they are perfectly capable of issuing certificates based on valid data.

-Ekr

--
[Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/


actually ... as i mentioned previously ... most of this is pretty much beside the point. even tho when we were doing the original e-commerce thing .... we had to go perform these due diligence visits with the major CAs .... with some depth review of the step-by-step process ... that isn't the major thrust of the original reply. We also knew a little about database operation ... as did the people that had come from a database vendor and were at this small client/server start-up building the commerce server.

in any case, from the original:
How effective is the SSL cert regime?

Last page showed 9,032,963 servers. This
page shows 112,153 servers using certs.


....
One of the points was the possibility of self-signed certs. As an aside, in the original post I raised the issue that more pervasive use of SSL .... could be based on a number of different things .... included things possibly not directly related to SSL-certs .... like the performance impact that performing basic SSL operation has on a server.

So I made the claim that SSL provides
1) server authentication (& countermeasure for MITM exploits)
2) encrypted channel
3) replay challenge


I also asserted that a major motivation for financial transactions related to SSL domain name certificates were related to server authentication. That if there was any significant change with regard to justification for SSL domain name certificates ... that it could have a significant downside effect on the SSL-cert regime.

So a purpose of the SSL-cert is basically to provide trusted public key distribution (bound to a domain name) which is used in both #1 and #2. Now, one of the original suggestions was the possibility of using self-signed certificates. Now if there is some issue of trusting that you are really talking to the server you think you are talking to (requiring server authentication), then self-signed certificates don't really help a lot.

An assertion is also that any improvements in various internet infrastructures (including domain name infrastructure) ... could lower the concern regarding am I talking to a counterfeit/wrong server, which results in lowering the number of business operations that feel that they might need an SSL-cert for standard business operation or feel that the value of an SSL-cert is less than the going price for such things. For instance, the primary reason that SSL-cert regime is as pervasive as it is .... is associated with credit card transactions (aka this thing we worked on commonly referred to as e-commerce) Now SSL protects credit card numbers while in flight. However, we never actually saw a reported exploit against credit card numbers in flight. All the reported instances of major credit card exploits have to do with harvesting of credit card merchant files ... at rest at the merchant. So for the major exploit, SSL has no effect on.
http://www.garlic.com/~lynn/subintegrity.html#fraud

So there are integrity issues in the existing domain name infrastructure. However, as previously pointed out, there are integrity issues in the existing SSL-cert because the process is also dependent on domain name infrastructure. A major road block for using the domain name infrastructure as trusted distribution of public key bound to the domain name .... is the availability of the public key in the domain name infrastructure database. However, that barrier is addressed by a CA-industry proposal to have public keys registered in domain name entries.

So there are additional concerns about various other kinds of vulnerabilities and exploits of the domain name infrastructure, specifically in the process of propagation and distribution of the information (like DNS cache poisoning). So, as per previous thread focusing specifically on the transition to domain name infrastructure with higher integrity operations ... the public key that gets distributed by DNS can initially reside in encapsulated form in the database entry ... effectively as a mini-cert .... public key, domain name, digital signature. In the interim, to more trusted domain name infrastructure .... rather than distributing bare public keys .... distribute encapsulated public keys.

some past discussion of baby steps for the domain name infrastructure that rather than distribution of bare public keys as part of the dns protocol, the public keys are encapsulated in a mini-cert and digitally signed.
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions

also, mentioned in the above ... the existing SSL-cert environment isn't even a real PKI ... because it doesn't do anything about the management and administration of the certificates .... like revocation. when we originally were performing the due diligence on the CAs as part of the original e-commerce effort, we coined the term certificate manufacturing to distinguish SSL-cert environment from a real PKI. The domain name infrastructure does provide for timely management of its distributed information, something that the existing SSL-cert environment doesn't address.

as a side issue, X9.59 was specifically designed to address exploits of payment account numbers .... whether at rest (as in database entry) or in flight (as in flowing over the internet) for all kinds of electronic payments (credit, debit, e-check, stored-value) and all kinds of environment (face-to-face, non-face-to-face, point-of-sale, internet, unattended terminals, non-internet, etc).
http://www.garlic.com/~lynn/x959.html#x959

there is the possibility, with something like x9.59 that addresses all the exploits of payment account numbers, there would be an erosion in the demand for the existing SSL-certs, possibly putting at risk the financial stability of the existing independent SSL-cert operations. I assert that integrating trusted public key distribution into an existing information distribution infrastructure places it on a better financial basis.

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto? (bad form)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 17 Mar 2003 09:48:31 -0700
To: EKR <ekr@xxxxxxxx>
Subject: Re: How effective is open source crypto? (bad form)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
        Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 07:42 AM 3/17/2003 -0800, Eric Rescorla wrote:
But it's not he one that's of concern on the normal Internet. On the normal Internet, there are a wide array of easy to mount DNS spoofing attacks that don't involve compromising the true server, just forging traffic.

-Ekr


also as per
http://www.garlic.com/~lynn/2003.html#49 InfiniBand Group Sharply, Evenly Divided

and related things:
http://www.garlic.com/~lynn/subintegrity.html#assurance
http://www.garlic.com/~lynn/subintegrity.html#fraud

that the whole internet is at risk because of various domain name infrastructure integrity issues ... and there is need to improve the integrity of the domain name infrastructure .... regardless of the CA-industry issues and/or using it for trusted distribution of things other than ip-address bound to domain name.

as before, baby steps
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions

suggests that in the interim, encapsulated public key distribution can be used instead of plain, bare public key distribution. With sufficient improvement in the integrity of the domain name infrastructure with respect to trusted information distribution it might be possible to transition from mini-cert distribution to bare public key distribution.

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

How effective is open source crypto?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 17 Mar 2003 17:06:49 -0700
To: Bill Stewart <bill.stewart@xxxxxxxx>
Subject: Re: How effective is open source crypto?
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
   Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
Amutlt 09:58 AM 3/17/2003 -0800, Bill Stewart wrote:
The second half isn't true, because it assumes a 1:1 mapping between domain names and IP addresses, and it's really N:N, with N:1 and 1:N both common. Larger domains typically have multiple servers (and therefore multiple addresses), though you may be able to represent this in the reverse name space. Smaller domains are usually served by virtual hosts on big shared servers, so multiple domains have the same IP address, or even multiple pooled addresses. That not only means there's a security concern about domains on the same host, but it also makes the reverse namespace not very useful. You could have the reverse namespace belong to the hosting server, and have them issue certs to their customers, but it's still certs. Also, small domains often want to change servers, but don't want their certification hosed if the reverse lookups don't get changed at the same time as the forward.


... the second half only assumes that there are bindings to a domain name .... which is the same thing that happens in a SSL domain name certificate .... a binding between a domain name and a public key.

now dns allows the binding of one or more ip-addresses to the same domain name. SSL domain name certs sort of have the reverse .... they allow "wildcards" in domain name certs (aka browsers will check a SSL domain name cert with a domain name containing a wildcard specifier as being a fuzzy match against the URL that the browser used). In these scenarios .... multiple different servers have access to the same private key.

effectively what dns would be doing is transporting the information analog of a real-time cert (representing a real-time binding between the resolved host name and a public key) .... i.e. the binding of some domain name to a public key. in the stale, static cert business .... they need the wildcard because at the time in the distant past when the cert was created the, infrastructure might not be totally sure about all possible names that might be used. So the browser asks DNS to tell me what you know about a specific host/domain name. DNS sends back one or more ip-addresses (a-records), but if play with dig or nslookup .... there can be other information bound with the domain name. So multiple different domain names may have similar/identical fields in the record .... like the person to contact. There is nothing preventing different domain name entries from having same public key values (as appropriate).

So the browser check is given the domain name (in the URL) and some public key bound to that domain name .... if the browser contacts any of the ip-addresses provided using the public key encryption .... and the server successfully responds, then obviously it must be the correct server since otherwise it wouldn't have the correct private key. You just have to make sure that whenever anybody asks about a domain name to contact ... that the public key that will be used by that specific server matches what is in the database entry.

Because the existing operation only has a single public key per domain name certificate (even if there are wildcards in the domain name and large number of servers with the same public key) or a single server has a large number of different certificates .... possibly with the same public key ... it does simplify the mapping to DNS. The SSL-cert mapping to DNS doesn't need multiple public keys per domain name .... because the SSL-cert doesn't use multiple public key mapping to domain name.

It would get trickier if SSL-cert mapping have multiple identical certificates that differed only in the public key field .... and there were multiple different servers for the same domain name ... each with their own unique certificate and unique key-pair (and each server reliably presents the correct SSL-cert that corresponds to the public key that it "owns"). It also gets tricky for any sort of SSL-cert caching .... since there are things that attempt to do server load balancing via A-record rotation ... but there is also router-based load-balancing that effectively does NAT ... with dynamic steering of new connection to server with fewest connections (which means that you can't guarantee you are talking to the same server given the same identical ip-address). In any case, all of the multi-machine server cases that I know of, use a common key-pair across the server farm (and the same public key may or may not appear in different certificates .... with virtual domain hosting). I would be interested to know if there are server farms with multiple different SSL-certs with identical domain name and different public keys (with each server having its own unique key-pair) ... as multiple servers all using the same key-pair.

Now back to the SSL-cert scenario .... the browser must first contact the server, get back the server's cert, check to see if the server's cert contains anything that (closely) matches the domain name in the original URL, and then eventually attempt to communicate with the server using the public key from the SSL-cert (which is then somewhat similar to the above abbreviated scenario). Now if this was real PKI ... instead of just simple certificate manufacturing .... the browser would also have to check any trust chain for CRLs related to the server's certificate. All that gorpy stuff goes away .... if you are using a real time distribution mechanism from a trusted source .... rather than a stale, static distribution mechanism from an unknown source (aka the webserver).

now when we were doing this thing with the small client/server startup for their commerce server and what would become to be called e-commerce .... we did have this small problem with getting them to support multiple a-record stuff. Since we effectively had sign-off on the server to payment gateway .... so we could mandate multiple a-record support (along with mutual SLL authentication, and some number of other integrity things) ... however, even given classes on multiple a-record support along with example code .... it was probably another year before the client code supported it.

work with small client/server startup on this thing called SSL and e-commerce:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

some discussion about the multiple a-record trials and tribulations:
http://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/aepay4.htm#comcert17 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#miscdns misc. other DNS
http://www.garlic.com/~lynn/2002.html#23 Buffer overflow
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002.html#34 Buffer overflow
http://www.garlic.com/~lynn/2003.html#30 Round robin IS NOT load balancing (?)
http://www.garlic.com/~lynn/2003c.html#8 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#12 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#25 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

The case against directories

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/21/2003 08:02 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, epay@xxxxxxxx
Subject: Re: The case against directories
>2. Internal information (including employment) is generally not public

in fact, for earlier public PKI certificate-based information, the eventual result (because of difficult privacy issues, both individual and institutional, taking some liberty to translate privacy as both a personal concept as well as an institutional concept) was the lowest common denominator, a certificate that only contained a institutional number (ex: various financial certificates) and nothing else, which then were only used in context of relying-party-only certificates.

the cross domain issues have not been technical (they effectively have all been a form of privacy, either individual or institutional) .... they were not technical some 15 years ago with cross-domain kerberos, there were not technical some 6-8 years ago with cross-domain PKI certificates, and they probably won't be technical this time around with directories. another simple example of the reduction of information has been the dig/nslookup responses from the biggest internet "public" directories, the DNS root-servers. Over the last five years, nearly all "privacy" information has disappeared from public responses (like name, address, telephone number, and email of administrative and technical contacts).

DNS directories are an example of an online internet information source for a couple decades and the issue isn't that the paradigm doesn't work, but there are significant privacy issues (personal & institutional).

And as one of my common/frequent references .... certificates are just stale, static copy/representation of a database/directory entry that exists somewhere ... and the personal & instititional privacy issues are common, regardless of the representational format.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

on 3/21/2003 1:21 am wrote:
I would like to add a few things to what Phillip Hallam-Baker of VeriSign wrote about directories as an obstacle to PKI deployment.

Many PKI experts are involved in huge public-sector-driven projects, that are based on establishing directory interoperability between organizations. At first sight this looks like a great idea but digging a bit further, you soon note that this is not a universal solution but rather a dead end.

Directory problem issues
1. Technical. Unifying schemas + firewall issues
2. Internal information (including employment) is generally not public
3. The level of openness depends on who is asking
4. Directories represent just one way to organize data

But, there is no reason to despair, as there are work-arounds that properly addresses all these issues:

Using authentication systems like OASIS' SAML, organizations can (through their employees), authenticate to each others' intranets and through this get access to exactly the information they should have and in a format that make sense. The latter may be a directory tree, a PDF-file, a database listing, an HTML form, etc.

Unlike directory systems, SAML allows secure access to any kind of active or passive information source, including purchasing and work-flow systems.

All using the truly universal Internet browser interface.

For machine-to-machine (=automated) access to external information, specialized Web Services seems to be a much more extensible route than directories, as the former introduces no restrictions on data.

Anders Rundgren
Independent consultant PKI and secure e-business


AADS Postings and Posting Index, next, previous - home