Subject: RE: Scale (and the SRV record)

From: Alan Lloyd <[email-masked]>
Date: Thu, 5 Nov 1998 09:31:16 +1100

Comments inline.

Perhaps the answer to most of this is to ask how PKI suppliers are
integrating their non directory solutions into organisations - without
causing yet more islands of services, information and higher operational
costs.

Or why they built X.509 without X.500. Thats a bit like using a data
structure from a database - without using the features of a database.

> -----Original Message-----
> From:	Graham Bland [SMTP:[email-masked]]
> Sent:	Friday, 30 October 1998 20:33
> To:	'Alan Lloyd'; [email-masked]'
> Subject:	RE: Scale (and the SRV record)
> 
> 
> 
> Large portions of original message deleted for readability, relevant
> sections only maintained with comments in line. 
> Graham Bland 
> > -----Original Message----- 
> > From: Alan Lloyd [ mailto:[email-masked] ] 
> > Sent: 29 October 1998 21:37 
> > To: 'Bill Burr'; Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> 
> > [email-masked] 
> > Subject: RE: Scale (and the SRV record) 
> ...deleted 
> > > I have been saying for some time that don't know of anybody who
> has 
> > > built 
> > > an X.500 directory of a size that convinces me that it is a viable
> 
> > > technology to base a US national PKI, or even a US Federal 
> > > government-wide 
> > > PKI on. I keep asking the question, where are the really big 
> > > distributed 
> > > X.500 directories? Particularly multivendor directories.  
> > But I don't 
> > > seem 
> > > to get any answers.  What I hear are horror stories about the 
> > > difficulties 
> > > of getting any two X.500 products to work together. 
> >       [Alan Lloyd]  
> >       No horror stories from us. 20 million entries, 1000s of
> searches 
> > a second, distributed, multi master, etc We have very scaleable, 
> > distributed technology - that also integrates LDAP servers, etc We
> are 
> > very busy deploying X.500 into major corporate infrastructures who
> are 
> > following the themes I described. Including those in the US. 
> > Please read 
> > our WEB site. "Uses of Directory Services" 
> > 
> Can I access these directories or are they private islands.  If they
> are private islands then they might as well not exist.
	[Alan Lloyd]  
	Thats a narrow view. All systems today are islands in one shape
or another. Thats no reason to say that X.500 or directory systems dont
work. They are - in our books - being applied to many organisations to
consolidate their information systems, provide a direction to having a
single logon and a singlr mail box. And on this we appli PKI
functionality.

	Are you saying the above direction is not happening or you dont
agree with it.

> > >   If the X.500 directory industry builds products that
> interoperate 
> > > and scale 
> > > well, it has done a really bad job of getting the word out.  
> >       [Alan Lloyd]  
> >       My view here is that the LDAP hype has done a really good job
> of 
> > damaging X.500. However, now the LDAP hype has dissipated and
> reality 
> > has set in we are left with a protocol that can only ACCESS a 
> > directory 
> > service ? is twice as big as DAP and has half the functionality. In 
> > addition, getting LDAP only solutions is proving to many that X.500
> is 
> > the way to go because of LDAPs NO distribution and a model 
> > that demands 
> > Replicate everything to everywhere. LDAP has high operational 
> > costs and 
> > gets to a point where it is unworkable. 
> >       So LDAP accessed X.500 in my book is the way to go and is
> being 
> > deployed globally. 
> I think you meant to say DAP accessed X.500 from the flow of the text 
> > 
> > >  Until now, I have also been saying, does anybody have a
> believable 
> > > alternative to the mythological, pervasive X.500 directory
> service? 
> > > It 
> > > seemed almost a rhetorical question.  But I think perhaps Phill
> has 
> > > outlined an alternative, that looks like it probably ought to
> work, 
> > > and is 
> > > based on something, DNS, that we know works well, scales well, and
> 
> > > exists 
> > > now. Moreover, we should be able to create the service we need 
> > > incrementally, by just by adding servers as we need them, one at 
> a 
> > > time. 
> > > And, If I understand the proposal, all we have to do is 
> > agree on some 
> > > simple naming conventions. 
> >       [Alan Lloyd]  I am not against alternative proposals - its all
> a 
> > question of how much effort and implementation goes behind it.
> Phills 
> > solution has to be backed by all the DNS and PKI suppliers on this 
> > planet and DNS then has to become secure - with signed operations, 
> > mutual authentication, access controls, real life naming, and scale
> a 
> > lot better and of course be easy to manage and follow Object
> Oriented 
> > design. (does this mean turning DNS into X.500?) I would vote 
> > for that - 
> > thats more X.500! 
> Why would DNS need to be more secure with signed operations mutual
> authentication etc. Certificates and CRLs are signed objects and their
> security is inherent.   Ignoring denial of service I cannot see any
> attacks from an insecure distribution method.  The whole point of the
> distribution method is that I have no trust relationship with it and
> have no need of a trust relationship be it email, X.500 or anything
> else.
	[Alan Lloyd]  
	I did not raise DNS as being a directory service as it has about
