Subject: Re: Scale (and the SRV record)

From: [email-masked]
Date: Wed, 28 Oct 1998 10:13:23 -0800

spent a lot of time on the SSL portion of the web ... 94/95 working out how
to do/deploy electronic commerce operations. Current SSL infrastructure
uses server certificate for key exchange ... not for authentication. To the
extent that there is authentication done ... it consists of checking the
certificate issuer against a list that has typically pre-installed in the
browser (not checking on the certificate owner). It is one of the reasons
that I coined the term certificate manufactoring .... to highlight
manufactoring and distributing certificates is typically only a small part
of what has become to be considered part of a PKI infrastructure.

I got possibly the first mutual authentication SSL deployed ... before it
was called SSL3. Again authentication was limited to verifying the
certificate issuer. The server certificate was essentially a comfort device
for all the clients ... the client certificates started out essentially
being "relying party" certificates .... but to do more than simple
certificate issuer authenitcation ... i had to check the certificate owner
information against an account database. At that point it became evident
that even relying party certificates were superfulous in the transaction
since I needed to reference the account record (which already had copy of
the public key, lots of attribute binding ... as well as up-to-date
real-time status).

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 29 Oct 1998 09:15:15 +1100

> -----Original Message-----
> From:	Russ Housley [SMTP:[email-masked]]
> Sent:	Thursday, 29 October 1998 5:29
> To:	Alan Lloyd
> Cc:	[email-masked]
> Subject:	Scale (and the SRV record)
> 
> Alan asks:
> 
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
> 
> Directory is the preferred certificate repository, but it is not the
> only
> repository that will scale.  People have used FTP, Finger, HTTP, and
> other
> mechanisms to distribute certificates.
	[Alan Lloyd]  
	Distribution of certificates is not the issue.
	How as a recipient of signed messages follow multiplecertificate
paths - without a directory?.

>  The PKI is not dependent on the deployment of a Directory, as these
> other
> mechanism can be used until the Directory become widely available.
	[Alan Lloyd]  But as I have said, they are bespoke, do not tie
well to business and customer management/ service delivery models or
distributed , transaction based information systems over a wide scale -
efficiently.
> Further, a trusted repository is not a requirement.  Since
> certificates and
> CRLs are signed, the repository cannot make undetected modification to
> the
> data structures.  Denial of service is allways an issue; it is a
> concern in
> all of the possible repository alternatives.
	[Alan Lloyd]  Agree 
> Russ

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 29 Oct 1998 10:20:36 +1100

Sean, I agree. But there are windows - ie, if a master gets a CRL when
one does not already exist and it has not propagated to the replicas -
then there is a window in which a cert could be deemed valid when it
isnt. ie. We can chose to accept replication delays or we can get higher
trust by requesting cert path objects from the master DSA (using DAP).

Its just a timing hole that system designers with LDAP should watch out
for.
regards alan

> From:	Sean Turner [SMTP:[email-masked]]
> Sent:	Thursday, 29 October 1998 10:10
> To:	Alan Lloyd
> Cc:	[email-masked]
> Subject:	Re: Scale (and the SRV record)
> 
> Alan Lloyd wrote:
> > 
> > > From: [email-masked] [SMTP:[email-masked]]
> > > Sent: Thursday, 29 October 1998 5:56
> > > To:   'Russ Housley'; Alan Lloyd
> > > Cc:   [email-masked]
> > > Subject:      RE: Scale (and the SRV record)
> > >
> > > >Denial of service is allways an issue; it is a concern in
> > > At the risk of stating the obvious, a denial of service that
> > > prevents you from getting revocation information (such as a
> > > CRL) can be Very Bad, given the implementation quality of most
> > > network services that I've seen...
> >         [Alan Lloyd]
> >         Yes, and we enforce that risk by saying LDAP is the way to
> go.
> > :-)
> >         "Dont Use Copy" - see X.511 (DAP) and knowing master DSAs
> is
> > good.
> > 
> >         regards
> 
> Alan,
> 
> You can use a shadowed copy of a CRL or a master copy it doesn't
> matter it's a signed object.
> 
> spt

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 29 Oct 1998 09:35:45 +1100

Phill - you have missed the point I think. Its not a DNS issue or an SSL
issue or a certificate structure issue.

