Subject: RE: Software for PKI

From: Peter Williams <[email-masked]>
Date: Thu, 01 Nov 2001 20:41:22 -0800

Peter, as the Heineken beer advert used to say:-

"Probably the finest" set of simple-to-use PKI (PKIX-I -complying
cert-based) programs for making/verifying digital 
signatures probably comes from two of the most used 
and "usable" consumer programs in the world, 
fortunately: Microsoft Office 2000, and PKZip - from 
a maker of the infamous zip format for compressing sets of
files into an archive file.

Microsoft Office 2000 (office tools, see VB signatures) allows 
ANYONE to create his/her own signing cert, usable by any
MS CAPI application. No other CA (other than you, yourself,
acting as a self-appointed authority) is required, unless you
want/need to use a TTP-grade CA or CTL provider to help 
distribute the key of your new signing authority. It all
makes testing PKI(X) really easy.

PKWare's  PKZIP (an MS CAPI Application) then allows you to 
drag and drop any file onto a disk folder (which is really a 
zip archive file), and,  behold, the key generated above (or any
other user-nominated key on a hardware device), signs this 
element of the zip file, verifiable using the PKIX cert by nothing
more than by consulting a property page available by 
right-clicking on the file. The property pages can futher
exploit the MS platform to manage trust lists, AND can 
actually walk the chain and consult revocation sources using 
ldap CRLs, and IETF's (PKIX)OCSP, etc.

It could be useful to list the CA service vendors who 
integrate their various PKIX services with these sorts 
of user-friendly tools, designed for ordinary users of 
computers. Finally, we seem to be making progress in getting
signatures and certificates sufficiently accesible for
the average citizen to start actually using! After
the disaster of S/MIME adoption, such good news is 
welcome.

I suspect zip may become the killer PKI application. It
works, its hidden, and it does something useful in
a natural way! And, today, its a solid user of (the useful
bits of the) PKIX infrastructure!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 26, 2001 6:06 PM
To: [email-masked]; [email-masked]
Subject: Re: Software for PKI

"Kronenberg, Peter" <[email-masked]> writes:
>I am student and make a work about PKI. I have to test the interoperability
of
>an IP-router with IPSEC-Implementation for the use with a PKI. I am looking
>for different PKI-softwares (PKIX) for Linux and Windows. I will use the
>software only for testing purpose. Do you know any good Software to test
the
>interoperability with PKIX (with a certification-authority, LDAP, CRL and
so
>on) ?

There are several open-source apps you can use, eg OpenCA (www.openca.org,
although the last time I looked it still seemed a bit of a work in progress)
or
cryptlib (www.cs.auckland.ac.nz/~pgut001/cryptlib).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 3 Nov 2001 19:25:41 +1300 (NZDT)

Peter Williams <[email-masked]> writes:

>"Probably the finest" set of simple-to-use PKI (PKIX-I -complying cert-based)
>programs for making/verifying digital signatures probably comes from two of
>the most used and "usable" consumer programs in the world, fortunately:
>Microsoft Office 2000, and PKZip - from a maker of the infamous zip format for
>compressing sets of files into an archive file.

The problem is that what you're getting with Windows isn't PKIX, it's MSIX.
The list of bugs in MS's certificate handling alone (in the X.509 style guide)
is about the same size as that for all other vendors combined, and that doesn't
go into all the bugs and quirks of CAPI which affect public and private key
use, signing, and other things (but which don't really have much place in the
style guide so they're not listed there).

It may be easy to use, and you may get wonderful warm fuzzies from it, but I
wouldn't put any trust in the result.  It's the usual choice for users, do you
want something you can place some trust in, or do you want something which
looks pretty?  (Unfortunately in most cases it's the latter, but I can't do
much about that except try and educate the masses).

>It all makes testing PKI(X) really easy.

But what you're testing isn't anything like PKIX, it's MSIX.  If you want to
test interoperability with other instances of the Windows PKI then it's fine,
but to test PKIX capabilities you'll need to use something which actually
follows the PKIX RFCs and drafts.

>Finally, we seem to be making progress in getting signatures and certificates
>sufficiently accesible for the average citizen to start actually using!

Is this of any value if they're mostly worthless?

Peter.

-----BEGIN CERTIFICATE-----
MIIQojCCCIoCAQAwDQYJKoZIhvcNAQEEBQAwGDEWMBQGA1UEAxMNS29tcGxleCBM
YWJzLjAeFw01MTAxMDEwMDAwMDBaFw01MDEyMzEyMzU5NTlaMBgxFjAUBgNVBAMT
DUtvbXBsZXggTGFicy4wggggMA0GCSqGSIb3DQEBAQUAA4IIDQAwgggIAoIIAQCA
A+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+//////////////////////////////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///++++HELLO+THERE++++////////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///And/welcome/to/the/base64/coded/x509/pem/certificate/of////+
+//////////////////////////////////////////////////////////////+
+///KOMPLEX/MEDIA/LABS/////////////////////////////////////////+
+///www/dot/komplex/dot/org////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///created/by/Markku+Juhani/Saarinen//////////////////////////+
+///22/June/2000///dw3z/at/komplex/dot/org/////////////////////+
+//////////////////////////////////////////////////////////////+
+///You/are/currently/reading/the/public/RSA/modulus///////////+
+///of/our/root/certification/authority/certificate////////////+
+//////////////////////////////////////////////////////////////+
+///Which/happens/to/be/16386/bits/long////////////////////////+
+//////////////////////////////////////////////////////////////+
+///And/fully/working/and/shit/////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///And/totally/insecure///////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///You/can/save/this/text/to/a/file/called/foo/dot/crt////////+
+///Then/click/on/it/with/your/explorer/and/you/can/see////////+
+///that/your/system/doesn+t/quite/trust/the/komplex/root//////+
+///CA/yet+////////////////////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///But/that+s/all/right///////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///Just/install/it////////////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///And/you+re/happily/part/of/our/16386/bit/public/key////////+
+///infrastructure/////////////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///One/more/thing/////////////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
+///Don+t/try/read/this/with/other/PKI/or/S/MIME/software//////+
+///Cause/this/cert/is/not/really/x509/compatible//////////////+
+//////////////////////////////////////////////////////////////+
+///+/mj///////////////////////////////////////////////////////+
+//////////////////////////////////////////////////////////////+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
////////////////////////////////////////AAIBATANBgkqhkiG9w0BAQQF
AAOCCAEAAAH/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////ADAgMAwGCCqGSIb3DQIFBQAEEKGhHCKQYa9YjOZdQEi/TSE=
-----END CERTIFICATE-----

---

From: "Harrington, Chris" <[email-masked]>
Date: Wed, 7 Nov 2001 11:57:50 -0500

>Your note said "let's not discuss security problems, let's just
>implement." 

Rich,

What I meant was lets not obsess over MS CAPI security problems, lets
implement some PKIX compliant and user friendly solutions irregardless of MS
problems. 

I apologize if my comments were misleading.

Chris

-----Original Message-----
From: Rich Salz [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 10:28 AM
To: Harrington, Chris
Cc: [email-masked]
Subject: Re: Software for PKI

Your note said "let's not discuss security problems, let's just
implement."  Unless you meant something else be referring to Peter G's
list of issues as "shouting at the rain."
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

---

From: "Florian Oelmaier" <[email-masked]>
Date: Wed, 7 Nov 2001 18:12:02 +0100

> Regardless of any concerns about MS CAPI,
> it's what most of those desktops are running and the more simple
> trusted applications there are that make using PKI seemless for the
> masses, makes it
> that much easier to build on a solid base of "warm/fuzzy" users.

BTW all programmers should be aware, that a shared crypto-library (thats
basically what MS-CAPI is) has conceptional problems, too. Every Virus may
alter the functionality, for example replying "good" to every signature
check call in the whole library.

Do not rely on preinstalled software. Check if you are using a correct
library, version and functions. As you know - there ARE bad boys out there
:-)

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 7 Nov 2001 09:17:46 -0800 (PST)

"Harrington, Chris" <[email-masked]> writes:
>Instead of shouting at the rain about how insecure MS CAPI may or may not be,

It wasn't so much a comment on security (or lack thereof), it was a reply to
the original poster's question about needing something to test PKIX standards
with.  My response to Peter Williams' comment was that for testing PKIX
standards compliance, the PKI stuff which comes with Windows isn't terribly
useful.

>we should concentrate on developing some PKIX / RFC compliant apps that give
>the users that "warm and fuzzy" feeling.
>
>Thoughts??

Now that's something I'd really like to see.  So far the *sole* PKI usability
study which has been done ("Why Johnny can't encrypt") indicates that the
majority of technical computer users (let alone Joe Sixpack) don't understand
PKI, and can't do much with it if you hand it to them (and PGP is probably
about as usable as the Windows PKI stuff, at least from what I've seen of
either).  How can we make it usable?  More importantly, *can* we make it
usable?  Will Joe Sixpack ever be able to sit down and do something meaningful
with certificates?  Or will Passport (warm fuzzies technology if ever I saw it)
conquer the world while we're still trying to figure out how to get an LDAP
schema everyone can agree on?