5% of the functionality of X.500. Its just that if DNS wants to become a
directory service - then its fuctionality will end up as X.500 no doubt.

> How is it relevant if DNS follows OO design, why should it.  While I
> agree that OO design and methods have many advantages the relevant
> questions are does it work and how much will it cost, not what its
> internal structure is.
> What is the problem with the scalability of DNS (How many users does
> it support now ?) 
> X.500 is easy to manage? later you say "But LDAP did prove that
> directorys are difficult 
>  and complex and X.500 got most things right."  
	[Alan Lloyd]  Any distributed information system that supports a
major organisation for business is difficult to manage - thats obvious -
it has nothing to do with the technology in most part. Its to do with
operational dynamics, wear and tear and scaling up with usually less
resources.

	In addition we are using our X.500 to back end DNS/DHCP and
RADIUS servers  for large ISPs - now theres a trend eh.

	regards alan

> Graham Bland

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 17:15:06 -0500

Rich,

>>Denial of service is allways an issue; it is a concern in
>>all of the possible repository alternatives.
>
>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...

True, but note that in many applications one can exchange CRLs; it is not
always necessary to retrieve them from ANY repository.  In that case, the
worst that happens is that one's peers sends a CRL that should be currently
valid, but for which an unscheduled successor has been issued.  In many
applications, and with frequent CRL (e.g., daily) issuance, this is a
reasonable risk to accept.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 17:24:08 -0500

Alan,

>I think of CAs as functions and certs that are applied to real life
>entities which are represented as attributes of objects in a business
>level directory system.
>
>Bashing DNS records into certs and CA operations and validation paths
>just complicates life with a higher operational costs and does not use
>the utility of distributed information infrastructures. Its like
>configuring every phone with every one elses phone number. When in fact
>we use the distributed telephone network and its directory system to
>avoid that.
>

In the US few people I know regularly use directory assistance; they most
often use local caches (address books) and hard copy phone directories.
So, this analogy seems a bit questionable.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 17:12:31 -0500

Lynn,

>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 disagree wuth this last observation.  As I mentioned in a recent posting,
browsers do check for a match between the server URL and it's cert, which
is precisely an authentication function.

>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).

If you chosen the IDs in the client certs to match the account record keys,
the authentication capability of client certs would have been useful.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 17:29:21 -0500

Alan,

>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

Neither trust nor robustness is necessarily improved by introducing more
players into the cert validaton process.  Replicated copies of CRLs in a
variety of repositories are more robust than a single copy in one database,
all else being equal.  However, relying on a network of directories to
perform operations on which the security of a communication  depends, may
easily be less robust and less secure.  I am especially concerned about the
notion of a thin client relying on servers to validate certs.

Anyway, didn't thin clients become less of a goal with the demise of netPCs
:-)?  All of the software on my desktop and laptop machines is getting
bigger each year, not smaller.

Steve

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 5 Nov 1998 16:38:07 +1100

Thanks Steve Comments in line.

> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Thursday, 5 November 1998 9:29
> To:	Alan Lloyd
> Cc:	'Paul Koning'; Alan Lloyd; [email-masked]
> all else being equal. 
	[Alan Lloyd]  The issue raised is of inconsistency in
master/replica CRLs and not being able to select the master with LDAP.
ie. the master may have a new CRL, the replica has not seen any of this
yet.

>   However, relying on a network of directories to
	[Alan Lloyd]  Concern is good. But some customers want them. At
the opposite end is the worst evil. 10 or so complex validation path
processes all tied to different CA or service vendors.

> bigger each year, not smaller.
	[Alan Lloyd]  Yes - but its the dependency issue. We dont want