PKI from many people's perspective is about applying cryptographic
techniques to current business information systems. These information
systems support services to the masses over a wider environment. ie the
generic business model is to authenticate uses at a number of levels,
allow service profiles to be applied to those users and verify
transactions by those users at the originating and the recipient end of
the business. And this must occur across a multi domain environment. The
foundation of all this is information sets related to Users and Services
and because these need to be globally named, distributed and protected
(and evolving to OO paradigms) then the directory serves this
requirement. PKIs are applied to this evolution. They DONT create it.

ie. DNS is about host / domain names for computers to relate IP
addresses .ie machiney level things. Its not OO in my book.
X.500 is about OO application to real life entities such as ships,
people, workflow applications, library books, Media content, Users, etc.
real named items with real life attributes with real life privileges.

X.500 is being deployed in masses....with PKIs and a lot faster than
PKIs on their own  - reason already stated. 

regards alan

> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Thursday, 29 October 1998 3:37
> To:	Alan Lloyd
> Cc:	Stephen Kent; [email-masked]
> Alan issued the following challenge,
> 
> Seems like a good question, it occured to me that now is a good time
> to
> raise it.
> 
> Look at the one already deployed and work it out. The SSL secured part
> of
> the Web does not stop working if directory.verisign.com goes down.
> 
> I have had this arguement before with the hypertext establishment.
> They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were
> completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L
> to
> give the keynote!
> 
> The greater the scale the less weight a base information system can
> carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of
> consistency
> across transactions. Finally at global scale it is not practical to
> deal in
> data, we must deal in names instead, names in this case being of
> Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live)
> to
> make the DNS sytem tractable, precisely because they have Sebok's
> 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
> 
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
> 
> Making PKI scale to global reach is no more than a matter of naming.
> Bind
> the network level directory infrastructures to the internet naming
> system
> which is and will continue to be DNS.
> 
> There is already a DNS resource record defined for the purpose - SRV.
> If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
> 
> Email client is to send to [email-masked], there is no cert in the
> address
> book:
> 
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> 	_ldap._tcp.arius.com	SRV 0 0 389 directory.arius.com
> 	_ldap._tcp.arius.com	SRV 1 3 389 fast.backup-site.net
> 	_ldap._tcp.arius.com	SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest
> priority
> 	number which offers a directory protocol that is understood,
> 	in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> 	[email-masked]
> 5) The client retrieves the certificates for the entry, there are
> three
> 	of which one is a currently valid one for [email-masked]
> 6) The client encrypts the email
> 7) The client sends the email
> 
> 
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
> 
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
> 
> 
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
> 
> 
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
> 
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
> 
> 	__pkix._ldap._tcp.arius.com	SRV 0 0 389 directory.arius.com
> 	__pkix._ldap._tcp.arius.com	SRV 1 3 389 fast.backup-site.net
> 	__pkix._ldap._tcp.arius.com	SRV 1 1 389 slow.backup-site.net
> 
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
> 
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
> 
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have
> deployed.
> 
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
> 
> 
> 		Phill
> 
>

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 29 Oct 1998 11:10:39 +1100

I think the response I gave was about denial/system integrity re getting
CRLs or not with master/replicas.

As LDAP is now much bigger than DAP (with half the functionality) I
would rather call LDAP HDAP and DAP EDAP (efficient DAP) :-)

I agree that no matter what protocol you use, denial of service is an
issue as protocols cannot prevent hogging by other or someone switching
the machine off.

The real issue is that some protocols (not simple or lightweight ones)
provide system selection features (chaining/replication selection
control) and the use of these assist with system operation and
information integrity ie. improve reliability and trust. 
regards alan

> From:	Paul Koning [SMTP:[email-masked]]
> Sent:	Thursday, 29 October 1998 11:02
> To:	[email-masked]
> Cc:	[email-masked]
> >>>>> "Alan" == Alan Lloyd <[email-masked]> writes:
> 
>  >> -----Original Message----- From: [email-masked]
>  >> [SMTP:[email-masked]] Sent: Thursday, 29 October 1998 5:56 To:
>  >> 'Russ Housley'; Alan Lloyd Cc: [email-masked] Subject: RE:
>  >> Scale (and the SRV record)
>  >> 
>  >> >Denial of service is allways an issue; it is a concern in >all of
>  >> the possible repository alternatives.
>  >> 
>  >> prevents you from getting revocation information (such as a CRL)
>  >> can be Very Bad, given the implementation quality of most network
>  >> services that I've seen...
>  Alan> [Alan Lloyd] Yes, and we enforce that risk by saying LDAP is
>  Alan> the way to go.  :-)
> 
> How so?  I've never heard of a protocol that's immune to denial of
> service attack.  Why would replacing LDAP by HDAP help?
> 
> 	paul

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 30 Oct 1998 12:12:48 +1100