(At the moment I'm kinda putting my money on the last option, sigh.  If there's
 any HCI people out there who'd like to work on a paper on making PKI usable
 for end users, please get in touch).

Peter.

---

From: "Galipeau, Jenny" <[email-masked]>
Date: Wed, 7 Nov 2001 13:09:23 -0500

I agree.  Why do you think SSL implementations and IPsec/VPN implementation
are widely in use.  TRANSPARENT to the end-user!

-----Original Message-----
From: Harrington, Chris [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 10:14 AM
To: 'Rich Salz'; Harrington, Chris
Cc: [email-masked]
Subject: RE: Software for PKI

>Most of us in this field would rather not knowingly become charlatans
>and frauds. 

I am not suggesting anything of the kind. What I am suggesting is a more
focused approach on developing PKI software that is user friendly. Making it
user friendly is an important step in making PKI software acceptable to a
wider audience. I was talking about building something that IS secure and
making it user friendly, not building user friendly software that APPEARS to
be secure. Is that such a foreign concept???  I don't know how "charlatans
and frauds" entered the picture. Make it secure and usable...what's
fraudulent about that??

Chris

-----Original Message-----
From: Rich Salz [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 6:37 PM
To: Harrington, Chris
Cc: [email-masked]
Subject: Re: Software for PKI

> we should concentrate on developing some PKIX / RFC
> compliant apps that give the users that "warm and fuzzy" feeling.

Most of us in this field would rather not knowingly become charlatans
and frauds.  Building something that looks like a secure and
interoperable system when you know it's not, just to give users the
appearance of same... yuk.
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 8 Nov 2001 10:05:08 +1300 (NZDT)

Michael StrM-vder <[email-masked]> writes:

>I saw much Windows software with bad usability. In the PKI field almost all
>client software I saw up to now simply sucks. No matter if Windows, MS CAPI or
>whatever OS is used.

I would assume that MS have at least looked at this, based on the amount of UI
testing they do.  OTOH maybe they only test the core Windows OS and Office UI
and assume that everything else will be used by technies, certainly the little
I've seen of the Win2K PKI stuff didn't seem very straightforward.

Peter.

---

From: "Galipeau, Jenny" <[email-masked]>
Date: Wed, 7 Nov 2001 16:41:59 -0500

Exactly, they shouldn't have to know PKI ... 

-----Original Message-----
From: Harrington, Chris [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 2:21 PM
To: 'Peter Gutmann'; [email-masked]
Subject: RE: Software for PKI

>indicates that the majority of technical computer users (let alone Joe
Sixpack) don't understand PKI and can't do much with >it if you hand it to
them 

I am in agreement with that. However, I don't feel that users should HAVE to
understand PKI in order to use it. Can you imagine how much web surfing
would be going on if Joe Sixpack had to understand TCP/IP and HTML. Jennifer
brings up a good point about SSL being widely used because it is transparent
to Joe Sixpack. 

Chris

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 12:18 PM
To: [email-masked]
Subject: RE: Software for PKI

It wasn't so much a comment on security (or lack thereof), it was a reply to
the original poster's question about needing something to test PKIX
standards
with.  My response to Peter Williams' comment was that for testing PKIX
standards compliance, the PKI stuff which comes with Windows isn't terribly
useful.

>the users that "warm and fuzzy" feeling.

Now that's something I'd really like to see.  So far the *sole* PKI
usability
study which has been done ("Why Johnny can't encrypt") indicates that the
majority of technical computer users (let alone Joe Sixpack) don't
understand
PKI, and can't do much with it if you hand it to them (and PGP is probably
about as usable as the Windows PKI stuff, at least from what I've seen of
either).  How can we make it usable?  More importantly, *can* we make it
usable?  Will Joe Sixpack ever be able to sit down and do something
meaningful
with certificates?  Or will Passport (warm fuzzies technology if ever I saw
it)
conquer the world while we're still trying to figure out how to get an LDAP
schema everyone can agree on?

(At the moment I'm kinda putting my money on the last option, sigh.  If
there's
 any HCI people out there who'd like to work on a paper on making PKI usable
 for end users, please get in touch).

Peter.

---

From: "Galipeau, Jenny" <[email-masked]>
Date: Wed, 7 Nov 2001 13:50:01 -0800

-----Original Message-----
From: Harrington, Chris [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 10:14 AM
To: 'Rich Salz'; Harrington, Chris
Cc: [email-masked]
Subject: RE: Software for PKI

Chris

---

From: "Harrington, Chris" <[email-masked]>
Date: Wed, 7 Nov 2001 13:50:01 -0800

Rich,

Chris

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 8 Nov 2001 13:08:59 +1300 (NZDT)

Eric Rescorla <[email-masked]> writes:
[email-masked] (Peter Gutmann) writes:
>>My favourite example: Go to www.united.com and have a look at the cert you
>>get.
>I can't seem to connect to www.united.com:443

You have to go there with HTTP and then select one of the HTTPS links.

>I assume your point here is that it www.united.com redirects you to
>www.ual.com? If so, I don't see the problem with this. 

You end up (once you're using SSL) talking to a site which is completely
unrelated to United (itn.net) although there's no indication from the browser
that you've ended up talking to who knows what (that is, no warning unless
you've got the appropriate warning option enabled in your browser, if you do
enable it you get so many false alarms you tend to turn it off again fairly
quickly.  Also, the URL is so long you can't see the server name).  As a result
unless you go out of your way to check, it looks like you're talking SSL to
United when it's actually to itn.net.

(The same is true for any virtual hosting and whatnot system, I'm just using
United as an example).

Peter.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 07 Nov 2001 18:16:44 -0800

Peter I guess I must be missing something. The only links I have found on
the United site that point to itn.com are HTTP based and the HTTPS ones
point to a ua2go.com site and the CN of the certificate associated with that
site match the FQDN.

I also do not see what the problem would be here; the default behavior for
IE is to notify the user when the CN does not match (although it does let
you turn this off!!). Netscape also successfully notifies you of this
scenario, even on a redirect I think.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2001 4:09 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Software for PKI

You end up (once you're using SSL) talking to a site which is completely
unrelated to United (itn.net) although there's no indication from the
browser
that you've ended up talking to who knows what (that is, no warning unless
you've got the appropriate warning option enabled in your browser, if you do
enable it you get so many false alarms you tend to turn it off again fairly
quickly.  Also, the URL is so long you can't see the server name).  As a
result
unless you go out of your way to check, it looks like you're talking SSL to
United when it's actually to itn.net.

Peter.

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 07 Nov 2001 19:33:05 -0700

I'll plead guilty to a certain amount of hyperbole to emphasize my point, but there certainly are a number of systems that attempt to convey rights and authorizations directly and/or anonymously, including SPKI and (perhaps arguably) SAML.  Certainly the SPKI proponents would argue that possession of a private key and some kind of a credential granting you some kind of authorization is and should be sufficient. This is particularly true given the almost metaphysical problem of knowing who you "really" are, or attempting to provide a globally unambiguous "name".  

So it certainly isn't NECESSARY to provide identity in order to convey rights, it just happens to be the way we presently do it, however badly.  And then we never to around to addressing the really interesting stuff, which it the rights issue.  

Of course I agree with virtually all of the rest of the things you said. Like most of us, I spend most of my time trying to build and sell those kinds of wonderful PKI solutions to people, and have been now for the last 20+ years.  And any day now, all of this effort will bear fruit and I can retire a millionaire.  Until then, I'm about $999,999 short, unfortunately.

Bob

>>> Mitchell Arnone <[email-masked]> 11/07/01 07:05PM >>>
I am not sure I agree with the statement that no one really cares about 
identity.  How can anyone "know what you are authorized to DO" if you are 
not confident that you are who you say you are.  Only after proper identity 
has been established can proper permissions be assigned.  PKI is all about 
identity management and it may be the most effective method of identity 
management on the market today.

One of our problems is that we have not been selling solutions and that is 
because we have not properly identified the problem.  As a network 
engineer, I became tired and leery of building and supporting so many 
systems and applications with so many IDs and passwords.  I have designed 
and built IP networks, remote networks, VPN networks, Extranets and worked 
with all manner of application integration.  At one point, I had not less 
that 8 IDs and Passwords and it was a costly nightmare.  Companies are 
crying for a solution to this dilemma.

Now consider the alternative.  I have a badge that lets me into my 
corporate building and offices within the building with restricted 
access.  Then that same card permits me to login to the network from any 
workstation in the corporation and permits me access to personal 
information, applications, web pages and so on.   I can justify the cost 
for PKI simply as an effective identity management solution and this 
solution is available TODAY.

This is what attracted me to PKI in the first place and is the primary 
reason for pursuing a career focused on this exciting technology.

Yes ... non-repudiation, confidentiality and data integrity are crucial but 
until we can deliver a suite of applications that meet those needs simply 
and effectively, we need to focus on those areas where we can derive the 
greatest benefit today.  If we say that PKI is not effective because there 
are not sufficient applications to deliver on these benefits and the 
developers say that they will not deliver these kinds of applications 
because there is no business driver then we will be caught in a Catch 22 
with no way out.  But there is a way out.  PKI is an extremely effective 
Identity Management Tool/Service.  They say that if you develop a better 
mouse trap, people will buy it.  Well we have a great mouse trap right in 
front of our eyes, we just need to sell it, first to ourselves then to others.

As more PKI deployments take place, we will be better able to justify the 
business case for application designers to improve upon their efforts and 
to develop more effective applications that will help take advantage of 
these other significant benefits.

PKI and Identity management is a foundation service just like the network 
infrastructure and directories.  You build a strong foundation and 
construct your application architecture in a manner to leverage the 
strength of the foundation.

Lets not underestimate the value of Identity management.  That would be 
like underestimating the value in having a little toe... try cutting your 
little toe off and see how well you walk.

Mitch

At 04:47 PM 11/07/2001, Bob Jueneman wrote:

>It's rather ironic that as we are finally nearing the end of the PKIX 
>development effort we are beginning to talk about why it isn't being used.
>
>Let me offer my two cents worth:
>
>I believe that we have passed over the peak of technology hype, and are 
>now wallowing in the trough of disillusionment that always follows that 
>kind of crest.  Unfortunately, the collapse of the dot-coms and the rest 
>of the economy happened to coincide with the this disillusionment, and 
>9/11 has made matters even worse.  But although it may be difficult to see 
>the bright side right now, I believe we will eventually climb out of this, 
>and public key technology will be used -- either with or without PKI as we 
>presently know it.
>
>1.  The alleged communications security threat that PKI was envisioned as 
>solving simply not perceived to be real.  Most companies just don't have 
>any hard evidence that their e-mail is being compromised  -- at least not 
>enough to justify implementing end-to-end S/MIME for the average 
>user.  The Internet is envisioned by Joe Sixpack as being a dangerous 
>place, but that is because of computer viruses and compromised web sites, 
>NOT because of eavesdropping.
>
>2.  Despite the hype and hopes for using PKI for e-commerce, 
>nonrepudiation, etc., that hasn't materialized either.  By the time you 
>get through reading all of the fine print behind the CA's policies, plus 
>all of the legal  ifs, ands and buts required to effectively implement 
>non-repudiation, you realize that there is no way that a TTP CA could 
>really do a bang-up job of due diligence for any reasonable priced 
>certificate.  So you might as well negotiate a set of business practices 
>with your trading partners directly, and in which case you don't need a 
>TTP CA at all -- you just need his certificates or certificate chain, 
>without regard to any particular trusted root. So PKI doesn't scale nearly 
>as well as we had hoped it would, primarily because of legal and business 
>reasons, as opposed to technical ones.
>
>3.  Perhaps the biggest single blunder that the PKI advocates committed 
>(and I would include myself in that, unfortunately), was to focus 
>excessively on the issue of identity.  In business no one really cares 
>much about identity -- on the Internet no one knows you're a dog -- they 
>just want to know what you are authorized to DO, and whether you will pay 
>your bills.  Identity information provides an easy way to look up that 
>information, but is otherwise relatively useless (except perhaps for 
>audit, which no one does anyway).  And identity also collides with 
>privacy, and may be perceived as making matters worse, rather than 
>better.  Unfortunately, X.509 and PKIX got around to grappling with the 
>issues of authorization and rights far too late in the game, with 
>mechanisms that were poorly thought out (and remain so to this day) and 
>never widely implemented.
>
>In summary, PKI has not failed so much as TTP CAs have failed (at least 
>for end users), and S/MIME has failed  both for lack of a demonstrable 
>threat (unless you are a terrorist, in which case you would probably want 
>to use steganography rather than cryptography, to avoid disclosing that 
>you are doing something that might be suspicious) and because deployment 
>is too hard.
>
>On the other hand, PKI has succeeded brilliantly in solving the identity 
>problem for SSL, where it is now ubiquitous.  And it has been at least 
>marginally successful in dealing with the security issues involved in 
>executing downloaded applets, despite the debacle of the bogus Microsoft 
>certificate.  And those areas are precisely where the focus on identity 
>(and implied rights) is exactly on target.
>
>In addition, PKI has failed because provisioning is too hard, i.e.,  too 
>hard to manage.  Going to VeriSign for one certificate at a time is too 
>much work and costs too much, but installing something like VeriSign's 
>On-Site or the various toolkits available from Entrust or Baltimore 
>Technologies takes too much of a leap of faith -- the cost of entry for a 
>company is too high.
>
>Finally, another blunder within the PKIX community was in avoiding making 
>a firm commitment to use directory technology to distribute certificates, 
>while at the same time not espousing any other workable solution either, 
>such as some kind of an http mechanism.  As a result, S/MIME is too hard 
>to use because it is too hard to get your hands on the recipient's 
>certificates unless you go through a cumbersome exchange of signed e-mails 
>and manually enter them into to your list of recipient's certificates. 
>Yuck.  And I won't even mention the problem of managing trusted roots.
>
>Sigh.  "Ve get so soon alt, und so late schmart."
>
>Bob
>
> >>> "Harrington, Chris" <[email-masked]> 11/07/01 12:20PM >>>
>

***********************************************************
Mitchell Arnone
Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[email-masked] 
www.slb.com/nws 

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  +1 410-579-8691
Mobile  +1 443-838-9373

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 07 Nov 2001 19:40:18 -0800

Jim --
	It's not that SSL is in-secure; it's that SSL in itself is not a
complete solution. It does what it was designed to do (obfuscate data in
transit) and provide a level of authentication parties in a transaction, and
in fact it does this well. The problem is that this stuff is complicated for
the average administrator who's goal is to simply get it running and keep it
working, as such they store there keys in clear text on disk, to make things
worse no body knows who they trust and anyone with the right amount of money
can establish themselves as a trusted authority.

	Now, if the question is would some one choose to start an attack on
the SSL session, I would say the answer is a resounding NO since there are
far easier attacks (and probably more fruitful ones) one could take to
compromise a server.

	As a security practitioner I always want to architect, build and
deploy the most comprehensive and secure system possible. However in the end
it is all about mitigating risk right? So putting an overly complex (and
hopefully highly secure) system in an environment that does not need that
level is not only a disservice to the customer but likely will introduce
even more insecurities due to miss-management of the system.

Is PKI dead, I really do not think so there are finally a great set of
development tools and libraries out there for people to integrate this
technology into their applications easily. In-fact with the integration that
both Microsoft and Novell have done into their platforms of PKI I actually
think Enterprise PKI is going to blossom; it is not much more difficult for
the system administrator to produce and manage user certificates than it is
passwords now.

As for high assurance PKIs, TTPs, bridge CAs and VAs I think we will
continue to see these grow and as this happens we will see more vertical
trust consortiums but not like the past 10 years. At least not until the
application vendors catch up.

I hate to sound like an analyst (no offense to Gartner, IDC et al.) but PKI
will simply blend into the application; as far as usability is concerned
application vendors will make their stuff easy to use or it wont sell its
that simple.

My 2c,

Ryan

-----Original Message-----
From: jim [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2001 5:46 AM
To: [email-masked]
Cc: Galipeau, Jenny; 'Harrington, Chris'; [email-masked];
[email-masked]; 'Rich Salz'
Subject: Re: Software for PKI

I have to agree with Lynn.  SSL  is inherently insecure just because of its
nature.  It is a "secure pipe for rats to run through"  according to
government
sources.  If I were hacking someone for information, I would never hack at
the
message in transit as I would have to obtain everyone of the many packets
being
sent (the larger the message, the more difficult it is to get it all).  It
is
infinitely easier to hack the sending or receiving platform, specifically
where
SSL, SSh, and VPNs do not protect the data.  This is the call for PKI.

If the call is to abandon PKI rather than overcome the proprietary solutions
being offered by CA-PKI vendors or that will be offered by application
developers, that is taking the easy and cheap way out.  Note that this is
not
easy and cheap to the owner-protector of data, but to the people tasked with
finding the best workable approach.  Certificates and some of the structures
of
PKI need to be commoditized to reduce the cost issues.  There is just no
reason
for the inflated costs.  I would easily accept that the answer in the HTTP
domain is a middleware approach, and I believe that this august group should
be
looking at the approaches that will make PKI valuable to business, not at
making
it complex to the organizations that are selling it.

Jim Heimberg, Ph.D.

[email-masked] wrote:

> For 99.9999999 of the certificate associated events in the world today
....
> aka with SSL domain name certificates .... they aren't really a PKI ... it
> is manufactored certificates. Furthermore, the users are told that SSL is
> there to keep people from evesdropping on the credit card number ... which
> is a key-exchange protocol issue. There is some noise about certificate
> being used to make sure you are really dealing with the web-site that you
> think that you are dealing with ...  but I believe for the majority of the
> end-users that is just noise ... the majority already believe that they
are
> dealing with the web-site that they are dealing with. From that
stand-point
> the certificate part of SSL domain name certificates is pretty much
> extraneous protocol noise.
>
> Furthermore, the perported purpose of the SSL domain name certificates
> (aside from the SSL key exchange stuff) is because of worries about the
> integrity of the domain name infrastructure. However, if somebody goes to
> get a SSL domain name certificate from a TTP ... the TTP has to validate
> the request with the authoritative agency for domain names (aka the domain
> name infrastructure). To a large extent domain name infrastructure
> integrity issues ... that exist can impact not only standard domain-name
> lookup ... but also validation requests from TTPs. So a proposal to
improve
> the domain name infrastructure for the purposes of TTPs validating
> information for manufactoring SSL domain name certificates ... turns out
> would go a long way to improve the integrity of the domain name
> infrastructure for everybody's use (which in turn, nagates the
> justification for having SSL domain name certificates in the first place).
> random ref:
> http://www.garlic.com/~lynn/subtopic.html#sslcerts
>
> [email-masked] on 11/07/2001 11:09 AM wrote:
>

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 8 Nov 2001 15:49:44 +1100

But if I can either give you my IP address, or persuade you that my domain
name is the one you need, why do I find it so hard to also give you my
public key?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 8 November 2001 14:22
To: EKR
Cc: [email-masked]; 'Harrington, Chris'; [email-masked]; Galipeau,
Jenny; [email-masked]; 'Rich Salz'
Subject: Re: Software for PKI

The scenerio probosed for improving the integrity of the domain name
infrastructure for CAs is to have person registering his domain name, also
register his public key along with his domain name in the domain name
registery. One of the insecurities of the domain name system .... happens
to be domain name hijacking ... somebody impersonating the domain name
owner (with domain name hijack) getting a certificate issued to him for
that domain name (somewhat the same way that somebody got Verisign to issue
them a microsoft certificate). They now have a certificate from verisign
for that domain name. So registering the public key is the solution to
domain name infrastructure integrity so that the CAs can have better
confidence (including verisign) that they are truely dealing with the
person that registered the domain name.

Ok, however, if there is a public key registered with the domain name
infrastructure (as part of improving the integrity of the domain name
infrastructure on behalf of the TTP CAs) .... then the domain name
infrastructure could include the public key as part of the domain name
record.

Now the original purpose of certificates were the offline world .... the
early 80s where somebody called up, downloaded their email and hung up. Now
that they are no longer online ... they can not directly contact the
authoritative agency for the information directly and so needed a
substitute. Now these things called certificates effectively contained a
copy of the information kept by the authoritative agency ... these
certificates were manufactored at some time in the past and the information
by now could be quite stale. However, given the design point for
certificates of an offline world, with no authoritative information at all;
then a stale certificate was slightly better than now information at all.

Now the interesting part is that if the domain name infrastructure
registers the public key for the domain name owner .... and I was
interested in timely information .... which would i prefer 1) some piece of
stale data manufactored at some time way in the past that is the copy of
the information at the authoritative agency (based on the original design
point of a totally offline world)  or 2) the near real-time information
directly from the authoritative agency in an online world (especially
considering that the certificate is effectively only a stale copy of that
information from the authoritative agency design to address a problem of
the offline world and unable to contact the authoritative agency directly).

Now the interesting thing for SSL .... is if the TTP CAs fix the domain
name integrity issue for their own purpose with the registering of the
public key .... the existing domain name infrastructure can serve up the
real-time version of that registered information (public key) in the same
transaction that the ip-address is served up. Given a choice of an old
stale, R/O copy of the authoritative agency information .... getting the
currect up-to-date information seems a whole lot more interesting (and also
as a side-point was actually designed for an online world rather than the
certificate copy design point for the offline world). The other interesting
part is that the SSL setup handshacking chatter gets drastically simplified
.... all the client does is get the authoritative copy of the public key at
the same time it gets the domain name lookup. Huge amounts of SSL setup
chatter & noise goes away.

Now have an implementation that was actually designed for an online world
.... not the certificate stale copies that were designed for the offline
world; also since it is real-time, online ... there is no more of this
horrendously complex stuff about PKIs .... not more worry about things like
CRLs. These are the exact analogies to the credit-card paper booklets that
addressed the offline credit card credential world of the first half of the
last century .... every month send  out a paper-booklet to everybody of the
revoked credit card numbers. The problem was the same issue that PKI is
attempting to address .... credentials issued at some time in the past for
the offline world ...... and how to try and manage the updating of stale
information for an offline world.

Of course, in the 2nd half of the last century ... it appeared that the
world started going online ... and a large part of the target market for
certificates, CRLs, PKIs, is now having a harder time finding a niche.  If
I'm dealing with totally inconsequencial information of now value ... that
I problem am now as concerned about whether or not I may be dealing with
offline year-old stale copy of some information as opposed to a online
transaction directly with the authoritative agency for the information to
get the current, non-stale version.

random refs and more detail:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

Eric Rescorla <[email-masked]> at 11/07/2001 5:03 PM wrote

Of course, it's possible that some CAs (even Verisign, perhaps) gets
the information from DNS but those CAs have insecure policies.
Discovering that they did so wouldn't invalidate the purpose of
SSL certificates any more than it would be invalidated by discovering
that Verisign left it's private key lying around. You'd just want
to stop trusting said CA.

-Ekr

--
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: "Galipeau, Jenny" <[email-masked]>
Date: Thu, 8 Nov 2001 08:07:05 -0500

Lynn:

What a great idea!  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 10:22 PM
To: EKR
Cc: [email-masked]; 'Harrington, Chris'; [email-masked]; Galipeau,

-Ekr

---

From: Mitchell Arnone <[email-masked]>
Date: Thu, 08 Nov 2001 07:51:16 -0500

Mitch

I believe that we have passed over the peak of technology hype, and are now 
wallowing in the trough of disillusionment that always follows that kind of 
crest.  Unfortunately, the collapse of the dot-coms and the rest of the 
economy happened to coincide with the this disillusionment, and 9/11 has 
made matters even worse.  But although it may be difficult to see the 
bright side right now, I believe we will eventually climb out of this, and 
public key technology will be used -- either with or without PKI as we 
presently know it.

1.  The alleged communications security threat that PKI was envisioned as 
solving simply not perceived to be real.  Most companies just don't have 
any hard evidence that their e-mail is being compromised  -- at least not 
enough to justify implementing end-to-end S/MIME for the average user.  The 
Internet is envisioned by Joe Sixpack as being a dangerous place, but that 
is because of computer viruses and compromised web sites, NOT because of 
eavesdropping.

2.  Despite the hype and hopes for using PKI for e-commerce, 
nonrepudiation, etc., that hasn't materialized either.  By the time you get 
through reading all of the fine print behind the CA's policies, plus all of 
the legal  ifs, ands and buts required to effectively implement 
non-repudiation, you realize that there is no way that a TTP CA could 
really do a bang-up job of due diligence for any reasonable priced 
certificate.  So you might as well negotiate a set of business practices 
with your trading partners directly, and in which case you don't need a TTP 
CA at all -- you just need his certificates or certificate chain, without 
regard to any particular trusted root. So PKI doesn't scale nearly as well 
as we had hoped it would, primarily because of legal and business reasons, 
as opposed to technical ones.

3.  Perhaps the biggest single blunder that the PKI advocates committed 
(and I would include myself in that, unfortunately), was to focus 
excessively on the issue of identity.  In business no one really cares much 
about identity -- on the Internet no one knows you're a dog -- they just 
want to know what you are authorized to DO, and whether you will pay your 
bills.  Identity information provides an easy way to look up that 
information, but is otherwise relatively useless (except perhaps for audit, 
which no one does anyway).  And identity also collides with privacy, and 
may be perceived as making matters worse, rather than 
better.  Unfortunately, X.509 and PKIX got around to grappling with the 
issues of authorization and rights far too late in the game, with 
mechanisms that were poorly thought out (and remain so to this day) and 
never widely implemented.

In summary, PKI has not failed so much as TTP CAs have failed (at least for 
end users), and S/MIME has failed  both for lack of a demonstrable threat 
(unless you are a terrorist, in which case you would probably want to use 
steganography rather than cryptography, to avoid disclosing that you are 
doing something that might be suspicious) and because deployment is too hard.

Finally, another blunder within the PKIX community was in avoiding making a 
firm commitment to use directory technology to distribute certificates, 
while at the same time not espousing any other workable solution either, 
such as some kind of an http mechanism.  As a result, S/MIME is too hard to 
use because it is too hard to get your hands on the recipient's 
certificates unless you go through a cumbersome exchange of signed e-mails 
and manually enter them into to your list of recipient's certificates. 
Yuck.  And I won't even mention the problem of managing trusted roots.

Bob

35 Waterview Blvd.
Suite 210

Phone  +1 410-579-8691
Mobile  +1 443-838-9373

---

From: [email-masked]
Date: Thu, 8 Nov 2001 08:05:08 -0700

The issue is that the domain name infrastructure provides the domain name
mapping to ip-address ... and that infrastructure is built to some level of
trust.  Since it is already being trusted to provide that level of
information, it may be possible (if the trust level was sufficient) for the
domain name infrastructure to also distribute other associated information
associated with the information ... like public keys. The infrastructure
supposedly isn't built on random entities with unknown trust levels
providing arbitrary information. The point is that the trusted agency for
providing domain-name mapping isn't random individuals .... it is the
domain name infrastructure.

On the other side, PGP does, in fact, have individuals serving up their own
public keys ... and the relying party is given the opportunity to execute
(possibly out-of-band) operation for corroborating.

In effect, that is also what happens as the RA/registration authority
portion of any TTP CA operation. Somebody serves up their own public key
and some other piece of information .... and then it is up to the
CA/certification authority to invoke some certification process prior to
activating that information/public key (which in the TTP CA case is
manufactoring a certificate ... representing the provided information as
well as the validation/certification process).

The interesting characteristic about registering a public key at the same
time as registering the domain name .... is that puts the level of trust
for the public key at the same level of trust as accepting the registration
of the domain name i.e. to whatever extent there is trust in the whole
domain name registration and whatever trust attached to that domain name,
the public key trust is at the same level ... because it was part of the
same registration process. Trust in a domain name may include an arbritrary
number of previous transactions, word-of-mouth, etc.  The other part is
that while the whole certificate architecture has an offline-world design
point ... the domain name infrastructure was designed for online, near
real-time opreation (and so the whole issue of things like CRLs ... the
invalid credit card number paper booklets .... from the first half of the
previous century, goes away).

[email-masked] on 11/7/2001 9:49 PM wrote

---

From: [email-masked]
Date: Thu, 8 Nov 2001 08:20:22 -0700

therre is a web site that the rfc-editor points at:

http://www.garlic.com/~lynn/rfcietff.htm

some amount of that information also used to be included in STD1 ... and
the process used to generate the information on the web site also is used
to cross-check the information in STD1, including, but not limited to the
information that used to be carried in section 6.10 of STD1

http://www.garlic.com/~lynn/rfcietf.htm#obsol

however, I apoligize for not having a DNSSEC acronym (but it is possibly a
good addition) but go to

http://www.garlic.com/~lynn/rfcietff.htm

and slect "Term(term->RFC#)

and then from the keyword screen, select "DNS" ... will get you a list of
all DNS (including DNSSEC) related RFCs. The first one on the list (as of
this moment) is 3130. Clicking on 3130 serves up

3130
     Notes from the State-Of-The-Technology: DNSSEC, Lewis E., 2001/06/18
(10pp)
     (.txt=22291) (was draft-lewis-state-of-dnssec-02.txt)

clicking on 3130 will get you to all the terms that 3130 is categorized
under (domain name system & security). clicking on the "txt" field will
retrieve the actual field.

[email-masked] on 11/8/2001 8:05 AM wrote:

Do you know about DNSSEC, it's support in BIND, etc?
           /r$

---

From: Hal Lockhart <[email-masked]>
Date: Thu, 8 Nov 2001 11:02:05 -0500

First of all, the CSP is signed by Microsoft and verification is enforced
(primarily to enforce US export restrictions) so patching it is not all that
trivial. On the other hand, the flap over the "RSA key" showed that is is
possible to patch the public key while retaining compatability with
legitimate CSPs.

However, I think your comment is somewhat disingenuous. How would I verify,
for example, that Windows NT 4.0 SP6 or Solaris 8, with the following
patches... is what is currently running in my machine today? Its good to
think about all possible threats, but true security is risk management. That
means distinguishing among the possible, the probable and the likely.

Hal

> From: Florian Oelmaier [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 12:12 PM
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 8 Nov 2001 09:41:18 -0700

also some relying-party discusson
http://www.garlic.com/~lynn/aadsm2.htm#scale Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsm2.htm#inetpki A PKI for the Internet (was
RE: Scale (and the SRV
http://www.garlic.com/~lynn/aadsm2.htm#integrity Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsm2.htm#account A different architecture?
(was Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy
are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#mauthauth Human Nature
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature
initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures,
technology experiments, and service operations
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re:
KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#4 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#7 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#shock2 revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla...
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm5.htm#spki Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki3 Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose11 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki4 Software for PKI
http://www.garlic.com/~lynn/aadsmail.htm#perform AADS & X9.59 performance
and algorithm key sizes
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
http://www.garlic.com/~lynn/aadsmore.htm#vpki valid PKIs
http://www.garlic.com/~lynn/aadsmore.htm#killer0 Killer PKI Applications
http://www.garlic.com/~lynn/aadsmore.htm#scanon Smartcard anonymity patents
http://www.garlic.com/~lynn/aadsmore.htm#pressign President Clinton digital
signing
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/aepay2.htm#cadis disaster recovery
cross-posting
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations
regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
http://www.garlic.com/~lynn/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/aepay6.htm#dsdebate Digital Signatures Spark
Debate
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay6.htm#dspki2 use of digital signatures and
PKI
http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and
PKI (addenda)
http://www.garlic.com/~lynn/aepay6.htm#dspki4 use of digital signatures and
PKI (addenda)
http://www.garlic.com/~lynn/aepay6.htm#userauth2 MS masters NC mind-set
(authentication is the key)
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS)
Relying-Party Certification Business Practices
http://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on
DSTU X9.59
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#40 general questions on SSL
certificates
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication
implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format
standard
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001d.html#20 What is PKI?
http://www.garlic.com/~lynn/2001e.html#35 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/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#40 Self-Signed Certificate
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 9 Nov 2001 06:45:37 +1300 (NZDT)

[Several people asked this in private mail so I'm bouncing it back to the list]

Eric Rescorla <[email-masked]> writes:
>This isn't what I see. I just clicked on the "Join mileage plus" link which
>directs me to an HTTP page which has a redirect to an HTTPS page on
>www.ua2go.com (which is what the cert say). None of this seems out of order to
>me.

Try making a booking (that's the only important one, since it's the one which
you eventually send your CC details to along with authorisation for a $xK
transaction).

I'm not trying to pick on United here (I just happen to use the site a fair
bit and noticed it at some point), it's a standard feature of sites which
outsource their merchant services (which covers a lot of sites).

Peter.

---

From: "todd glassey" <[email-masked]>
Date: Thu, 8 Nov 2001 10:51:41 -0800

Peter  - responses below

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 08, 2001 10:22 AM
Subject: Re: Software for PKI

> "todd glassey" <[email-masked]> writes:
> >From: "Peter Gutmann" <[email-masked]>
> >>>>Sixpack) don't understand PKI and can't do much with it if you hand it
to
> >>>understand PKI in order to use it.
> >>
> >>Read the paper I referred to ("Why Johnny can't encrypt", Usenix
Security'99,
> >>it's scary reading).  Users weren't asked to understand PKI, they were
asked to
> >>exchange encrypted mail with someone else.  One person out of 12 managed
it.
> >>The others (with access to manuals, online help, etc etc) didn't.  Not a
good
> >>sign, particularly since PGP's laissez-faire key management (and
accompanying
> >>simple UI) is far less complex than any X.509-type system.
> >
> >Thats because the authors of those documents tried to teach the people
PKI.
> >What they should have had was a button on the header that said "ENCRYPT
THIS
> >MAIL" rather than document after document on PKI and its infrastructure.
>
> Uhh, what?  Have you actually *read* the paper?  As I said above, the task
they
> were given was "exchange encrypted mail with someone else", and the docs
they
> were given (PGP manuals) cover just that (I'm sure that if you went to the
PGP
> folks and told them that their manuals were actually attempts to teach PKI
> they'd have to be physically restrained from attacking you).
> The PGP manuals
> (and software) attempt to walk people through exchanging encrypted mail in
the
> easiest manner possible, what the paper found was that people couldn't
grasp
> even that.

No Peter, what the paper found is that the UI and the PGP description of Ted
and Alice and their PKI  process was still too complex for the average
mortal. What it clearly showed is that they, the normal user, didn't want to
know how the PGP PKI worked, or how to go through  N steps to encrypt or
decrypt a letter, they just wanted to know that it did. They wanted a much
simpler manner of using the tool. What they really wanted is a mail-browser
with a button that says "Send this letter encrypted" or "Decrypt this
letter" and a little icon that pops up to tell them that this media is in an
encrypted form that their UI supports and that was something that PGP
ignored in many of its incarnations.

---

From: [email-masked]
Date: Thu, 8 Nov 2001 11:43:21 -0700

the point was that there are integrity exposures with the current SSL
domain name certificates .... because of its dependancy on the domain name
infrastructure. There are proposals to fix the problem by registering
public keys in the domain name system.

The claim is that if public keys are in the domain name system as part of
fixing the issue for TTP CAs ... then it is relatively trivial for the
domain name infrastructure to start using those public keys ... including
current domain name infrastructure facilities to "serve-up" those keys in
online, real-time requests.  The observations is that if the problem was
fixed for the TTP CAs that the fix is also the seed for eliminating the
need for the SSL domain name certificates.

Furthermore, the claim is that such an implementation (once the keys are
being registered) is a much, much simpler (KISS) deployment for online,
real-time information that what it would take to turn the current SSL
domain name certificate manufactoring infrastructure into a real PKI (aka
real-time serving of public keys is much better and simpler strategry with
domain name infrastructure .... than trying to turn an offline-world design
point certificates into a PKI).

ekr.rtfm.com at 11/8/2001 10:39 am wrote:

Yes, that's true. So? It's still better than nothing which is what
we had before.

-Ekr

---

From: [email-masked]
Date: Thu, 8 Nov 2001 13:59:14 -0700

let say it is a bank with bank employees. The bank may be required to run a
FBI check on all employees associated with various kinds of financial
responsibility. That is obviously a identification issue.

however,. for all the authentication and authorization operations that
occur in a banks internal operation .... it is of absolutely no use to know
a person's name for authentication and authorization.

in the point-of-sale & e-commerce scenerio it serves little purpose that a
people's name & address have to be kept in some 20 million merchant web
servers around the world.  All that is necessary is for the merchant to
know that a correct transaction occurs and the merchant gets their money.

In effect, authentication and authorization w/o identification is
sufficient for correct operation. The problem that does crop up is large
amounts of incorrect operation (i.e. insdier fraud is documented as being
the largest type of fraud). For in-correct operation it is useful to have
an audit trail so that it is possible to track back from an authentication
& authorization event as part of financial forensics so that recovery and
remediation processes can be put into effect. However, it is not necessary
to have identity directly invovlved in the direct authentication &
authorization process as part of correct operation.
Part of it, isn't that the corporation might not have to determine at some
point exactly who you are .... but that it is unnecessary to repeatedly
propogate large amounts of identity on every transaction (for fraud, it is
just sufficient that there is some way of tracking a frauduent activity
back to an individual).

The unnecessary propogation of identity related information on transactions
which only require authentication and authorization.

Basically I need to proove that some authentication & authorization belong
to me ... I don't need to proove who i am (although there may be a way of
correlating things that belong to me with who i am).

Following is discussion of picture card ... not for identification purposes
... but for authorization purposes. The ID didn't need name or anything
else. The purpose of the picture was that somebody could check that the
card being used actually belonged to the person using it.
http://www.garlic.com/~lynn/aadsm7.htm

and how authentication and authorization deals with correct operation and
typically identification deals with recovery, remediation, and possibly
deterance.

Now, some number of corporations (besides EU banks for customers) have gone
to relying-party-only certificates .... basically no identification ... but
only an account number .... let's say an employee number. The employee
number has associated with it various authentication properties as well as
authorization properties. Digital signature operations are one form of
authentication in a relying-party type of environment. At the simplest
having a "credential" from a specific employer and being able to
demonstrate that it is your credential is sufficient for certain minimum
authorizations/previleges. However, in the previous posting regarding EU
banks it is possible to trivially show that it is unnecessary, redundant
and superfulous  to append a certificate to a digitally signed message that
is going to the relying party (either by the zero byte compression rule or
the relying party already has the original rule).

So as in the DNS case registering public keys provides an avenue for
totally obsoleting the necessity for SSL domain name certificates .... what
about employee/customer certificates. My previous claim that possibly
99.9999 percent of the exiting certificate related authentication events
are SSL domain name certificates ... and it is fairly straight-forward to
totally obsolete the necessity for such certificates. Also it is possible
to show that is straight-forward to totally obsolete the relying-party-only
certificates in the financial customer transaction case.

What about the employee/client/corporate case? I would also claim that
99.999 percent of the client-related authentication events that happen in
the world today involve RADIUS. RADIUS currently involves shared-secret
and/or challenge/response ... frequently observed when customers contact
their ISP or employees dial into corporate networks. So, it is relatively
straight-forward if a corporation was to register public keys in a database
(i.e. the RA, registration authority, part of a certification authority,
and also store the original of a manufactored certificate there), then the
simplest deployment is to hook up a real-time, online RADIUS infrastructure
to that database and also enable RADIUS for digital signature
authentication.  The message is signed, the message and digital signature
are transmitted and RADIUS authenticates the digital signature with the
real-time, online access to the RA-registered public key. It has the
advantage of being currently deployed infrastructure for 99.999 percent of
the internet, and is an online real-time design point. It doesn't have the
short-comings of a PKI infrastructure designed for the offline, stale,
out-of-date operation with manufactored certificates. Furthermore, any
invention for adding online, real-time to a PKI ... can be done better by
eliminating the certificate all together and directly using the real-time
information.

misc. threads regarding use of public keys in existing RADIUS
authentication and authorization infrastructures;
http://www.garlic.com/~lynn/subtopic.html#radius

For a list of RADIUS RFCs: goto
http://www.garlic.com/~lynn/rfcietff.htm

and click on "Term (term->RFC#)" and then scroll down in the abbreviations
to "RADIUS" and click on "RADIUS".

For a list of authentication related RFCs goto
http://www.garlic.com/~lynn/rfcietff.htm

and click on "TERM (term->RFC#)" and then scroll the frame down to the term
"authentication". Also listed are RFCs from the "Authentication,
Authorization and Accounting" work group, as well as terms related
specifically to authorization. The authentication term also points "UP" to
RFCs that are related to security in general.

You may also find of some interest the security taxonomy & glossary at:
http://www.garlic.com/~lynn/index.html#glossary

there is both the Security specific taxonomy/glossary as well as a X9F
standards taxonomy/glossary
Security
     Terms merged from: AFSEC, AJP, CC1, CC2, FCv1, FIPS140, IATF IEEE610,
ITSEC,
     Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983,
RFC2504,
     RFC2828, TCSEC, TDI, TNI, and misc. Updated 20010729 with glossary
from IATF V3.
X9F
     Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24,
X9.31,
     X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69.
     Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary
(identified
     by lower case x9 instead of upper-case X9). Original source documents
include: X3.92,
     X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24,
x9.26, x9.28, x9.30,
     x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62,
x9.69 x9.74, x9.76,
     x9.78, x9.80, x9.82, and TG-17. (990710)

[email-masked] at 11/08/2001 10:35 AM wrote

If I understand your point correctly, you are making reference to the usage

of real human names in certificates.  There is the question of where does
privacy begin and where does it end.  In a corporate office, do you have a
right to keep your name private?  Sure you can be as private as you want at

home and in your personal transactions but I can't imagine a valid argument

for the same level of paranoia in the work place.  Privacy is a very
important concern but even if you use some other form of unique
identification that can not be correlated with obvious private human
information, you are still dealing with identity management.  Your name may

not be included in that certificate but somehow and somewhere there must be

some sort of non-reputable association between that certificate and a
specific human.  This is identity management!

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 9 Nov 2001 12:23:35 +1300 (NZDT)

"Ryan Hurst" <[email-masked]> writes:

>I would certainly advocate that we add a requirement that there is use case
>documentation included with all of these technology drafts.

What about requiring that drafts include a rationale, as the IEEE has always
done?  This is slightly different to what you're proposing, but would help in
two ways:

1. Authors would be forced to explain what they're doing, which would help
   clarify the thinking behind some of the stuff in PKIX drafs (and reduce the
   "WTF??!" factor experienced in reading some of them).

2. Readers wouldn't have to rely on guesswork so much, enhancing
   interoperability.

(It should be noted that no-one's actually prevented from including a
 rationale, it's just not usually done.  I've included a rationale for each
 decision in my drafts, which hopefully helps clarify things not explicitly
 mentioned in all the MUST/SHOULD/whatever text).

Peter.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 9 Nov 2001 10:53:06 +1100

The problem is not in the registration. The problem is in retrieving the
public key. PGP, for example, is based on the "web of trust", and this does
not mean picking up public keys where you can find them.

Putting public keys into DNS would be as useless as tits on a bull. DNS
offers no security. It is trusted only because providing the IP address for
a domain name is not yet regarded as a critical function. Providing public
keys in this random way would, I guess, expose the vulnerabilities of the
system.

Ron.

---

From: [email-masked]
Date: Thu, 8 Nov 2001 17:19:59 -0700

... the DNSSEC RFC standards talk about adding security to DNS ... in part
by starting with effectively chain of trust/evidence with public keys.
independent of the DNSSEC work, registering of public keys would also
support making the domain name infrastructure more secure for TTP CA
purposes associated with SSL domain name certificates.

the mapping of domain name to ip address integrity issue was the primary
reason for having SSL domain name certificates at all in the first place.
While most people click on https for secure tunnel for their credit card
numbers .... the actual implementation of the SSL handshaking chatter ....
checks the domain name in the certificate provided by the server it is
talking to at the ip-address provided by dns ... with the domain name that
it thinks it is talking to.

Having created that infrastructure for SSL domain name certificates ....
somewhat implies that somebody thot the mapping from domain name to
ip-address was an issue .... enuf to justify the whole SSL domain name
certificates and browser use of those domain name certificates as part of
the SSL/TLS protocol .... aka if there was an actual belief that the
ip-address for the specified URL was always correct .... there would be no
reason for the client to check if the server at the ip-address mapped by
DNS is the server that the client thinks it is.

The issues are

1) DNSSEC & public keys can be part of scaffold to address integrity issues
in the domain name infrastructure (both for TTP CAs but also for all the
clients in the world)

2) with #1, clients can trust the DNS IP-addresses ... then they can
eliminate the check that they do with SSL domain name certificates
(checking that the server at the DNS-provided ip-address they are talking
to has the domain name certificate that matches the domain the client
specified in the browser ... prior to the DNS lookup).

3) if #2, then SSL domain name certificates can be eliminated as
unnecessary, superfulous and redundant.

4) if #1, and somebody actually wants to know a server's public key, and
they can otherwise trust the distribution of information by the domain name
infrastructure ... then they can also trust the DNS distribution of public
keys ... in so far as the public key is with respect to some network domain
name operation.