CA company X to change a few validation path conditions or add a cros
cert and all the clients to be updated - do we?
	regards alan

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 6 Nov 1998 03:16:15 (NZDT)

Alan Lloyd <[email-masked]> writes:
 
>causing yet more islands of services, information and higher operational costs.
>
 
It's interesting that you mention the word "database" here in relation to 
X.509.  About six months ago I did an informal poll of users of my crypto 
toolkit to see what they were doing for certificate storage.  The toolkit
supports everything from primitive flat files and smart cards through all 
manner of RDBMS's and LDAP.  The almost universal solution to certificate 
storage needs was MS Access.  Everything else may as well not have existed.
 
Some comments on this:
 
This is for the unwashed masses who have to work with crypto (developers and 
implementors), not cryptographers.  All they wanted was a way to map an email 
address/server name to a key.  Heirarchical storage and free-form attributes 
and fuzzy dice and chrome tailfins were nothing but a nuisance to work around 
(so far I've identified one single user of an LDAP directory, and AFAIK he was 
only playing with it on a Unix box).  Dunno how many users there are in total, 
but at one point it was averaging 200 downloads a week.  Most of the users in 
the informal poll used Win32 and VB (spit), followed by Delphi/C/C++.
 
Although I don't know whether I want to laugh or cry at the use of Access, it 
does make sense: It's either pre-installed on the most widely-used platform on 
the planet or can be trivially added via the MS Jet engine[0], and there are a 
huge number of third-party tools available to use with it.
                                                          