Phill - this one jumped to light speed eh? Comments as usual follow.

> Sent:	Friday, 30 October 1998 11:19
> To:	Alan Lloyd
> Cc:	[email-masked]
> > > Hence the motivation for an Online Status service like OCSP.
> > 	[Alan Lloyd]  Please enlighten me.
> > 	Companies make telephones based on the fact that there is a
> > distributed telephone network (switching infrastructure) out there
> that
> > supports global numbering and common protocols.
> 
> The Internet is not like a telephone service. It is a network of
> networks
> and not a network.
	[Alan Lloyd]  So is the phone service - see BT, AT&T, NTT, I
wonder what the P in PABX means.

> The differences between the circuit switching infrastructure of the
> telephone system and the packet switching infrastructure of the
> Internet
> are significant and fundamental. The telephone system is optimized for
> voice, not data. As the role of data networks increases it is the
> telephone infrastructure which is being absorbed into the data network
> and not vice versa.
	[Alan Lloyd]  The telephone paradigm is used to indicate an
infrastructure which is distributed, owned by many, applies universal
numbering plans and scales efficiently.

	It was not used in the debate to talk of bits and bytes.

> Don't try to re-fight the OSI vs IP protocol stack wars. This is not
> the place to do that. You might as well advocate gun control in
> talk.guns
> or go to a Klu-Klux-Klanbake and advocate racial tollerance. Nobody is
> 
> arguing that directories do not have an important role in the
> Internet. 
> But you seem to have to insist that everything that could be done by 
> a directory SHOULD indeed MUST be done by one or it will fail to meet 
> the catalog of noise word criteria you state.
	[Alan Lloyd]  Warp 7 on this one. I just say that when
directories are applied as the information infrastructure then PKIs are
much better and collectively they suit service provisioning for
businesses more efficiently. This is natural and expected being that
X.509 and PKIs is part of the X.500 directory standards.
	(But isnt it odd that ASN.1 was defined as the tool for creating
presentation layers (layer 6 in OSI) and now its in many
specifications.)

>   I don't think you are doing a very good job of being an advocate for
> directories. When you lump them together with terms that are so
> overused
> as to be meaningless marketing noise I suspect that many people will
> dismiss directories as another sales pitch hype 
	[Alan Lloyd]  But there are many that arent - to their benefit.

> which will promise 
> everything but deliver little: Object oriented - Isn't everything?
> Scale - in whose laboratory? Oh its a pitch for a directory and it 
> will solve all my problems - I'll buy 3, make that 4 if it will also
> solve my Y2K. Do you support OpenGenera?
	[Alan Lloyd]  You obviously have one world, I have another. I
help design large scale distributed (secure) information systems that
work across continents so my views might be different to yours.

> The directory plays a very specific role in a PKI as a repository of
> signed objects. It does not create signed objects, it does not vouch
> for their trustworthiness. 
	[Alan Lloyd]  Never said it did.

> It does not replace DNS. 
	[Alan Lloyd]  But it could and may be it will.

> How the directory
> system manages its bits is its own affair. It is not the concern of 
> the PKI except that the PKI must not rely on the directory service to
> fulfil expectations it is not capable of meeting.
	[Alan Lloyd]  Thats a view again. Not mine.

> There are roles for other types of PKI components but they are not
> called directories. They may share parts of the code base, they may 
> re-use the protocols but it is not usefull to call everything a
> directory just because as Dilbert and Wally said 'we always build 
> a directory', 'we like directories'[1].
	[Alan Lloyd]  Never said that a directory does everything. Just
said that a PKI is a Directory enabled function, so that distribution,
scaleability and a common information service paradigm can be applied -
rather that bespoke protocols and mechanisms that seem to provide
mystery and misery and limited functionality.
	High functionality distributed infrastructure provides a
capability eg a telephone service or a directory service. Why not use it
rather than try to re-invent it?

	regards alan

> 		Phill
> 
> [1] I know it was actually a database.

---

From: [email-masked]
Date: Fri, 30 Oct 1998 13:41:01 -0000

I had taken it for granted that nobody would trust a self signed
certificate without having validated it by either a secure distribution
mechanism or verification of the hash from a trusted source.

I am pleased to say we are in total agreement.

Graham Bland