[email-masked] on 11/8/2001 4:53 PM wrote:

Ron.

---

From: [email-masked]
Date: Thu, 8 Nov 2001 18:17:21 -0700

as an aside ... rfc3000 went up yesterday (i.e. new STD1) and there were
some minor nits when I parsed it ... but there is a new rfc3000 with
corrections up now and I've also just finished updating the index at
http://www.garlic.com/~lynn/rfcietff.htm

also if there is interest ... i can go back add an explicit DNSSEC
category/indexing to the term index.

and for whose of you intested a bunch of new "ancient" RFCs have also gone
up (these are old RFCs, typically from the early '70s that lacked a
'electronic' version ... and there is program to go back and generate
softcopy from surviving hardcopies.

__________________

lynn.wheeler wrote:

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 08 Nov 2001 17:58:31 -0800

Peter --
	Hmm, this would be much less of a burden on the author and would
certainly help with the problem....

Ryan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 08, 2001 3:24 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Software for PKI

What about requiring that drafts include a rationale, as the IEEE has always
done?  This is slightly different to what you're proposing, but would help
in
two ways:

1. Authors would be forced to explain what they're doing, which would help
   clarify the thinking behind some of the stuff in PKIX drafs (and reduce
the
   "WTF??!" factor experienced in reading some of them).

Peter.

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 08 Nov 2001 17:55:50 -0800

Agreed :)