[Purely in order to forestall the inevitable comments about "it won't scale 
 and there's no replication and it's not distributed and you can't get it with 
 fuzzy dice and ...", I'll reiterate what I said above: The users don't care.  
 Given the choice, they've gone for the easy-to-use, widely-available solution 
 which does the job.  I'll continue to support whatever's around and let the
 users make their own choice, but when it comes to key storage mechanisms they 
 sure aren't choosing X.500 or anything derived from it]
 
Peter.
 
[0] So-called because it both sucks and blows.

---

From: James M Hayes <[email-masked]>
Date: Thu, 5 Nov 1998 09:03:31 -0500

> JAMES M. HAYES, Capt, USAF
> Information Operations Research Manager
> The Office of INFOSEC Research and Technology
> National Security Agency
> 301-688-0847

-----Original Message-----
From:	EKR [SMTP:[email-masked]]
Sent:	Thursday, November 05, 1998 7:58 AM
To:	[email-masked]
Cc:	Stephen Kent; [email-masked]
Subject:	Re: Scale (and the SRV record)

[email-masked] writes:
> you must live on another part of the internet than i do.
> 
> I've seen clients fail SSL connection because the supplied server
> certificate wasn't manufactored by a CA in the included browswer list.
Of course. 

> I've yet to see a client fail an SSL connection because it was the first
> time it had ever encountered a particular server certificate ... had
> absolutely no record of the particular server certificate or prior
> knowledge of the particular server (the only characteristic for succesful
> SSL seems to be that the server's certificate was manufactored by CA known
> in the browser list).
Lynn, this simply isn't correct.

There are two major checks for a server certificate:
1. That it's descended from a trust point.
2. That it contain a name that corresponds to the URL that the
client thinks it's dereferencing. 

In terms of browsers, I would add the following to keep things in perspective:

1. Trust - Trust management is still an issue within the browser environment.  The user doesn't really know which authority is actually authorized to certify a certificate for a given server (certificate masquerade). For example, if Bob connected to a web site outside of his company and ended up with a server certificate signed by his company CA (in his browser), he may actually think that this is okay.   His company is suppose to provide the security to entities outside of his company.  Chances are that Bob will just look for the "secure" icon and not ever see that his CA signed the certificate.
2. Education - Users do not actually know how to go about verifying the authenticity of the CAs in their browsers or where to go to get the actual information.   
3. PKIX Nemesis - Real-time revocation status is still an issue.  

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

> JAMES M. HAYES, Capt, USAF
> Information Operations Research Manager
> The Office of INFOSEC Research and Technology
> National Security Agency
> 301-688-0847

---

From: [email-masked]
Date: Thu, 5 Nov 1998 09:43:10 -0500

E-mail addresses in Certificates sounds good, but please do not put them
into the Certificate's subject.

A Certificate's subject is a singular Name. A Name is a CHOICE of one type:
RDNSequence.

S/MIME embeds two names into subject: a distinguished name and an e-mail
address. Embedding multiple names into subject works OK for S/MIME, but does
not scale. Just imagine 20 or 30 names.

Should a Certificate contain multiple names? Why not!

One solution is to add a CHOICE to Name each time a new application naming
system is defined. This system is pretty efficient and works in a closed
system. In an open system, this solution does not scale very well and
requires everyone to update their systems.

Another solution is to leave Name alone (RDNSequence remains the common
"handle") and let application's define Extension(s) for their naming
systems. For example, Alice might choose to integrate all her names (and
identifiers) into one monolithic Certificate (e.g., social security number,
credit card account number, checking account number, email address, etc.),
while Bob might choose to use separate certificates.

Frank Balluffi
CertCo

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, November 04, 1998 5:18 PM
To: Phillip M Hallam-Baker
Cc: [email-masked]
Subject: Re: Scale (and the SRV record)

Phill,

Although I'm very late getting into this particular debate due to being
away on travel (mostly not Internet connected) for almost 2 weeks, I concur
with several of the themes of your observations, although I might prefer
storing certs and CRLs in the DNS per se, rather than using DNS records as
pointers to othyer repositories.

The DNS is the only robust, distributed directory system the Internet has.
That makes it attractive for two things: storing data, such as certs and
CRLs, and for its naming tree.  Note that anytime we use a name in a cert
that is not exactly the same as the name we use in an application, we are
required to perform a mapping between two name spaces, and that introduces
another database which imposes significant additional management overhead
and another place to make errors with adverse security implications.  So,
for example, for IPsec, i really want certs with DNS names and IP
addresses, since these are the native name forms that the applications
employ and upon which access control decisions are made.  For SSL, browsers
check a DNS name in a certificate against the corresponding portion of the
URL, and ignore the rest of the DN in the subject field.  For e-mail the
case may not be so strong, since people may mentally map identifies
irrespective of e-mail addresses, but even there I worry that cognitive
overload can eaisly set in and cause people to make perception mistakes.
(If one has an S/MIME system that automatically checks for the
correspondence between the "from" address and the sender's DN from his
cert, instead of presenting the subject DN from the certificate, then the
above arguments apply.) So, here too, I really prefer certs with e-mail
addresses, which is a change from a stance I adopted years ago when I wrote
RFC 1422.

Steve

---

From: [email-masked]
Date: Thu, 5 Nov 1998 10:13:09 -0800

i agree that the SSL specification works as you described ... including the
URL check.

---

From: [email-masked]
Date: Thu, 5 Nov 1998 11:40:05 -0800

x9.59 attacked different parts of the problem .... in the case of the
common useage of SSL for the buy button .... X9.59 was designed to insure
the integrity of the financial infrastructure using only digital signature
for authentication and not requiring any encryption.

... i.e. while the SSL URL (& certificate) check is interesting ... the
common useage for SSL is encryption connection between the client and
browser to protect something.

x9.59 insures the integrity of the financial infrastructure w/o requiring
SSL/encryption for protection.
it has the advantage of doing end-to-end integrity eliminating a lot of the
opportunity for fraud (security 101 teaches that any time you seperate
authentication and authorization .... holes/opportunities for fraud open
up). x9.59 also has the advantage that it works for all electronic
environments (not simply limited to internet).

one approach to the area that SSL URL checking addresses would be having
ISP boundary routers doing address filtering on origin address of incoming
packets. this can reduce many of the spoofing related attacks (not just the
one caught by the SSL URL checking) and provide some evidence trail back to
attack origins.  other is general upgrade of authentication procedures to
public key ... both at boundary points and infrastructure operations (like
DNS).

i believe that public key infrastructure for authentication is good thing.
I believe that basic justification for certificates is to provide
authentication attribute binding for offline operations; raising offline
integrity closer to what online account-based operations have. introducing
certificates into an online account-based operations can result in lowering
the integrity ....

i.e. online account-based operations with public key authentication (and no
certificates) can have extremely high integrity. The incremental increase
in integrity offered by certificates would be nominal and typically more
than offset by the decrease in integrity created by increased complexity
(i.e. complexity all by itself creates an integrity issue).  The addition
of certificate to an AADS PKI .... would represent an integrity issue ....
even if the certificate was totally ignored ... since, at the very least,
the level of complexity is raised. To the extent that the certificate is
not ignored and represents something in the process .... it further
increases complexity (having to check the CA-signing key on the certificate
or checking a CRL represents complexity & integrity issues)..... and to
actually represent a net increase in integrity there would have to some
significant reduction in the account-based operations (like eliminating the
account-related operations totally). A troublesome area for the elimination
of the account-based operations are real-time attributes and/or sensitive
attributes that raise privacy issues.

A pervasive example in the internet world are ISP account based operations
for internet service. There are real-time issues like has the account been
canceled and/or suspended (for say not paying the bill). One might consider
pre-paid accounts (like pre-paid phone cards) ... with a certificate that
was good for the pre-paid period. However, accounts still might be
cancelled ... which would need reference to the account record. As soon as
I have to touch an account record .... then having the public key bound in
the account record is simpler and higher integrity than processing
information both in the account record and in a certificate (along with all
the baggage of validating the certificate & certificate infrastructure).

---

From: [email-masked]
Date: Fri, 6 Nov 1998 08:24:51 -0800

.... and that a spoofer can't obtain the same thumbnail/phrase  in their
certificate extension ...  requiring all CAs (typically valid for the
browser community) to reference a central registry of thumbnail/phrases
(ala copyright or service mark office).

X9.59 standard proposed exactly that for merchant web servers certificates
selling on the internet. There was split between the banks that were
interested in being the CA for such certificates on the part of their
merchants and banks that proposing bank AADS server (did client browser
cross-check service mark with what was in the merchant's certificate
extension ... or did client browser do a online reference to well-know bank
web server checking the service mark, merchant's URL ... and was the bank
still financial responsible party for the merchant). A side issue of
specifying such a thumbnail service mark in a certificate was that X9.59 is
suppose to be for all account-based payments in all electronic environments
(and at least one such electronic environment is point-of-sale where
neither browswer nor certificates are available).

---

From: [email-masked]
Date: Sat, 7 Nov 1998 15:05:15 -0800

,,,, relying party certificates was something that a european financial
institution brought up at NISSC during e-commerce session (issues addressed
were business issues associated  privacy and liability .... wasn't
technical issue regarding size or bandwidth, etc). In discussions
afterwards .... the processing flow is almost identical to X9.59 and AADS
.... the difference is that one of these certificates flows along with the
transaction and gets to the relying party .... where (if they hadn't
noticed) they had the original (i.e. client was appending a copy of the
certificate to the end of of every transaction sent to the relying pary
.... which had the original ... easy to show it was superfulous).

nissc web site is
                   http://csrc.nist.gov/nissc/1998/

but there is nothing there on that particular discussion.

They also mentioned an evidence server to validate parts of the
infrastructure. That part is also nearly identical to part of an overall
infrastructure that i've been presenting for last 8-9 months (which have
had included europeans in the audience).