> From: Al Arsenault [mailto:[email-masked]]
> Sent: 30 October 1998 13:29
> To: [email-masked]; [email-masked]
> Since I agree with most of what Phill has to say on this 
> topic, I'll go against
> my better judgement and jump in here.
> 
> If I'm understanding this correctly, the attack of concern is 
> as follows:
> Nothing today stops me from cobbling together my own 
> certificate-generating and
> -signing software, and then generating a self-signed 
> certificate for user "US
> Verisign Primary Class 3 Public Certificate Authority" (or 
> whatever the magic
> string is that will exactly match what VeriSign uses).  This 
> new certificate
> will use the public key corresponding to a private key that I 
> know, rather than
> the one that VeriSign actually uses.  (This ignores the 
> scenario described by
> Graham, in which I've managed to obtain VeriSign's private key.)
> 
> Given this, can I get you, the unsuspecting user, to use MY 
> certificate (and
> any user certificates I then issue with it) instead of the 
> real one?  After
> all, once you've retrieved the certificate, the DN or 
> subjectAltName field will
> LOOK "right" to you, if you bother to check it.  The argument 
> has been that
> given an insecure, spoofable, distribution mechanism, I might 
> be able to fool
> you into using the wrong "VeriSign certificate".  If, for 
> example, I can spoof
> DNS and make you think that the IP address corresponding to 
> "VeriSign.com" is,
> say, 130.85.1.3,  and I control that machine (note: I don't 
> :-) then you'll go
> there for the "real certificate" and I've got you.  So, to 
> counter that, you
> need a "secure" distribution mechanism.
> 
> I frankly don't buy that argument, though.  What is required 
> in a PKI is that I
> somehow securely obtain the certificate/public key of a CA 
> that I have chosen
> to trust - normally, that's the one that issued my 
> certificate.  If this first
> step is broken - I'm fooled into accepting a certificate from 
> a phony CA, or
> whatever - then the security of the entire PKI is shot, and 
> no X.500 directory
> or other mechanism is going to help.  Once I have that public 
> key, though, I
> can detect any faked certificates based on the trust my CA 
> has.  My CA will
> have cross-certified with the REAL VeriSign Class 3 primary 
> CA (when WHAT
> freezes over? :-)   Thus, even if I get your phony VeriSign 
> cert that looks to
> be the right one based on the name, I can't build a 
> certification path back to
> a node I trust, because my CA or whomever else I trust hasn't 
> signed your
> spoof.  I'm protected against your spoof by the certificates 
> and CRLs, not the
> distribution mechanism.
> 
> (Of course, if you can trick the people I trust - my CA, for 
> example - into
> cross-certifying your fake certificate, I'm hosed.  But that 
> just means that I
> trusted some incompetent fool I shouldn't have.  A '"secure" 
> X.500 directory
> won't help at all once my CA has botched it.)
> 
> 
> 
> 
> 
>                                         Al Arsenault
> 
> --- standard disclaimer - my own opinions; don't reflect 
> those of my employer
> or of any other organization to which I may have a 
> relationship; etc., etc., ad
> infinitum, ad nauseum
> 
> 
> 
>         
> 
> At 11:06 AM 10/30/98 +0000, [email-masked] wrote: 
> 
> >
> > How are you going to do all this ? 
> >
> > The only way I can think of is that either you know or have 
> compromised the
> > CA private keys. 
> > If you know the private signature keys then all information 
> is compromised
> > regardless of source. 
> > If you don't how will you construct the Certificates, CRLs, 
> OCSP responses
> > etc. 
> >
> > This is an attack based on the compromise of the CA, not 
> the security of DNS
> > OCSP etc. 
> >
> > Graham Bland 
> >
> > > From: Ron Ramsay
> [<mailto:[email-masked]>mailto:Ron.Ramsay@Ope
> nDirectory.c
> > om.au] 
> > > Sent: 30 October 1998 02:42 
> > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd 
> > > Cc: Stephen Kent; [email-masked]; Rick Harvey 
> > > Phillip, 
> > > Thanks again. 
> > > Let me pick up on two points. 
> > > 
> > > Firsly, DNS security. If I can spoof DNS (which doesn't look 
> > > to hard) I 
> > > can provide the address of my server in any of the records of 
> > > interest. 
> > > A request for your certificate will come to my server and 
> I will send 
> > > back the certificate that I have constructed for you. If 
> you ask for a 
> > > CRL I will give you one that doesn't name this 
> certificate. If you 
> > > choose to use a validation service like OCSP that's OK 
> because I'll 
> > > return 'valid' for your/my certificate. 
> > > 
> > > Denial of service is the best bad behaviour you can 
> expect. Positively 
> > > helpful service is much worse! 
> > > 
> > > Secondly, you're going to send your certificate with the 
> > > message. Why, I 
> > > shall do that too! So I'm still you! 
> > > 
> > > It is interesting you say that the worst that can happen 
> is that you 
> > > receive a certificate you don't trust. How do you know 
> you don't trust 
> > > it? I should think if you already know what certificates you 
> > > trust then 
> > > you don't need PKI at all! 
> > > 
> > > Ron. 
> > > > Sent:       Friday, October 30, 1998 2:38 AM 
> > > > To:Ron Ramsay; Alan Lloyd 
> > > > Cc:Stephen Kent; [email-masked]; Rick Harvey 
> > > > > Phillip, 
> > > > > Thanks for taking time to develop the example. 
> > > > > 
> > > > > Two issues: 
> > > > > 
> > > > > 1. Surely DNS is not secure? 
> > > > 
> > > > Define secure? With the exception of a denial of 
> service attack DNS 
> > > > is 'secure enough' for this purpose since there is no 
> trust placed 
> > > > on the server. The origin of a signed message is 
> irrelevant. Only 
> > > > the signature is relevant. 
> > > > 
> > > > > 2. Your example seems to be based on encryption using 
> public keys. 
> > > > From 
> > > > > what I know of the public key system, it is not used for 
> > > encryption. 
> > > > 
> > > > 
> > > > I think you are confusing DNS security here with PKIX. 
> The two are 
> > > > very 
> > > > separate. 
> > > > 
> > > > If someone spoofed DNS the worst that would happen is 
> that I would 
> > > > recieve a certificate I didn't trust (and would ignore) or no 
> > > > certificate 
> > > > at all. 
> > > > 
> > > > >Its 
> > > > > purpose is authentication and integrity. To bend your 
> example, you 
> > > > will 
> > > > > be encrypting your message with your own private key. 
> How is an 
> > > > > addressee to verify it was you who sent the message 
> and that the 
> > > > message 
> > > > > was not modified? 
> > > > 
> > > > I send my signing certificate with the message. Or once the 
> > > > infrastructure 
> > > > is deployed the recipient could use the SRV pointer to locate a 
> > > > directory 
> > > > where a copy of the certificate was available. 
> > > > 
> > > >       Phill 
> > > 
> 
> 
> 
>

---

From: WHenry <[email-masked]>
Date: Fri, 30 Oct 1998 09:26:57 -0500

All:

 Al Arsenault said:

"What is required in a PKI is that I somehow securely obtain the
certificate/public key of a CA that I have chosen to trust - normally,
that's the one that issued my certificate.  If this first
step is broken - I'm fooled into accepting a certificate from a phony CA, or
whatever - then the security of the entire PKI is shot, and no X.500
directory
or other mechanism is going to help."

 I couldn't agree more! This is precisely the reason why CA certs that come
embedded in my browser are, from a trust standpoint, worthless.

 -Bill Henry

> From:	Al Arsenault [SMTP:[email-masked]]
> Sent:	Friday, October 30, 1998 8:29 AM
> Since I agree with most of what Phill has to say on this topic, I'll go
> against
> If I'm understanding this correctly, the attack of concern is as follows:
> -signing software, and then generating a self-signed certificate for user
> "US
> Verisign Primary Class 3 Public Certificate Authority" (or whatever the
> magic
> string is that will exactly match what VeriSign uses).  This new
> certificate
> will use the public key corresponding to a private key that I know, rather
> than
> the one that VeriSign actually uses.  (This ignores the scenario described
> by
> Given this, can I get you, the unsuspecting user, to use MY certificate
> (and
> any user certificates I then issue with it) instead of the real one?
> After
> all, once you've retrieved the certificate, the DN or subjectAltName field
> will
> LOOK "right" to you, if you bother to check it.  The argument has been
> that
> given an insecure, spoofable, distribution mechanism, I might be able to
> fool
> you into using the wrong "VeriSign certificate".  If, for example, I can
> spoof
> DNS and make you think that the IP address corresponding to "VeriSign.com"
> is,
> say, 130.85.1.3,  and I control that machine (note: I don't :-) then
> you'll go
> there for the "real certificate" and I've got you.  So, to counter that,
> you
> I frankly don't buy that argument, though.  What is required in a PKI is
> that I
> somehow securely obtain the certificate/public key of a CA that I have
> chosen
> to trust - normally, that's the one that issued my certificate.  If this
> first
> step is broken - I'm fooled into accepting a certificate from a phony CA,
> or
> whatever - then the security of the entire PKI is shot, and no X.500
> directory
> or other mechanism is going to help.  Once I have that public key, though,
> I
> can detect any faked certificates based on the trust my CA has.  My CA
> will
> have cross-certified with the REAL VeriSign Class 3 primary CA (when WHAT
> freezes over? :-)   Thus, even if I get your phony VeriSign cert that
> looks to
> be the right one based on the name, I can't build a certification path
> back to
> a node I trust, because my CA or whomever else I trust hasn't signed your
> spoof.  I'm protected against your spoof by the certificates and CRLs, not
> the
> distribution mechanism.
> 
> (Of course, if you can trick the people I trust - my CA, for example -
> into
> cross-certifying your fake certificate, I'm hosed.  But that just means
> that I
> trusted some incompetent fool I shouldn't have.  A '"secure" X.500
> directory
> --- standard disclaimer - my own opinions; don't reflect those of my
> employer
> or of any other organization to which I may have a relationship; etc.,
> etc., ad
> infinitum, ad nauseum
> 
> 
> 
>         
> 
> > The only way I can think of is that either you know or have compromised
> the
> > CA private keys. 
> > If you know the private signature keys then all information is
> compromised
> > regardless of source. 
> > If you don't how will you construct the Certificates, CRLs, OCSP
> responses
> > etc. 
> >
> > This is an attack based on the compromise of the CA, not the security of
> DNS
> > OCSP etc. 
> >
> > Graham Bland 
> >
> [<mailto:[email-masked]>mailto:[email-masked]
> > om.au] 
> > > A request for your certificate will come to my server and I will send 
> > > back the certificate that I have constructed for you. If you ask for a
> 
> > > CRL I will give you one that doesn't name this certificate. If you 
> > > choose to use a validation service like OCSP that's OK because I'll 
> > > Denial of service is the best bad behaviour you can expect. Positively
> 
> > > It is interesting you say that the worst that can happen is that you 
> > > receive a certificate you don't trust. How do you know you don't trust
> 
> > > > Define secure? With the exception of a denial of service attack DNS 
> > > > is 'secure enough' for this purpose since there is no trust placed 
> > > > on the server. The origin of a signed message is irrelevant. Only 
> > > > > 2. Your example seems to be based on encryption using public keys.
> 
> > > > From 
> > > > I think you are confusing DNS security here with PKIX. The two are 
> > > > very 
> > > > separate. 
> > > > 
> > > > If someone spoofed DNS the worst that would happen is that I would 
> > > > > purpose is authentication and integrity. To bend your example, you
> 
> > > > will 
> > > > > be encrypting your message with your own private key. How is an 
> > > > > addressee to verify it was you who sent the message and that the 
> > > > message 
> > > > > was not modified? 
> > > >

---

From: MHenry <[email-masked]>
Date: Fri, 30 Oct 1998 09:57:01 -0500

al,
interestingly enough, the largest base of existing
pki users (those that have browsers with a hard coded
certs at time of purchase) do, regularly, exactly what you take for
granted they would never do. 
semper fi,
mike henry

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, October 30, 1998 8:41 AM
> To:	[email-masked]; [email-masked]
> > From: Al Arsenault [ <mailto:[email-masked]>] 
> > [< <mailto:[email-masked]>> <mailto:Ron.Ramsay@Ope> 
> > nDirectory.c 
> > > om.au]

---

From: "Tolga Acar" <[email-masked]>
Date: Fri, 30 Oct 1998 10:25:55 -0700

>>> Michael Helm <[email-masked]> 10/30/98 10:05:09 >>>
>This is theoretically true, but then, aren't you setting yourself
>up for an attack based on a single (or small integer number) point 
>of failure?  For example maybe I could trick you into using 
>a bad certificate database (by breaking into a login of yours
>somewhere & trojanning your personal software) but I may not 

Violation of integrity on the victim's side.
if you ruin the baseline (integrity), and expect to be secure. can't do it.
besides, this will hurt that particular victim, not others.

>On the other hand, would price would we pay for this complexity?
>Would we somehown make operations more insecure and/or less reliable?

insecurity is coming from the lack of integrity, so called "less reliable".
you have to have them both: security and integrity. If one is missing, you can't have the other.

- Tolga