Ryan

-----Original Message-----
From: todd glassey [mailto:[email-masked]] 
Sent: Thursday, November 08, 2001 2:14 PM
To: Ryan Hurst; 'Mitchell Arnone'; [email-masked]
Subject: Re: Software for PKI

Thanks for the response Ryan - I agree but this change will take an
amendment of the charter. I would also recommend that all in process works
be required to produce said same use draft prior to be advanced and further
that any drafts or RFC's that seek advancement that do not have the Use
Models defined be refused any further motion.

anything else belongs in the IRTF and not here.

Todd

----- Original Message -----
From: "Ryan Hurst" <[email-masked]>
To: "'todd glassey'" <[email-masked]>; "Ryan Hurst"
<[email-masked]>; "'Mitchell Arnone'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 08, 2001 12:00 PM
Subject: RE: Software for PKI

>
> I see the ROI coming from the benefits associated with unified
> authentication systems and ability to manage fewer disparate
authentication
> technologies.
>
> I full heartedly agree about the continuous influx of drafts on solutions
to
> problems that are not well defined and even worse specifications that
simply
> do not map into any real business need :). I also see us continuously
coming
> up with new ways to do the same thing which is always fun :). I would
> certainly advocate that we add a requirement that there is use case
> From: todd glassey [mailto:[email-masked]]
> Sent: Thursday, November 08, 2001 9:51 AM
> To: Ryan Hurst; 'Mitchell Arnone'; [email-masked]
> From: "Ryan Hurst" <[email-masked]>
> To: "'Mitchell Arnone'" <[email-masked]>;
> <[email-masked]>
> Sent: Thursday, November 08, 2001 8:18 AM
> > Mitchell --
> > The difference is that in many (but not all) cases "knowing that the
user
> is
> > authorized" and "knowing that you have had previous contact with the
user"
> > is adequate. But even in these cases we still want to know the literal
> "who"
> > we are doing business with, I think this is more a matter of human
nature
> > than anything else.
> >
> > I too think PKI can be a ROI tool, even if we do not take the security
> > aspects of the technology into consideration. Building heterogeneous
> > authentication infrastructure that is used across organizational and
> > technological boundaries has a great potential for return.
>
> Where is the ROI over running a "hardened" computing environment with
local
> auth models?
>
> The only thing that makes PKI of any real interest to many ifs that it
> promises to take the "Human culpability" factor out of most long term
> logging or instantaneous decision processes. But I to date have still
failed
> to see how its going to keep these promises.
>
> This is the problems with allowing people to submit draft after draft on
> technologies without require some rudimentary statement about how its to
be
> used and its constraints, which is why the TS Protocol, for example, is
> still undergoing revision after revision.
>
> Why not just mandate User Documents be required before anything is
> transferred to a Standards Track? - BTW - take this as an official motion
to
> the WG as a whole for an amendment to the charter.
>
> Todd
>
>
> >
> > My 2c,
> >
> > Ryan
> >
> > From: Mitchell Arnone [mailto:[email-masked]]
> > Sent: Thursday, November 08, 2001 4:51 AM
> > To: [email-masked]
> now
> get
> TTP
> much
> audit,
> for
> a

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 9 Nov 2001 18:58:30 +1300 (NZDT)