---

From: Russ Housley <[email-masked]>
Date: Mon, 09 Nov 1998 12:41:02 -0500

PKIX Part 1 is quite clear on this topic.  It recommends that e-mail
addresses belong in subjectAltName.  However, it warns implementors that
PKCS#9 emailAddress attributes are used by S/MIME v2 as part of the subject
Distringuished Name.

Russ

---

From: Alan Lloyd <[email-masked]>
Date: Tue, 17 Nov 1998 10:31:24 +1100

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, 6 November 1998 14:16
> To:	[email-masked]; [email-masked]
	[Alan Lloyd]  snip

>  fuzzy dice and ...", I'll reiterate what I said above: The users
	[Alan Lloyd]  Its always this line that gets me when its used to
negate the engineering issues of dealing with information (or any)
infrastructure for large scale systems.

	Users of the telephone service dont care about undersea cables,
sats, switches, plesiochronous digital hierarchies, etc But the
engineering and the people that biuld the system do.

	Yes Use what you want.

	I work with many large customers that do care about their
infrastructures and how they deal with services, information and
certificates - and naturally because I am involved with them its
distributed X.500 (with LDAP access).

>  which does the job. 
	[Alan Lloyd]  These arenot engineering terms - the phone system
or building a large corporate information system is NOT and never will
be a product that is easy to apply - if you want it easy to use) eg
phone systems and what is the job here?

>  I'll continue to support whatever's around and let the
	[Alan Lloyd]  Thats a view - but it depend what you are building
- islands of information for islands of users with simple products or
scaleable, distributed, coherent, secure, large scale, service based
information infrastructures.

	regards alan