"Ramsay, Ron" <[email-masked]> writes:
>The problem is in retrieving the public key. PGP, for example, is based on the
>"web of trust", and this does not mean picking up public keys where you can
>find them.

It doesn't?  That's the whole point of the WoT, you grab a key from wherever
and then use the web to verify whether it's good or not (whether it actually
works that way in practice is another matter, usually only the first half
works).

Peter.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 9 Nov 2001 17:12:37 +1100

So, the WoT allows you to *recognise* the key. I say this is as good as
*having* the key. It certainly doesn't (shouldn't - I note your point) allow
you to download a key which is *supposed* to be the object's public key but
isn't. PGP has those signing party thingies - I don't believe that "trust
me, it is right key" is part of the procedures.

The aim of a PKI must surely be to prevent you from erroneously accepting a
public key as belonging to a principal you wish to communicate with when it
actually doesn't.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, 9 November 2001 16:59
To: Ramsay, Ron; [email-masked]
Cc: [email-masked]
Subject: RE: Software for PKI

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 9 Nov 2001 19:24:20 +1300 (NZDT)

>public key as belonging to a principal you wish to communicate with when it

It depends.  If you can't *get* a key then it doesn't matter whether it's
certified, authenticated, authorised, etc etc up the wazoo.  The primary aim of
a PKI is therefore to get you a key.  After that, you can look at verifying it.
(It's like water in a desert, your primary goal is to find the stuff, after
that you can decide whether you want to drink it or not.  If you can't find it
in the first place it doesn't matter whether it's clean or not).

What PGP gives you is a means of getting a key (go to any PGP keyserver, enter
the victim's name or email address, grab the key).  That at least gives you
probable security, in the sense that it's the real thing with a high
probability.  I wouldn't even know where to start doing the same thing with
X.509, because I have no idea where to look for a key.  The result is highly-
probable email security vs no email security.  I'll take the highly-probable
option, thanks.

(The effective security or lack thereof of a PGP WoT key vs a Verisign free
 email cert can be argued elsewhere.  Cream pies will be provided).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 14 Nov 2001 09:06:11 +1300 (NZDT)

Stephen Kent <[email-masked]> writes:

>The IETF imposes certain requirements for advancement of documents in the
>standards process and it is not obvious that the PKIX WG is unique in a
>fashion that requires or motivates deviation from the procedures by which the
>rest of the IETF operates, in this regard.

You're right, the PKIX WG isn't unique, many other security WGs are also in
desperate need of this.  TLS (with its endless flow of proposed cipher suites),
IPsec (with... well, with everything basically, this one sort of goes without
saying), and S/MIME (with strange-ways-of-doing-unexpected-things-with-SMIME)
all need a requirement to provide a rationale and business cases to justify
some of the drafts which are appearing.

There are groups which don't have this problem.  Examples are OpenPGP (a single
RFC specifying the format, with an update in the works), SSH (a fixed core set
of RFCs, although there's some cruft starting to accumulate), and syslog (one
RFC, one or two add-ons), so it's limited only to some WGs.

>I am aware of no precedent in the IETF that requires the sort of documentation
>Todd has suggested as a normal part of developing IETF standards

The reason for this is that historically it hasn't been necessary.  You have
(for example) RFC 959, and that's about it.  There aren't 25 further RFCs all
specifying slight (incompatible) modifications and "enhancements" and
alterations, with overlaps and incompatibilities and no clear idea of why any
of them are useful except to the people who proposed them.  

OTOH if you've got the situation which PKIX (and IPsec, TLS, and S/MIME) are
in, where there's such a confusion of stuff that noone who isn't intimately
involved in the standard-setting process can figure out what's going on,
authors should be required to justify what they're doing.  It's easy enough for
anyone to throw together an RFC, but if you can't explain why and how it's
useful then it's a good sign that it's not worth persuing.

It would be good if PKIX could lead by example in this area.

Peter.

---

From: [email-masked]
Date: Fri, 16 Nov 2001 16:35:34 -0700

it was a multi part piece of logic

1) part one ... early X.509 Identify certificate work for offline
credentials has morphed into several other forms

2) ... identity is useful for more than a single relying party

3) ... eliminating identity ... somewhat restricts the domain of offline
credentials.

4) one of the morphs was into online relying-party-only credentials

5) it was possible to show that in the case of relying party only
credentials, the relying party only certificates were unnecessary,
superfulous, and redundant.

As before the nominal X.509 identify offline certificates could involve
into other types of offline information binding credentials. However, many
of the X.509 offline credential morphs for the online world could be shown
that such credential was unnecessary, redundant and superfulous (when the
online original of the
information was being accessed).

In the case of a relying party only scenerio that was accessing the online,
real time account information ... that contained the original of the
relying party only certificate .... it was possible to show either

a) reduction of  the appended relying party only certificate to zero bytes
... since the receiving relying party already had a copy of all the
information in the relying party only certificate

b) eliminating the appended relying party only certificate ... since the
receiving relying party already had the original of the relying party only
certifciate.

replay of this same discussion in this newsgroup from august of last year
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation
checking capability

general thread on offline stale credential vis-a-vis online, real-time
information:
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI

[email-masked] on 11/12/2001 6:20 AM wrote:

Lynn:

Good grief.  You are a smart guy.  Do you say these things just to provoke
reaction?

There is nothing in X.509 or PKIX that warrants such statements.

The whole point of a public key certificate is to bind a public key to an
identity.  The form of the subject identity can be application
specific.  For example, to support S/MIME, the certificate binds an
electronic mail address to the public key.  To support a anonymous payment
protocol, the certificate would likely bind the public key to an identifier

of the financial institution and an account number, where only the
financial institution need know the identity of the account owner.  This is

clearly the opposite end of the spectrum from QC defined in RFC 3039.

Do not condemn the public key certificate because one application makes use

of a different form of identity than another application.

Russ

---

From: [email-masked]
Date: Fri, 16 Nov 2001 16:50:30 -0700

... also, with respect to the other direction this thread has taken ....
some of the business justification issues may be when force-fitting
offline, non-identity credentials manufactored at some time in the past
.... into environment that is directly accessing the online, real-time,
non-stale, superset of the credential (the easily obvious is the financial
institution case, that given only the account number ... the operation
references the account record which contains the real-time, online,
non-stale, superset of the credential).

Lynn:

Russ