Subject: OCSP Service Locator and RFC2459's Authority Information Access
From: Rich Salz <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sun, 28 Feb 1999 12:57:44 -0500 (EST)

Is there any reason to use the OCSP "Service Locator", (Draft 7,
Section 5.4.6) instead of defining an Authority Information Access
AccessDescription for the OCSP service (RFC2459, Section 4.2.2.1)?
Is it just a case of parallel efforts duplicating work, or is there
a subtlety I'm missing?

Replies to me will be summarized for the list.
	/r$

Date: Sat, 27 Feb 1999 16:51:59 +0100
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Qualified Certificates draft - Country name
Cc: <[email-masked]>, ietf-pkix <[email-masked]>, Stephen Kent <[email-masked]>
Sender: [email-masked]

All,

I would like to clarify the scope of the draft.

It is NOT the intent of the draft to specify how a meaningful identity
should be composed.

Period.

It is though the intent of the draft to specify a well defined structure
within which any useful identity information could be expressed according
to the issuers and the key holders preferences.

The qualified certificate has two different compartments for subject
identity information.
1) The subject field
2) The PersonalData field (stored in subjextAltName extension as a new
information construct stored under otherNames.)

The main purpose of the subject field is to hold a "technical name"
fulfilling all technical requirements that might be imposed on the
certificate with respect to presence of a unique X.500 type of name. This
name may or may not be suitable as the subjects preferred legal name
(unmistakable identity).

The optional PersonalData field has the main purpose of providing means to
express a legal name in cases where the subject field is not sufficient for
this purpose. The advantage of this approach is to free the subject field
of strange attributes and semantics necessary for expressing the legal name.

So, this debate is about whether the countryName attribute in the subject
field (the technical name)shall be mandatory or optional. Keep in mind that
any country information as part of the legal name can be handled in the
PersonalData field regardless of what is done in the subject field.

This gives the conclusion that what we decide in the subject field (as
mandatory or not), should only be based on technical requirements from
X.500 directory systems and similar, not from requirements on legal name
forming.

Based on this presumption I would appreciate a consensus in this subject.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

Date: Fri, 26 Feb 1999 16:50:39 -0500
To: [email-masked], [email-masked]
From: Tim Polk <[email-masked]>
Subject: NIST Reference Implementation available
Sender: [email-masked]

Today, NIST announced the availability of reference implementation PKI
components.  I have appended the press release below, but thought this
group would be interested in some additional technical details.

First, though, the distribution details:

The reference implementation is FREE, and is available upon request via the
following URL: 

	http://csrc.nist.gov/pki/mispc/refimp/cdj2.htm

NIST has obtained an export license; exports are approved worldwide except
to India, Pakistan, Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria.
Upon request, we will ship you a CD-ROM.  We do *not* support on-line
download; it is difficult to enforce the restrictions and complicates
reporting.

Technical Info:

The reference implementation components conform to NIST Special Publication
800-15, the "Minimum Interoperability Specification for PKI Components,
Version 1" (MISPC).  The MISPC is a fairly comprehensive PKI specification
based on X.509/RFC 2459, CMP, and CRMF.  It supports a PKI architecture
that includes CAs, RAs, clients, and an LDAP certificate repository.  It
defines transactions to obtain and revoke certificates, but is limited to
digital signatures.

NIST developed this specification with a number of industry partners under
Cooperative Research and Development Agreements (CRADAs).  (They are listed
below in the press release.)  The MISPC is more or less a subset of RFC
2459, CMP, and CRMF.  It provides profiles of certificates and CRLs.
Unlike RFC 2459, the MISPC requires DNs for the subject of all
certificates.  The MISPC uses only eight of CMP's message types.  The MISPC
supports RSA, DSA and ECDSA public keys and and signatures; SHA-1 is the
only hash algorithm.

Additional information regarding this specification, and the MISPC itself,
may be obtained at the URL: http://csrc.nist.gov/pki/mispc

The reference implementation is a laboratory tool and a proof-of-concept.
It is intended to help developers build interoperable products.  This is
not a production system, and the client is not linked to *any* of the
standard tools. (That is, there are no plug-ins for anything!)  We provide
a single test application that generates and verifies signatures on files.

The reference implementation is software for Windows 95/98/NT systems, and
is provided as both source and executables.  The cryptographic module is
supplied as executable only, and includes DSA, SHA-1, and DES.  You will
need to provide an LDAP directory (we've tested Netscape, Microsoft, and
ICL), an SMTP/Pop3 email server, and a TCP/IP network.  At a minimum, you
will need two computers - the CA and RA must run on different physical
systems.

The software was developed by Cygnacom Solutions under contract to NIST.
The source code is C++ and works really nicely with Visual Studio 6.0.  (We
have ported some code to Borland successfully.)  I think that will answer
the usual questions.  Additional information is available at 
	http://csrc.nist.gov/pki/mispc/refimp/referenc.htm
or by sending me email.

Thanks,

Tim Polk

P.S.  I will *not* be distributing copies at the Minneapolis IETF.  It
makes export control reporting far too difficult.  I recognize this would
reduce international mail delays, but the jewel case is clearly marked as
"subject to U.S. Government Export Controls".  Mail is really the best
solution.

-------------- NIST Press Release ------------------

FOR IMMEDIATE RELEASE:			Contact:   Philip Bulman		
Feb. 25, 1999						     (301) 975-5661		   
           	                           [email-masked] 	

      TN-6209			

NIST RELEASES SOFTWARE TO PROMOTE SECURE E-COMMERCE PRODUCTS

The National Institute of Standards and Technology’s Information Technology
Laboratory today released software to assist industry in building more
secure systems to promote electronic commerce.

Vendors of products can use the NIST software to help ensure that their
product offerings can work with those of other firms. Such
"interoperability" will provide customers greater choice and flexibility in
selecting secure products. Interoperability is also critical to promote
widespread availability of security features to support secure on-line
transactions.

The software can be used by industry vendors to ensure the interoperability
of their products implementing advanced "public key infrastructure" (PKI)
technology. This technology provides a strong means to support electronic
business transactions over the Internet.

"The release of this software marks an important advance in PKI technology.
 Now product developers can easily test their products and systems to
ensure interoperability with other systems," said Donna Dodson, who heads
the NIST Security Technology Group.

 NIST’s new software is a reference implementation of PKI components
conforming to the Minimum Interoperability Specification for PKI
Components, Version 1 (MISPC V1). It is available in two forms:
ready-to-run executables for Windows 95(TM) systems and source code.

Santosh Chokhani, president of Cygnacom Solutions, notes the project has
already had an impact. "This project helped us validate the MISPC and
supporting standards." Cygnacom Solutions developed the reference
implementation under contract for NIST.

The MISPC is an interface specification for PKI components based upon
emerging international standards. MISPC V1 identifies a small set of
features from these specifications as the minimum feature set for
interoperability for PKI components. The specification’s certificate format
conforms to the International Organization for
Standardization/International Telecommunications Union X.509 standard and
the Internet Engineering Task Force’s Internet X.509 Certificate and
Certificate Revocation List (CRL) Profile. Transactions are based on the
IETF’s Certificate Management Protocol and use the Lightweight Directory
Access Protocol (LDAP) to distribute certificates and CRLs.

This reference implementation is designed as a proof-of-concept to help
product developers and researchers. The implementation is a laboratory
tool, permitting researchers to become familiar with PKI transactions and
components without significant investment. The software is a concrete
demonstration of the functionality described in the MISPC, V1. Finally, it
provides a baseline for interoperability testing of PKI components. A
developer may substitute locally developed components for components in the
reference implementation for testing.

NIST’s software includes implementations of three PKI components: a
Certification Authority (CA), an Organizational Registration Authority
(ORA), and a PKI client. The program is available in executable form for
Windows 95Ô systems; source code for PKI operations is available as well.
With an LDAP directory and an electronic mail system, these components can
issue, revoke and retrieve public key certificates.  The reference
implementation enacts several scenarios for certificate issuance. Clients
and ORAs may request certificates. Both clients and ORAs may request
certificate revocation. The CA distributes revocation information by
issuing X.509 CRLs.  Electronic mail transports the requests and responses.
Clients and ORAs retrieve certificates and CRLs using LDAP.

NIST’s Information Technology Laboratory developed the MISPC V1 with 10
industry partners under the auspices of cooperative research and
development agreements (CRADAs). The 10 partners were AT&T Corp., BBN (now
part of GTE), Certicom Corp., Cylink Corp., Dyncorp Information &
Engineering Technology Inc., Northern Telecom (now Entrust Technologies
Inc.), IRE, Motorola Inc., SPYRUS and VeriSign Inc. NIST is developing an
enhanced specification, version 2, with 16 industry partners: AT&T Corp.,
CertCo, Certicom Corp., Cylink Corp., Digital Signature Trust Co., Dyncorp
Information & Engineering Technology Inc., Entrust Technologies Inc.,
Frontier Technologies Corp., GTE, ID Certify, Mastercard International,
Microsoft Corp., Motorola Inc., SPYRUS, VeriSign Inc. and Visa
International. The MISPC V2 will include new transactions to support
issuing public key certificates for key management.

 The software is available free of charge to anyone in the United States
and most other countries.

To request the reference implementation or obtain information on the MISPC,
please use the following URL: http://csrc.nist.gov/pki/mispc.
As a non-regulatory agency of the U.S. Department of Commerce’s Technology
Administration, NIST promotes economic growth by working with industry to
develop and apply technology, measurements and standards through four
partnerships: the Measurement and Standards Laboratories, the Advanced
Technology Program, the Manufacturing Extension Partnership and the
Baldrige National Quality Program. 
-30-
News and general information on the National Institute of Standards and
Technology are available on the World Wide Web at http://www.nist.gov.		

Date: Thu, 25 Feb 1999 15:21:59 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: A web of directories
Sender: [email-masked]

Hannu,

I agree.  And just because you use one or more e-mail providers doesn't 
necessarily that they provide directory services.

Regardless of which e-mail (or sneaker-net mail) provider is used, you 
would like to be able to point to at least one directory, no matter where 
it resides or who it is affiliated with.

I agree with Steve that the Authority Information Access extension could 
be used for this purpose, although the wording at present suggests that it 
is associated with the Issuer, with no way to look up something associated 
with the Subject.  I assume that could be fixed, if necessary.

(So if I receive a signature-only certificate from someone via S/MIME, 
I still don't know and can't find an encryption key for that user in order to 
respond to him.  That is, unless I look up the Subject's certificate by 
Issuer and serial number and then prowl around in the CA's directory. But 
this implies that the CA is obligated to maintain a directory containing 
all of the Subject certificates, and the CA might not want to do that
or might charge too much.)

I'd still like to find a way of associating this information with the DN itself, so 
it would not require access to the certificate, which may be what we are 
trying to find.

It could easily be done for a single LDAP URL, but I don't want to necessarily 
restrict the directory reference to a single protocol, nor for that matter to a single 
directory supplier.

So I'm thinking about a "Generic Access Protocol" type of URL -- one that 
would identify the directory supplier by a DNS name. Then perhaps DNS could
 then advertise what protocols that directory supports, and what the port number 
is.

Because I don't want to force fit any particular protocol, this "GAP" URL would
consist of a header or prefix, followed by a string of DER-encoded RDNs, i.e.,
the "real" DN as God and X.500 intended. :-)  The client, e.g., a browser,
would be responsible for translating the "GAP" protocol into one that is supported
by that directory, and for example might translate from RDN into an LDAP 
string-type of URL.

I'm in the middle of several hot projects right now and don't have time to think 
about this much more at this time, so I would welcome anyone else trying to 
move the ball forward.

How real is the SRV capability of DNS, and how widely is it used?

Bob

>>> Hannu Nikkanen <[email-masked]> 02/24/99 11:05PM >>>
Larry, Steve, Bob

there may be more real life complications, I'm actually using four e-mail
accounts (wich have separate DNS servers):

- department level mainly in the office;
- corporation level (special services);
- local ISP from home,
- HotMail, when using somebody else's PC.

I have no strict role division between the addresses so my eMail address
may jump even from one continent to the other just depending the way, I get
connected. Correlating the eMail address with one or more (work, personal,
..) LDAP directories would be difficult.

Hannu

At 12:24 24.2.1999 -0500, Stephen Kent wrote:
>Larry,
>
>>For e-mail certificates, can't you use the domain from
>>the internet e-mail address to point you to a DNS server
>>And can't that in turn point you to the correct LDAP directory.
>
>One can certainly look up the user's DNS server based on e-mail address,
>but we don't have a record format in the DNS that points to an LDAP
>directory as a result.  One could define such a record type, though.
>
>Steve

Date: Thu, 25 Feb 1999 08:05:25 +0200
To: Stephen Kent <[email-masked]>, Larry Layten <[email-masked]>
From: Hannu Nikkanen <[email-masked]>
Subject: RE: A web of directories
Cc: Bob Jueneman <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Larry, Steve, Bob

there may be more real life complications, I'm actually using four e-mail
accounts (wich have separate DNS servers):

- department level mainly in the office;
- corporation level (special services);
- local ISP from home,
- HotMail, when using somebody else's PC.

I have no strict role division between the addresses so my eMail address
may jump even from one continent to the other just depending the way, I get
connected. Correlating the eMail address with one or more (work, personal,
...) LDAP directories would be difficult.

Hannu

At 12:24 24.2.1999 -0500, Stephen Kent wrote:
>Larry,
>
>>For e-mail certificates, can't you use the domain from
>>the internet e-mail address to point you to a DNS server
>>And can't that in turn point you to the correct LDAP directory.
>
>One can certainly look up the user's DNS server based on e-mail address,
>but we don't have a record format in the DNS that points to an LDAP
>directory as a result.  One could define such a record type, though.
>
>Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Bug in RFC 2459
Reply-To: [email-masked]
Date: Thu, 25 Feb 1999 17:13:31 (NZDT)
Sender: [email-masked]

>Looks like draft-ietf-pkix-ipki-part1-11.txt specifies DisplayText for the 
>organization, so it must have been changed sometime before that.
 
It looks like it appeared in draft 08, June 1998.
 
>In anycase, we will update the extension to conform with the RFC.
 
This may not help much, since it'll just break any existing implementation 
which expects an IA5String (in practice I suspect it won't make any 
difference, because almost everything seems to ignore the policy stuff, but 
it's still a bit risky).  The problem lies with the RFC and not with existing 
implementations, what you'd need to do is allow a changeover period as with 
dates and UTF8String's where you can use IA5String until (say) 2005, but after 
that should use DisplayString.
 
Currently I'm using a CHOICE { DisplayString, IA5String } with DisplayString 
first in the encoding table which means it'll be generated in preference to 
IA5String, but IA5String will still be accepted when decoding certs.
 
Peter.

Date: Wed, 24 Feb 1999 16:34:16 -0500
To: Mark Wahl <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: A web of directories
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Mark,

Thanks for the reminder.  How widely used are SRV records, i.e., if I
looked at N DNS MX records, what percentage of corresponding SRV records
would I be likely to find?

Steve

Date: Wed, 24 Feb 1999 13:29:52 -0600
From: Mark Wahl <[email-masked]>
Subject: Re: A web of directories
To: Stephen Kent <[email-masked]>
Cc: Larry Layten <[email-masked]>, Bob Jueneman <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

> but we don't have a record format in the DNS that points to an LDAP
> directory as a result.  One could define such a record type, though.

The IDS, LSD and service location working groups have documented in various
I-Ds how to locate an LDAP server through SRV records in the DNS.  One
place to start is RFC 2377, another is draft-ietf-svrloc-discovery-10.txt.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

From: Larry Layten <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: Bob Jueneman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: A web of directories
Date: Wed, 24 Feb 1999 12:39:24 -0600
Sender: [email-masked]

Steve,

I thought that SRV records provided the means to advertise
a service to an address/port.

Larry

-----Original Message-----
From:	Stephen Kent [SMTP:[email-masked]]
Sent:	Wednesday, February 24, 1999 11:24 AM
To:	Larry Layten
Cc:	Bob Jueneman; [email-masked]
Subject:	RE: A web of directories

Larry,

>For e-mail certificates, can't you use the domain from
>the internet e-mail address to point you to a DNS server
>And can't that in turn point you to the correct LDAP directory.

One can certainly look up the user's DNS server based on e-mail address,
but we don't have a record format in the DNS that points to an LDAP
directory as a result.  One could define such a record type, though.

Steve

Date: Wed, 24 Feb 1999 12:54:28 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Bug in RFC 2459
To: [email-masked]
Content-MD5: 2/7TrhXGe265qeoOVAb2YQ==
Sender: [email-masked]

> From: [email-masked] (Peter Gutmann)
> 
> (ObGrumble: You have to wonder why anyone even bothers adding half the 
>  extensions in a cert for all the attention that gets paid to them - the 
>  policy extension could probably have just about anything in there and noone 
>  would even notice).

That would be an implementation bug.

If an implementation follows the path validation procedure of section
6, it pays attention to the certificatePolicies extension.  If an
implementation can't be bothered with path validation, you could make
the same statement about anything:  "the { signatureValue | validity |
issuerDN | CRL | ... } could probably have just about anything in there
and noone would even notice."

Date: Wed, 24 Feb 1999 12:36:01 -0500
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: A web of directories
Cc: <[email-masked]>
Sender: [email-masked]

Bob,

I meant AIA, authority info access. It is in PKIX part 1 and defines a way
to include pointers to info associated with the CA that issued a cert,
e.g., where to find the CA cert, the CRL, and OCSP responder, etc.

Steve

Date: Wed, 24 Feb 1999 12:24:18 -0500
To: Larry Layten <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: A web of directories
Cc: Bob Jueneman <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Larry,

>For e-mail certificates, can't you use the domain from
>the internet e-mail address to point you to a DNS server
>And can't that in turn point you to the correct LDAP directory.

One can certainly look up the user's DNS server based on e-mail address,
but we don't have a record format in the DNS that points to an LDAP
directory as a result.  One could define such a record type, though.

Steve

Date: Wed, 24 Feb 1999 12:00:26 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Usage of CRL Issuing Distribution Point
Cc: [email-masked]
Sender: [email-masked]

Pau-Chen

> I still have one question :
>
>   Section 5.2.5 of RFC 2459 says that an issuing-distribution-point
>   extension in a CRL can have DistributionPointName and ReasonFlags,
>   etc.
>
>   I can see why we need ReasonFlags. But what is the purpose for
>   DistributionPointName ? I have to know this name before I can get
>   the CRL, right ?

Inclusion of this info ensures that the CRL you retrieved is the one you
asked for, since we would rather not have to trust the directory system to
that extent.

Steve

From: Alex Deacon <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Bug in RFC 2459
Date: Wed, 24 Feb 1999 08:55:35 -0800
Sender: [email-masked]

Looks like draft-ietf-pkix-ipki-part1-11.txt specifies DisplayText for the
organization, so it must have been changed sometime before that.  

In anycase, we will update the extension to conform with the RFC.

Alex

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, February 24, 1999 6:47 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Bug in RFC 2459
> 
> 
> Peter,
> 
> Not to be too picky, but what you described is not a bug just 
> becuase a
> spec changed from draft to RFC. Only if the change was 
> inadvertant would it
> qualify as a bug.  Perhaps the editors of Part 1 can comment on the
> motivation for the change.
> 
> Steve
> 

From: [email-masked]
Date: Wed, 24 Feb 1999 11:03:07 -0500
To: [email-masked]
Subject: Re: Usage of CRL Issuing Distribution Point
Content-Md5: wRfIU7dmfXh43B3trFQv0w==
Sender: [email-masked]

 Thank you all for the answers and dsicussions to my CRL question.
 
 I still have one question :
 
   Section 5.2.5 of RFC 2459 says that an issuing-distribution-point
   extension in a CRL can have DistributionPointName and ReasonFlags,
   etc.
   
   I can see why we need ReasonFlags. But what is the purpose for 
   DistributionPointName ? I have to know this name before I can get
   the CRL, right ?

 Thanks in advance for any help you can provide.

 Regards, Pau-Chen

Date: Wed, 24 Feb 1999 09:46:56 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Bug in RFC 2459
Cc: [email-masked]
Sender: [email-masked]

Peter,

Not to be too picky, but what you described is not a bug just becuase a
spec changed from draft to RFC. Only if the change was inadvertant would it
qualify as a bug.  Perhaps the editors of Part 1 can comment on the
motivation for the change.

Steve

Date: Wed, 24 Feb 1999 09:21:23 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: CMC Comments? 
To: [email-masked]
Content-MD5: c+4EDtvwuzBQijOqBDq7RA==
Sender: [email-masked]

> From: "Phillip M Hallam-Baker" <[email-masked]>
> 
> That is ISO model standardization, not IETF model standardization.
> Remember the mantra:
> 
> 	'There will be NO flag days'
> 
> Backwards compatibility is what the INTER-net is all about. When you 
> have an installed base of 100 million odd clients you make sure that
> the standards proposed support them wherever possible.

The Web succeeded because it interoperates with the installed base.
Yet the http specification contains no conformance statement which
mandates that http implementations support ftp, gopher, or wais.

A minimally-conformant TLS implementation would not interoperate
with the installed base of 100 million odd SSL clients.  That is
an incentive for developers to support more than the minimum, not an
argument for raising the minimum.

Can you you provide an example of an IETF INTER-net protocol
specification which mandates support for a prior functionally-similar
protocol?  My mental model of the IETF says that interoperability is
achieved by designating a single mandatory-to-implement
protocol/algorithm/data-structure/whatever for each function, along
with a naming/versioning system which enables the negotiation
of alternative recommended, optional, or locally defined
mechanisms.

Date: Wed, 24 Feb 1999 09:03:46 -0500
To: "Bob Jueneman" <[email-masked]>
From: Francois Rousseau <[email-masked]>
Subject: Re: A web of directories
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Bob,

As I have previously suggested as solution to your requirement, I think
Steve meant the Authority Information Access (AIA) extension from section
4.2.2.1 of RFC 2459, which may be included in subject or CA certificates.

This proposed sub-type (i.e. id-ad-repository) would be included in
subject's certificates and could be used to associate an Internet style
identity for the location of the repository to retrieve the issuer's
certificate in cases where such a location is not related to the issuer's
name.

Francois Rousseau
AEPOS Technologies

Bob Jueneman wrote:
[clip]
>I confess that I don't recall the AAI extension, at least by that acronym.  
>Can you give me a reference to it?  If it will work, I'm happy.
>
>Bob
>
>
>>>> Stephen Kent <[email-masked]> 02/23/99 10:04AM >>>
>Bob,
>
>Aw, come on now, Bob.  DN's are NOT intended to include pointers to
>directory servers.  They are names within the DIT.  Don't try to shoehorn
>other info into a DN just because the GeneralName form allows other forms
>of IDs.  I agree with the suggestion that one could use the AAI extension
>with an appropriate sub-type.  (Actually, a previous version of PKIX Part
>1, which allowed for end-entity info rather than CA info makes more sense
>here, but we seemd to have lost that distinction along the way.)
>
>Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Bug in RFC 2459
Reply-To: [email-masked]
Date: Wed, 24 Feb 1999 22:34:02 (NZDT)
Sender: [email-masked]

As was trying to process a newly-issued Verisign test cert I noticed that 
the software was rejecting the cert due to an invalid cert.policy extension.
After a bit of poking around I found that the string type for
userNotice.noticeRef.organization quietly changed between the final drafts
and the actual RFC, so that what used to be an IA5String has now become a
DisplayString, which is a mixture of everything but IA5String.  This means
that any cert issued under the drafts isn't compliant with the final RFC.
Note that this is a PKIX bug, not a Verisign bug (the fact that the 
extension falls into indefinite-length encodings at various points is a bug,
but I grumbled about that nearly a year ago).

There are three possible ways to fix this:

1. Define a new cert.policy extension OID for the DisplayString version (this
   is probably bad).
2. Move back to the IA5String.
3. Make the organization a CHOICE between a DisplayString and an IA5String
   and deprecate the IA5String.

(ObGrumble: You have to wonder why anyone even bothers adding half the 
 extensions in a cert for all the attention that gets paid to them - the 
 policy extension could probably have just about anything in there and noone 
 would even notice).

Peter.

From: [email-masked]
To: Stefan Santesson <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], ietf-pkix <[email-masked]>
Date: Tue, 23 Feb 1999 14:12:38 -0500
Subject: Re: Comments to Qualified Certificates draft
Sender: [email-masked]

From: Larry Layten <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Bob Jueneman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: A web of directories
Date: Tue, 23 Feb 1999 14:58:02 -0600
Sender: [email-masked]

For e-mail certificates, can't you use the domain from
the internet e-mail address to point you to a DNS server
And can't that in turn point you to the correct LDAP directory.

Larry

-----Original Message-----
From:	Stephen Kent [SMTP:[email-masked]]
Sent:	Tuesday, February 23, 1999 11:04 AM
To:	Bob Jueneman
Cc:	[email-masked]
Subject:	Re: A web of directories

Bob,

Aw, come on now, Bob.  DN's are NOT intended to include pointers to
directory servers.  They are names within the DIT.  Don't try to shoehorn
other info into a DN just because the GeneralName form allows other forms
of IDs.  I agree with the suggestion that one could use the AAI extension
with an appropriate sub-type.  (Actually, a previous version of PKIX Part
1, which allowed for end-entity info rather than CA info makes more sense
here, but we seemd to have lost that distinction along the way.)

Steve

Date: Tue, 23 Feb 1999 12:14:24 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: A web of directories
Sender: [email-masked]

As Tom pointed out and I realized independently, there are some 
technical difficulties with the execution I proposed, not the least 
of which is the fact that a SET of optional components would be 
a nightmare to implement as the root of the DIT!

If all else fails, we could include the necessary information elsewhere 
in the certificate, although I really liked the idea of including it in the DN
in order to take advantage of existing mechanisms.

We could conceivably include a single primary directory name as a top level
component of a DN, since within that directory's view of the DIT everything 
would be consistent. And if and when we evolve to a world-wide directory
that (sub)directory name might be able to serve as a schema qualification.

But I don't want to wreck the existing DIT class definitions, at
least not out of ignorance, so I will have to propose something else.

I confess that I don't recall the AAI extension, at least by that acronym.  
Can you give me a reference to it?  If it will work, I'm happy.

Bob

>>> Stephen Kent <[email-masked]> 02/23/99 10:04AM >>>
Bob,

Aw, come on now, Bob.  DN's are NOT intended to include pointers to
directory servers.  They are names within the DIT.  Don't try to shoehorn
other info into a DN just because the GeneralName form allows other forms
of IDs.  I agree with the suggestion that one could use the AAI extension
with an appropriate sub-type.  (Actually, a previous version of PKIX Part
1, which allowed for end-entity info rather than CA info makes more sense
here, but we seemd to have lost that distinction along the way.)

Steve

From: "Flanigan, Bill" <[email-masked]>
To: "'Duran, Robert'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: DN in a cert
Date: Tue, 23 Feb 1999 12:31:39 -0500
Sender: [email-masked]

Hello Robert,

	It's pretty much your call if you are going with an in-house
solution for a "nonconventional" DIT.  If not, you are limited to what
doesn't cause off-the-shelf products to choke (especially when you leave the
"enterprise enclave").  For now, we have found it advisable to train all our
folks in the Heimlich maneuver!

Bill

               -----Original Message-----
> From:	Duran, Robert [SMTP:[email-masked]]
> Sent:	Monday, February 22, 1999 11:01 AM
> To:	[email-masked]'
> Subject:	DN in a cert
> 
> I have a question in regards to  the DN/Subject of a certficate. Is it
> acceptable generate a certificate with a DN= O=Comapny OU=People
> UID=UserID?
> Id like to avoid CommonName becasue it may change but the UID would not
> (at
> least in my situation)
> 
> 
> Rob D.
> Aetna -  IT Sercuirty
> (860) 636-2462
> [email-masked]
>  <<Duran, Robert.vcf>>  << File: Duran Robert.vcf >> 

Date: Tue, 23 Feb 1999 12:04:16 -0500
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: A web of directories
Cc: <[email-masked]>
Sender: [email-masked]

Bob,

Aw, come on now, Bob.  DN's are NOT intended to include pointers to
directory servers.  They are names within the DIT.  Don't try to shoehorn
other info into a DN just because the GeneralName form allows other forms
of IDs.  I agree with the suggestion that one could use the AAI extension
with an appropriate sub-type.  (Actually, a previous version of PKIX Part
1, which allowed for end-entity info rather than CA info makes more sense
here, but we seemd to have lost that distinction along the way.)

Steve

From: "Kurn, David" <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: [email-masked]
Subject: RE: A web of directories
Date: Tue, 23 Feb 1999 08:32:07 -0800
Sender: [email-masked]

Bob et al...

OK.... Not a URL or URI, but instead
  - Identifier of a protocol
  - Arguments relevant to that protocol
and being ASN.1 challenged, I leave it to others to make that more precise.
I think we are in agreement here.

In any (cryptographic) environment where trust is an issue, we make certain
assumptions about the kind of information available.  As far as I can tell,
it includes (but is not limited to):

- One or more root-certs (or trust points) from which all other trust is
derivied;
- One or more of your own certificates with your private keys;
- A way to get to the CA and Certificate store which houses your own
credentials;

I suppose that we could use the latter as the "default directory" value.

It's quite a jump from that to the ability to check the validity of an
arbitrary arriving certificate.  For example, if you sent me encrypted and
signed mail, using your Novell-issued credentials, I'd first want to check
to see if your issuer has revoked your cert.  I have absolutely no clue how
to find your issuer's CRLs in the current scheme.  It would be unwise to
assume that *my* issuer's directory is linked to yours (and such an
assumption seems to imply a n-squared problem if everyone has to know about
everyone else, which raises scalability issues).

So, I use our new attribute (which identifies the protocol and arguments
relevant to the protocol) to talk to your CA's certificate directory, and I
discover that your cert is not revoked (a very good thing).  

I continue my trust chain, and retrieve your CA's certificate, which lets me
continue the validation of your cert, and find that your CA's certificate is
not self-signed, but is signed by someone in my trust data-base.  Voila ...
I have the necessary cryptographic link.

Now, back to the default issue ....

If your mail was signed by a cert which had no "how-to-find" advice, I'd
really be in trouble.  If I chose the current method, I'd ask my own
directories, but in general, that would be a waste of time.  Furthermore,
asking my own directory where the normal case is "cannot find" puts
unnecessary load on that directory and has scalability problems.

David

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, February 22, 1999 7:16 PM
To: Kurn, David; [email-masked]
Cc: [email-masked]
Subject: RE: A web of directories

David, the URI/URL concept was exactly what I had in mind.

However, I wanted it to work across multiple protocols, so I didn't
think that
specifying the URI in terms of the current string format was the way
to
go, as it wouldn't work for DAP or DSP, for example.  

So I fudged it, by saying that the RDN component would be in ASN.1 
format, as would the rest of the DN, but that the client was
responsible for
translating the DER encoded DN into whatever format that particular 
protocol required.

This provides the ability to have our cake and eat it too -- we can
stay within 
the X.500 name structure, with all of the advantages of strong type 
encoding where required, while still being compatible with LDAP or 
whatever else is required.

I'm not quite sure I understood our point about having a "default"
directory
pointer, especially as it pertains to the ambiguity of where
Springfield is located.
Maybe you would like to elaborate.

What I had in mind was to provide at least one guaranteed-to-be-found
location where a particular DN is defined, along with the appropriate
certificate
content or other payload.  If desired, the user could include in the
SET of
directory providers each and every such directory, and let the client
software
choose between them based on any criteria it chooses, such as location

in the same country (based on the DNS suffix), access protocol
supported, etc.

Bob

>>> "Kurn, David" <[email-masked]> 02/22/99 01:01PM >>>
Bob et al

Nice generalization.  Of course, you have just re-invented a URI (or is
it
URL), so why not in general allow the syntax:

<name-of-protocol>://<ip-address-and-maybe-portno>/<stuff-interpreted-by-the
-server

as the access to the certificate lookup service.  Obvious candidates
are
ldap: http: https:

with "ldap:" probably being the default.

I have a problem with presuming any kind of default directory pointer
(in
general) because you have no idea where or who will be using your
certificates.  As a metaphor, consider that I send you a snail-mail
message,
and list on the top-left of the envelope a return address like:

  123 First Street
  Springfield

Now, as you may know, there are at least 26 instances of Springfield in
the
US, but since you're in Utah, you should assume it means "Springfield
Utah"?
Hmmm.... Bad idea.

I have no idea if there's any hope in our lifetime of affecting
standards,
but at least the discussion is interesting.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 11:38 AM
To: Kurn, David; [email-masked] 
Cc: [email-masked] 
Subject: A web of directories

<snip>

Date: Tue, 23 Feb 1999 11:16:31 -0500
To: "Duran, Robert" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: DN in a cert
Cc: [email-masked]
Sender: [email-masked]

Rob,

PKIX does not mandate any particular schema for DNs; in fact, because we
support altSubject names, we don't even mandate use of DNs for end
entities.

Your particular example DN omitted the country attribue, which one usually
employs to ensure global uniqueness of the company name, but even there,
PKIX does not mandate inclusion of that attribute, although most of us
would tend to strongly encourage it.

Steve

From: [email-masked]
To: "'Bob Jueneman'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: A web of directories
Date: Tue, 23 Feb 1999 11:09:23 -0500
Importance: Normal
Sender: [email-masked]

>Rich, what I'm trying to do is to find a way to make
>directories work

Which (whose) directory? :)  Surely not all of them.

Hm. I think you're actually trying to find a way to avoid
sending a cert chain.  Seems to me that an AIA extension
and just sending the end entity cert probably cuts down the traffic
significantly (what's the average chain length in use
or expected to be in use?  Your guess is as good as mine) --
at least in half.

	/r$

Date: Tue, 23 Feb 1999 08:52:50 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: A web of directories
Sender: [email-masked]

Rich, what I'm trying to do is to find a way to make directories work,
given the fact that at present there is no reliable, overarching
directory, yet there are hundreds of thousands if not millions 
of corporate directories installed and running.

The problem is that since those have been installed primarily for 
internal corporate use, there is no way of knowing where they are,
even if the directory owner has installed a partial replica on the outside
of the firewall where it would be accessible.

At present, of course, random DNs hardly show up at all, because
the existing protocols, recognizing that richly interconnected 
directories don't exist, send the entire certificate chain down the path
every time, whether they are needed or not. This is true of SET, it's 
true of SSL, and it's true of S/MIME.  This type of unnecessary 
"push" distribution is extraordinarily wasteful of bandwidth  -- you 
say "Hello, world" and get another 1 to 5K of unnecessary baggage.

But this is a chicken and egg problem -- we can't expect the protocols to
stop doing that until there is a workable alternative.

Bob

>>> Rich Salz <[email-masked]> 02/22/99 09:11PM >>>
Is it really that common to get a random, unknown DN and expect to
do something useful with it?  Is it so common that it's worth
defining an AIA-style name/attribute component?

How often do you expect to receive a random DN without the associated
cert?  And when you get them, what are you expecting to do with them?

Sure seems a lot easier to say "send the cert"
	/r$

Date: Mon, 22 Feb 1999 23:11:39 -0500 (EST)
From: Rich Salz <[email-masked]>
To: Bob Jueneman <[email-masked]>
Cc: [email-masked]
Subject: Re: A web of directories
Sender: [email-masked]

Is it really that common to get a random, unknown DN and expect to
do something useful with it?  Is it so common that it's worth
defining an AIA-style name/attribute component?

How often do you expect to receive a random DN without the associated
cert?  And when you get them, what are you expecting to do with them?

Sure seems a lot easier to say "send the cert"
	/r$

Date: Mon, 22 Feb 1999 20:58:53 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: A web of directories
Sender: [email-masked]

Tom, the last thing I want to get into is an ASN.1 fight, much less an 
X.520 fight.  If we agree about the basic concepts, we can finesse 
the ASN.1 details any way we would like -- we surely have people on this
list that are more expert in that than I am.

(But whether X.520 has a particular attribute is not of very great concern 
to me. Hoyt Kesterson has made it quite clear that these were only 
supposed to be examples, not a Procrustean bed of a standardized schema.
And the NADF and others concluded some time ago that "useful definitions"
was an oxymoron. They aren't. Very. Useful.)

My intent was to do as you suggest, and to provide the necessary information
that any client which understood the protocol could transform into whatever
form of URL, presentation address, or method yet to be determined might 
require.  (That is assuming the basic model of a DNS name and a port 
number for a protocol.)

In particular, I wanted to keep the definitions within the set of X.500/X.509 RDN
components, i.e., I did not want to depart from an ASN.1 structure and suddenly
start using string notation a la LDAP or SPKI. But I have no objection if some
protocol which uses that type of notation wants to convert the RDN sequence to
a standard URL format -- I am assuming that they would.

I do disagree with the concept of putting the information into an issuerAltName
or some similar construct, although I did think about it for several days.

The reason I rejected it is that we already have such alternate names, and 
they may be used for entirely different purposes that are not linked to the primary DN
(subject or issuer), and in addition may need their own form of directory locator function.

As I said in the original note, I wouldn't be opposed to putting the directory locator
function in a different attribute, but only if someone can dream up a way of supporting
both the primary DN and alternate subject names, _and_ keep track of the pairing of
the name and the directory location, especially given that different directories and/or
protocols may be required for different name types.  So far, I haven't thought of a 
way to be able to do that.

Bob

>>> <[email-masked]> 02/22/99 03:13PM >>>
     The construct you've come up with is very useful, but I don't think
it's a DN.  In fact, the LDAP variant is a legal RFC 2255 URL.
Unfortunately, X.520 doesn't have an attribute type for URL's even though
they have the ISO equivalent presentationAddress.  So if you really want to
put this into a DN, why not create a new attribute type syntax called
NetworkApplicationLocation whose syntax is a choice between a URL and a
PresentationAddress.  There's no extra ASN.1 tagging needed, because
PresentationAddress is an ASN.1 sequence, and URL is just an IA5String.
One would then define attributes with this syntax: a general one called
networkApplicationLocation and a more specific one called referenceLocation
or directoryLocation.  The value of directoryLocation in a DN would just be
the leading part (through port number) of the LDAP URL.
     In the case of a certificate, it's simpler and better just to put the
full URL, including underlying DN, into issuerAltName or subjectAltName.

          Tom Gindin

"Bob Jueneman" <[email-masked]> on 02/22/99 02:37:45 PM

To:   Tom Gindin/Watson/IBM, "Kurn, David" <[email-masked]>
cc:   [email-masked] 
Subject:  A web of directories

Was: Re: Finding PKIX Servers!

Tom and David,

Sometimes the simplest ideas solve very difficult problems,
and then you kick yourself for not having thought of it earlier.

For years I have been troubled by the fact that I couldn't
find a way of dealing with a residential person's DN, when
there wasn't a monopoly directory service provider or even
a de facto name registration authority.

If my DN is c=US, st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481,
how can anyone find that entry in a directory if the state of
Utah doesn't provide a centralized directory service?  Lots
of directory service providers might actually include or list
that DN in their directory, including the US Post Office,
the electric company, the gas company, several telephone
companies, my ISP, etc., etc., not to mention the Utah
Department of Wildlife Management that issued me a
fishing license, my health insurance company, and probably
the FBI, the Social Security Administration and sundry
other agencies who maintain some kind dossier, not to
mention VeriSign who issued me a certificate, but how can
anyone find them if they don't know that fact in advance?

The solution to this problem which now seems increasingly
obvious and desirable is that the DN itself should include an
optional reference to the directory service provider which
does contain that DN, i.e., a URL to the
directory itself.

Because the allowable PKIX name forms allow the use of a URL,
my first thought was to simply list the DN in the form of an LDAP URL:
LDAP://ldap.verisign.com/c=US,st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481.

But to paraphrase Richard Nixon, we could do that, but it
would be wrong.

We shouldn't force all directory queries into one particular
format and protocol, especially one as restrictive as LDAP.

Instead, I propose creating a new optional attribute, called
directoryProvider, that would normally be the first RDN in the
DN, at least when the DN is expressed within a certificate or
in some other context that is external to the directory itself,
e.g., as a reference to the originator's name and certificate
in an S/MIME message.

The tricky part of the definition is that the directoryProvider
attribute could conceivably be IMPLICIT within the directory
that actually contains the rest of the RDN sequence, but
could be used as an explicit reference for chaining and/or
referral within or by a directory that did not contain the rest
of the RDN sequence.

I'll let someone more expert in directories and ASN.1 suggest
how to best encode that thought, and also explore the
implications, but roughly what I have in mind is something
like the following, recognizing that there may be improvements
possible in these constructs or the way they are encoded:

<  forgiveUsOurASN.1Transgressions ::= ON   >

DirectoryProvider ::= SEQUENCE {
          directoryAccessProtocol  DirectoryAccessProtocol,
          } OPTIONAL

DirectoryAccessProtocol  CHOICE {
           [0]  ldap        PData ("LDAP://", dnsD, ldapPort#   )

           [1]  dap         PData  ("DAP://", dnsD, dapPort#)
OPTIONAL,
           [2]  dsp          PData  ("DSP://" dnsD, dspPort#)
OPTIONAL,
           [3]  http          PData  ("HTTP://", dnsD, httpPort#)
OPTIONAL,
           [4]  https        PData  ("HTTPS://", dnsD, httpsPort#)
OPTIONAL,
           [5]  otherAP   Pdata  OPTIONAL }     -- reserved for
expansion and/or proprietary protocols

PData  SEQUENCE {
     protocolName    PrintableString,
     dnsD                  DnsD,
     separator            PrintableString ":"
     portNumber        INTEGER}

DnsD ::= DNSName                -- DNS name of the directory service
provider's server
                                                             --    for
the named protocol.

By providing support for multiple directory access protocols, the
directory service provider can offer a choice of methods to someone
who needs to find something in that directory.

Presumably most browsers would either use LDAP or HTTP, assuming
the directory provider offers those services.

But the directory client would not be forced to go directly to the
named
directory.

Instead, the more reasonable and encouraged behavior would be for
the client to first try to find the information in the client's own
personal
directory or cache, ignoring the directory provider information, and
then
in the user's own organization's directory, again ignoring the
directory provider
information, and only if unsuccessful would it be necessary to go to
(one or more of) the listed directory service(s).

Assuming that the user's organization directory supports X.500,
that directory should be able to chain directly to the other Directory
Service Agent using the DSP protocol, even though the original query
might have come in via LDAP or HTTP to a directory front-end.
But if for some reason the user's DSA does not support chaining, it
can
bounce the request back to the client, which can then do referral to
the next directory service provider protocol in the set that it
supports.

If we only had to deal with a single name in a certificate, for
example
the Issuer, there would be a considerable advantage in making this
attribute completely separate, rather than including the attribute
within the DN itself.  But including a set or sequence of directory
provider names clearly points to a directory which can be assumed
to have implemented the appropriate schema for the RDN attributes
that make up the DN, and it will work for alternateSubjectNames
that are in the form of a DN as well.

Perhaps more importantly, by extending the DN in this manner, the
scheme works for references to DNs that are outside of either a
certificate or a directory construct.  For example, I would hope that
I could receive a signed S/MIME message that only identified the
originator by his DN, and then go look up that DN without having
to have the certificates sent down the line to me every time.

Finally, it is assumed that the client understands the various
protocols,
and is responsible for converting the standard DN attribute syntax into

whatever form the protocol requires. Ideally, the client should also
be capable of doing referral, so that if the first directory provider
that is
tried is unavailable or uses a directory access protocol which the
client doesn't support, the client can move on to the next in the set
or sequence.

Some examples might make this clearer. I'll use a business card type
of
output of the protocol string translation for simplicity:

LDAP://directory.verisign.com/c=US,o="XYZ Corp.", cn="John Smith"

DAP://voter.ut.us/c=US, st=UT, l=Provo, cn="Robert R. Jueneman"

http://adblitz.yahoo.com/c=US, rfc822="[email-masked]"

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

>>> <[email-masked]> 02/22/99 09:51AM >>>
     I don't think the location of an LDAP server should be mandatory,
but
an LDAP URL would be a reasonable option within issuerAltName.  While
the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked] 
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer
if"
points, but I think he has identified a real need in our efforts to
deploy
PKI.

Ignoring, for the moment, how I obtained Bob's key-encryption cert in
the
first place, there are two other places I must go to before I can
evaluate
trust.

1)  I must find the certificate of the issuer (signer) of the
certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service
address
(DNS name) for each is specified in all PKI certs.  Call it optional
(to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked] 
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an
optional
attribute
in a certificate that is associated with the Issuer's name somehow,
one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the
attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of
alternateSubjectName, or
it
could be some other alternateSubjectName attribute, or some other
attribute
entirely.

But is there at least some agreement about the potential utility of
this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

Date: Mon, 22 Feb 1999 20:39:00 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RE: A web of directories
Sender: [email-masked]

I think we are off the track here.

The issue isn't domains of trust, or open vs. closed PKI, it is an issue of how to find 
the directory where ANY information about that DN is listed, since the connection 
between the user's name and the name of his CA, as well as that CA's directory,
may be completely non-obvious.  But I don't want to assume that the name of the 
CA and the name of the directory into which the CA publishes certificates or anything 
else is closely tied together, necessarily.

My model is that if I receive a naked DN, I would first look it up on my own personal 
cache or mini-directory, one that I may have updated with a "Hit the road option" just 
before I left for the airport.

If I don't find it there, my next choice would be to look for it in my corporate directory,
since I have a 100 megabit local LAN connection to it.

If it isn't there, but my company subscribes to a CA/repository service, I might 
well want to check there next, but that assumes a business model that I don't
necessarily want to force on people, any more than I want to compel people 
to necessarily use a directory at all if they would rather use DNS or http.

But if all else fails -- maybe I am a sole practitioner in my bedroom/office, I would like
to know where to point my browser/e-mail/code verification software to next, in order 
to find the certificate corresponding to that DN, and then to proceed to climb the 
Subject/Issuer chain without being compelled to make assumptions about the 
length of that chain or the fact that all of the certificates in the chain after the 
end-user's were necessarily issued by the same organization or are 
necessarily contained in the same directory.

And this has little or nothing to do with how to find CRLs, since we already have 
an adequate mechanism for that (if not necessarily the most elegant or generalizable).

Bob

>>> Mike Smith <[email-masked]> 02/22/99 02:45PM >>>
So, isn't the burden on the CA to include what they need for folks that need to rely on the certificates that they issue?  Private CAs may issue certificates with no linkage to them because they do not wish their certs used outside the domain of trust in which they were issued.

If a CA issues certs to be used in other domains, then the issuing CA needs to ascertain that the other domains or their CA can route requests from the relying parties in those domains back to themselves.

It just seems that this discussion may be trying to solve a problem that won't exist, or, if it does exist, raises competancy (and trust) questions about the CA issuing certs that are intended to be "global" without including the CRL distribution point in the certs they issue.  The alternative for bridging non-global (private) PKIs would most likely have the CAs that would accept the foreign certificates into their domain of trust building the interface or validation process into the system for their subscribers that act as relying parties.

I think that the main problems arising in this discussion come from the perception that the relying party is the source of trust, not the CAs (theirs or the correspondent's issuer or some trusted third party that one or both CAs subscribe to).

If, in Bob's analogy, one were to set up a global directory to whihc all could go, search, retrieve certs and CRLS, it still comes down to the relying party's CA and issuing CA subscribing to or authorizing use of such third party directory for relying on their certificates, thus CRL or OCSP distribution points in their issued certs.

Quite often, the relying party would go into theor own trust domain (i.e., their issuing CA) to let the CA sort out all of the problems with bridging domains of trust transparent to themselves.

The relying party should, in my opinion, always go to THEIR trusted source to see if they are including the received cert and indemnifying them from the pitfalls of a bad or revoked cert.

This trust issue is the crux of any PKI.  If any relying party gets to choose their own trust domains and can't find the source of trust on a received cert, then maybe that is a good thing and they are not supposed to be trusting that cert outside of its own domain of trust?

Michael

>>> "Kurn, David" <[email-masked]> 02/22/99 02:28PM >>>
Mike

Of course, if you *know* it's from the State of Utah.  But, let's consider
that I send you mail.  You have no idea who/what I am, so you look at my
signature certificate and try to deduce something from it.  Maybe if you're
a human being and bring to the table lots of context, you can guess where to
look for CRL,s or for the CA's web site, etc.  But, if you are a computer
program, it would be a lot easier if the certificate stated:

  To find the CRL and other stuff of the CA that issued me, please look in
this <URL or URI or something>.

David

-----Original Message-----
From: Mike Smith [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 12:48 PM
To: [email-masked]; [email-masked]; [email-masked] 
Cc: [email-masked] 
Subject: Re: A web of directories

Bob:

If you received a certificate from State of Utah for your drivers license,
fish and game or whatever, then shouldn't the CA that issued the cert
support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not
practical for any entity, whether corporate or human or animal (e.g.,
issuing a certificate of authenticity for a thoroughbred race horse with
it's DNA signed by the CA, or some such future application with biometric
filters as part of the biometric certificate authentication to activate the
information system that actually processes the "signature" of the entity
(say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more
business for our CA service).

Michael

Date: Mon, 22 Feb 1999 20:23:34 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: A web of directories
Sender: [email-masked]

Yes, they should, as should any CA, except for the fabled Pasadena Ladies
garden Club, that operates their own CA once a year and wishes to outsource 
the directory functions to someone who is in the business of providing directory 
services.

But one of the other desiderata was that this should work for any old DN, and 
not necessarily one that was included in a certificate. So I may not have the
user's certificate, and hence don't know the Issuer's name, nor what directory
access protocol they might want to support.

('Course if we wanted to mandate Novell's variant of DAP, NDAP, that would 
be fine with me. :-)

I don't think there is an issue of trying to put all of one's identities in one certificate --
in fact I was citing multiple certificates for precisely that reason.

Bob

>>> Mike Smith <[email-masked]> 02/22/99 01:47PM >>>
Bob:

If you received a certificate from State of Utah for your drivers license, fish and game or whatever, then shouldn't the CA that issued the cert support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not practical for any entity, whether corporate or human or animal (e.g., issuing a certificate of authenticity for a thoroughbred race horse with it's DNA signed by the CA, or some such future application with biometric filters as part of the biometric certificate authentication to activate the information system that actually processes the "signature" of the entity (say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more business for our CA service).

Michael

>>> "Bob Jueneman" <[email-masked]> 02/22/99 12:37PM >>>
Was: Re: Finding PKIX Servers!

Tom and David,

Sometimes the simplest ideas solve very difficult problems, 
and then you kick yourself for not having thought of it earlier.

For years I have been troubled by the fact that I couldn't 
find a way of dealing with a residential person's DN, when 
there wasn't a monopoly directory service provider or even
a de facto name registration authority.

If my DN is c=US, st=UT, 
cn="Robert R. Jueneman"+driversLicense=159975481,
how can anyone find that entry in a directory if the state of 
Utah doesn't provide a centralized directory service?  Lots 
of directory service providers might actually include or list
that DN in their directory, including the US Post Office, 
the electric company, the gas company, several telephone 
companies, my ISP, etc., etc., not to mention the Utah 
Department of Wildlife Management that issued me a 
fishing license, my health insurance company, and probably 
the FBI, the Social Security Administration and sundry 
other agencies who maintain some kind dossier, not to
mention VeriSign who issued me a certificate, but how can 
anyone find them if they don't know that fact in advance?  

The solution to this problem which now seems increasingly 
obvious and desirable is that the DN itself should include an
optional reference to the directory service provider which 
does contain that DN, i.e., a URL to the 
directory itself.

Because the allowable PKIX name forms allow the use of a URL,
my first thought was to simply list the DN in the form of an LDAP URL:
LDAP://ldap.verisign.com/c=US,st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481.

But to paraphrase Richard Nixon, we could do that, but it 
would be wrong.

We shouldn't force all directory queries into one particular
format and protocol, especially one as restrictive as LDAP.

Instead, I propose creating a new optional attribute, called 
directoryProvider, that would normally be the first RDN in the 
DN, at least when the DN is expressed within a certificate or 
in some other context that is external to the directory itself, 
e.g., as a reference to the originator's name and certificate 
in an S/MIME message.

The tricky part of the definition is that the directoryProvider
attribute could conceivably be IMPLICIT within the directory 
that actually contains the rest of the RDN sequence, but 
could be used as an explicit reference for chaining and/or 
referral within or by a directory that did not contain the rest 
of the RDN sequence.

I'll let someone more expert in directories and ASN.1 suggest
how to best encode that thought, and also explore the 
implications, but roughly what I have in mind is something 
like the following, recognizing that there may be improvements 
possible in these constructs or the way they are encoded:

<  forgiveUsOurASN.1Transgressions ::= ON   >

DirectoryProvider ::= SEQUENCE {
          directoryAccessProtocol  DirectoryAccessProtocol,
          } OPTIONAL

DirectoryAccessProtocol  CHOICE {
           [0]  ldap        PData ("LDAP://", dnsD, ldapPort#   )             
           [1]  dap         PData  ("DAP://", dnsD, dapPort#)        OPTIONAL,     
           [2]  dsp          PData  ("DSP://" dnsD, dspPort#)          OPTIONAL,     
           [3]  http          PData  ("HTTP://", dnsD, httpPort#)      OPTIONAL,    
           [4]  https        PData  ("HTTPS://", dnsD, httpsPort#)  OPTIONAL,   
           [5]  otherAP   Pdata  OPTIONAL }     -- reserved for expansion and/or proprietary protocols

PData  SEQUENCE {
     protocolName    PrintableString,
     dnsD                  DnsD,
     separator            PrintableString ":"
     portNumber        INTEGER}

DnsD ::= DNSName                -- DNS name of the directory service provider's server 
                                                             --    for the named protocol.

By providing support for multiple directory access protocols, the 
directory service provider can offer a choice of methods to someone
who needs to find something in that directory.

Presumably most browsers would either use LDAP or HTTP, assuming 
the directory provider offers those services.

But the directory client would not be forced to go directly to the named 
directory.

Instead, the more reasonable and encouraged behavior would be for 
the client to first try to find the information in the client's own personal 
directory or cache, ignoring the directory provider information, and then 
in the user's own organization's directory, again ignoring the directory provider
information, and only if unsuccessful would it be necessary to go to 
(one or more of) the listed directory service(s).

Assuming that the user's organization directory supports X.500,
that directory should be able to chain directly to the other Directory
Service Agent using the DSP protocol, even though the original query 
might have come in via LDAP or HTTP to a directory front-end.
But if for some reason the user's DSA does not support chaining, it can
bounce the request back to the client, which can then do referral to 
the next directory service provider protocol in the set that it supports.

If we only had to deal with a single name in a certificate, for example
the Issuer, there would be a considerable advantage in making this
attribute completely separate, rather than including the attribute
within the DN itself.  But including a set or sequence of directory
provider names clearly points to a directory which can be assumed 
to have implemented the appropriate schema for the RDN attributes 
that make up the DN, and it will work for alternateSubjectNames 
that are in the form of a DN as well.  

Perhaps more importantly, by extending the DN in this manner, the 
scheme works for references to DNs that are outside of either a 
certificate or a directory construct.  For example, I would hope that
I could receive a signed S/MIME message that only identified the 
originator by his DN, and then go look up that DN without having 
to have the certificates sent down the line to me every time.

Finally, it is assumed that the client understands the various protocols, 
and is responsible for converting the standard DN attribute syntax into 
whatever form the protocol requires. Ideally, the client should also
be capable of doing referral, so that if the first directory provider that is
tried is unavailable or uses a directory access protocol which the 
client doesn't support, the client can move on to the next in the set
or sequence.

Some examples might make this clearer. I'll use a business card type of
output of the protocol string translation for simplicity:

LDAP://directory.verisign.com/c=US,o="XYZ Corp.", cn="John Smith"

DAP://voter.ut.us/c=US, st=UT, l=Provo, cn="Robert R. Jueneman"

http://adblitz.yahoo.com/c=US, rfc822="[email-masked]" 

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

>>> <[email-masked]> 02/22/99 09:51AM >>>
     I don't think the location of an LDAP server should be mandatory, but
an LDAP URL would be a reasonable option within issuerAltName.  While the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked] 
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer if"
points, but I think he has identified a real need in our efforts to deploy
PKI.

Ignoring, for the moment, how I obtained Bob's key-encryption cert in the
first place, there are two other places I must go to before I can evaluate
trust.

1)  I must find the certificate of the issuer (signer) of the certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service address
(DNS name) for each is specified in all PKI certs.  Call it optional (to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked] 
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or
it
could be some other alternateSubjectName attribute, or some other attribute
entirely.

But is there at least some agreement about the potential utility of this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

Date: Mon, 22 Feb 1999 20:15:36 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: A web of directories
Sender: [email-masked]

David, the URI/URL concept was exactly what I had in mind.

However, I wanted it to work across multiple protocols, so I didn't think that
specifying the URI in terms of the current string format was the way to
go, as it wouldn't work for DAP or DSP, for example.  

So I fudged it, by saying that the RDN component would be in ASN.1 
format, as would the rest of the DN, but that the client was responsible for
translating the DER encoded DN into whatever format that particular 
protocol required.

This provides the ability to have our cake and eat it too -- we can stay within 
the X.500 name structure, with all of the advantages of strong type 
encoding where required, while still being compatible with LDAP or 
whatever else is required.

I'm not quite sure I understood our point about having a "default" directory
pointer, especially as it pertains to the ambiguity of where Springfield is located.
Maybe you would like to elaborate.

What I had in mind was to provide at least one guaranteed-to-be-found
location where a particular DN is defined, along with the appropriate certificate
content or other payload.  If desired, the user could include in the SET of
directory providers each and every such directory, and let the client software
choose between them based on any criteria it chooses, such as location 
in the same country (based on the DNS suffix), access protocol supported, etc.

Bob

>>> "Kurn, David" <[email-masked]> 02/22/99 01:01PM >>>
Bob et al

Nice generalization.  Of course, you have just re-invented a URI (or is it
URL), so why not in general allow the syntax:

<name-of-protocol>://<ip-address-and-maybe-portno>/<stuff-interpreted-by-the
-server

as the access to the certificate lookup service.  Obvious candidates are
ldap: http: https:

with "ldap:" probably being the default.

I have a problem with presuming any kind of default directory pointer (in
general) because you have no idea where or who will be using your
certificates.  As a metaphor, consider that I send you a snail-mail message,
and list on the top-left of the envelope a return address like:

  123 First Street
  Springfield

Now, as you may know, there are at least 26 instances of Springfield in the
US, but since you're in Utah, you should assume it means "Springfield Utah"?
Hmmm.... Bad idea.

I have no idea if there's any hope in our lifetime of affecting standards,
but at least the discussion is interesting.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 11:38 AM
To: Kurn, David; [email-masked] 
Cc: [email-masked] 
Subject: A web of directories

<snip>

From: [email-masked]
To: Andrew Probert <[email-masked]>
cc: [email-masked]
Date: Mon, 22 Feb 1999 19:40:12 -0500
Subject: RE: A web of directories
Sender: [email-masked]

Andrew Probert <[email-masked]> on 02/22/99 05:45:44 PM

To:   "'Kurn, David'" <[email-masked]>, "'Bob Jueneman'"
      <[email-masked]>, Tom Gindin/Watson/IBM
cc:   [email-masked]
Subject:  RE: A web of directories

Comments inline

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:   Kurn, David [SMTP:[email-masked]]
> Sent:   Tuesday, February 23, 1999 7:02 AM
> To:     'Bob Jueneman'; [email-masked]
> Cc:     [email-masked]
> Subject:     RE: A web of directories
>
> Bob et al
>
> Nice generalization.  Of course, you have just re-invented a URI (or is
it
> URL), so why not in general allow the syntax:
>
>
>
<name-of-protocol>://<ip-address-and-maybe-portno>/<stuff-interpreted-by-t
> he
> -server
>
> as the access to the certificate lookup service.  Obvious candidates are
> ldap: http: https:
>
> with "ldap:" probably being the default.
>
[Andrew Probert]  The syntax needs to be broader than URI if you go down
this path i.e. to also hold reference to X.500/IP server i.e. hostname (or
IP), portnumber, tsap, ssap, psap.

[Tom Gindin]  The simplest syntax is probably
NetworkApplicationLocation    ::=  CHOICE
{    UniformResourceID        IA5String,
     presentationAddress PresentationAddress
}
hostname and IP are included in URI and all 3 SAP's in PresentationAddress.
The choices have distinct tags, so no context-specific stuff is necessary.
>  I have a problem with presuming any kind of default directory pointer
(in
> general) because you have no idea where or who will be using your
> certificates.  As a metaphor, consider that I send you a snail-mail
> message,
> and list on the top-left of the envelope a return address like:
>
>   123 First Street
>   Springfield
>
     [Andrew Probert]  That's why we need global namespaces for global
electronic commerce!
     [Tom Gindin]  Of course we need global namespaces for global
electronic commerce.  We have a number of candidates: X.500 with common
name based on organization, X.500 with personal name based on organization,
X.500 with physical delivery addresses, RFC-822, or URI's (including
RFC-822)?  All of these are global namespaces, and I haven't counted X.400
separately from X.500.

-- snip --

From: Andrew Probert <[email-masked]>
To: "'Kurn, David'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: A web of directories
Date: Tue, 23 Feb 1999 09:45:44 +1100
Sender: [email-masked]

Comments inline

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Tuesday, February 23, 1999 7:02 AM
> To:	'Bob Jueneman'; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: A web of directories
> 
> Bob et al
> 
> Nice generalization.  Of course, you have just re-invented a URI (or is it
> URL), so why not in general allow the syntax:
> 
>  
> <name-of-protocol>://<ip-address-and-maybe-portno>/<stuff-interpreted-by-t
> he
> -server
> 
> as the access to the certificate lookup service.  Obvious candidates are
> ldap: http: https:
> 
> with "ldap:" probably being the default.
> 
[Andrew Probert]  The syntax needs to be broader than URI if you go down
this path i.e. to also hold reference to X.500/IP server i.e. hostname (or
IP), portnumber, tsap, ssap, psap.  
>  I have a problem with presuming any kind of default directory pointer (in
> general) because you have no idea where or who will be using your
> certificates.  As a metaphor, consider that I send you a snail-mail
> message,
> and list on the top-left of the envelope a return address like:
> 
>   123 First Street
>   Springfield
> 
	[Andrew Probert]  That's why we need global namespaces for global
electronic commerce!

> Now, as you may know, there are at least 26 instances of Springfield in
> the
> US, but since you're in Utah, you should assume it means "Springfield
> Utah"?
> Hmmm.... Bad idea.
> 
> I have no idea if there's any hope in our lifetime of affecting standards,
> but at least the discussion is interesting.
> 
> -----Original Message-----
> From: Bob Jueneman [mailto:[email-masked]]
> Sent: Monday, February 22, 1999 11:38 AM
> To: Kurn, David; [email-masked]
> Cc: [email-masked]
> Subject: A web of directories
> 
> <snip>

Date: Mon, 22 Feb 1999 17:42:45 -0500
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Usage of CRL Issuing Distribution Point
Cc: Trevor Freeman <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Denis,

>We should look for another solution able to solve this concern. Placing all
>this administrative information in a *single* and new data structure signed by
>the CA would need to be explored.
>
>Opinions ?
>
I'm not saying we coulkd not envision other approaches, but we have one
solution now, it is in our standard, and thus it is an answer to the
questions we were discussing. New approaches to this problem may be
entertained in the future, but fopr now let's get on with what we have.

Steve

From: [email-masked]
To: "Bob Jueneman" <[email-masked]>
cc: "Kurn, David" <[email-masked]>, [email-masked]
Date: Mon, 22 Feb 1999 17:13:52 -0500
Subject: Re: A web of directories
Sender: [email-masked]

     The construct you've come up with is very useful, but I don't think
it's a DN.  In fact, the LDAP variant is a legal RFC 2255 URL.
Unfortunately, X.520 doesn't have an attribute type for URL's even though
they have the ISO equivalent presentationAddress.  So if you really want to
put this into a DN, why not create a new attribute type syntax called
NetworkApplicationLocation whose syntax is a choice between a URL and a
PresentationAddress.  There's no extra ASN.1 tagging needed, because
PresentationAddress is an ASN.1 sequence, and URL is just an IA5String.
One would then define attributes with this syntax: a general one called
networkApplicationLocation and a more specific one called referenceLocation
or directoryLocation.  The value of directoryLocation in a DN would just be
the leading part (through port number) of the LDAP URL.
     In the case of a certificate, it's simpler and better just to put the
full URL, including underlying DN, into issuerAltName or subjectAltName.

          Tom Gindin

"Bob Jueneman" <[email-masked]> on 02/22/99 02:37:45 PM

To:   Tom Gindin/Watson/IBM, "Kurn, David" <[email-masked]>
cc:   [email-masked]
Subject:  A web of directories

Was: Re: Finding PKIX Servers!

Tom and David,

Sometimes the simplest ideas solve very difficult problems,
and then you kick yourself for not having thought of it earlier.

For years I have been troubled by the fact that I couldn't
find a way of dealing with a residential person's DN, when
there wasn't a monopoly directory service provider or even
a de facto name registration authority.

If my DN is c=US, st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481,
how can anyone find that entry in a directory if the state of
Utah doesn't provide a centralized directory service?  Lots
of directory service providers might actually include or list
that DN in their directory, including the US Post Office,
the electric company, the gas company, several telephone
companies, my ISP, etc., etc., not to mention the Utah
Department of Wildlife Management that issued me a
fishing license, my health insurance company, and probably
the FBI, the Social Security Administration and sundry
other agencies who maintain some kind dossier, not to
mention VeriSign who issued me a certificate, but how can
anyone find them if they don't know that fact in advance?

The solution to this problem which now seems increasingly
obvious and desirable is that the DN itself should include an
optional reference to the directory service provider which
does contain that DN, i.e., a URL to the
directory itself.

Because the allowable PKIX name forms allow the use of a URL,
my first thought was to simply list the DN in the form of an LDAP URL:
LDAP://ldap.verisign.com/c=US,st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481.

But to paraphrase Richard Nixon, we could do that, but it
would be wrong.

We shouldn't force all directory queries into one particular
format and protocol, especially one as restrictive as LDAP.

Instead, I propose creating a new optional attribute, called
directoryProvider, that would normally be the first RDN in the
DN, at least when the DN is expressed within a certificate or
in some other context that is external to the directory itself,
e.g., as a reference to the originator's name and certificate
in an S/MIME message.

The tricky part of the definition is that the directoryProvider
attribute could conceivably be IMPLICIT within the directory
that actually contains the rest of the RDN sequence, but
could be used as an explicit reference for chaining and/or
referral within or by a directory that did not contain the rest
of the RDN sequence.

I'll let someone more expert in directories and ASN.1 suggest
how to best encode that thought, and also explore the
implications, but roughly what I have in mind is something
like the following, recognizing that there may be improvements
possible in these constructs or the way they are encoded:

<  forgiveUsOurASN.1Transgressions ::= ON   >

DirectoryProvider ::= SEQUENCE {
          directoryAccessProtocol  DirectoryAccessProtocol,
          } OPTIONAL

DirectoryAccessProtocol  CHOICE {
           [0]  ldap        PData ("LDAP://", dnsD, ldapPort#   )

           [1]  dap         PData  ("DAP://", dnsD, dapPort#)
OPTIONAL,
           [2]  dsp          PData  ("DSP://" dnsD, dspPort#)
OPTIONAL,
           [3]  http          PData  ("HTTP://", dnsD, httpPort#)
OPTIONAL,
           [4]  https        PData  ("HTTPS://", dnsD, httpsPort#)
OPTIONAL,
           [5]  otherAP   Pdata  OPTIONAL }     -- reserved for
expansion and/or proprietary protocols

PData  SEQUENCE {
     protocolName    PrintableString,
     dnsD                  DnsD,
     separator            PrintableString ":"
     portNumber        INTEGER}

DnsD ::= DNSName                -- DNS name of the directory service
provider's server
                                                             --    for
the named protocol.

By providing support for multiple directory access protocols, the
directory service provider can offer a choice of methods to someone
who needs to find something in that directory.

Presumably most browsers would either use LDAP or HTTP, assuming
the directory provider offers those services.

But the directory client would not be forced to go directly to the
named
directory.

Instead, the more reasonable and encouraged behavior would be for
the client to first try to find the information in the client's own
personal
directory or cache, ignoring the directory provider information, and
then
in the user's own organization's directory, again ignoring the
directory provider
information, and only if unsuccessful would it be necessary to go to
(one or more of) the listed directory service(s).

Assuming that the user's organization directory supports X.500,
that directory should be able to chain directly to the other Directory
Service Agent using the DSP protocol, even though the original query
might have come in via LDAP or HTTP to a directory front-end.
But if for some reason the user's DSA does not support chaining, it
can
bounce the request back to the client, which can then do referral to
the next directory service provider protocol in the set that it
supports.

If we only had to deal with a single name in a certificate, for
example
the Issuer, there would be a considerable advantage in making this
attribute completely separate, rather than including the attribute
within the DN itself.  But including a set or sequence of directory
provider names clearly points to a directory which can be assumed
to have implemented the appropriate schema for the RDN attributes
that make up the DN, and it will work for alternateSubjectNames
that are in the form of a DN as well.

Perhaps more importantly, by extending the DN in this manner, the
scheme works for references to DNs that are outside of either a
certificate or a directory construct.  For example, I would hope that
I could receive a signed S/MIME message that only identified the
originator by his DN, and then go look up that DN without having
to have the certificates sent down the line to me every time.

Finally, it is assumed that the client understands the various
protocols,
and is responsible for converting the standard DN attribute syntax into

whatever form the protocol requires. Ideally, the client should also
be capable of doing referral, so that if the first directory provider
that is
tried is unavailable or uses a directory access protocol which the
client doesn't support, the client can move on to the next in the set
or sequence.

Some examples might make this clearer. I'll use a business card type
of
output of the protocol string translation for simplicity:

LDAP://directory.verisign.com/c=US,o="XYZ Corp.", cn="John Smith"

DAP://voter.ut.us/c=US, st=UT, l=Provo, cn="Robert R. Jueneman"

http://adblitz.yahoo.com/c=US, rfc822="[email-masked]"

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> <[email-masked]> 02/22/99 09:51AM >>>
     I don't think the location of an LDAP server should be mandatory,
but
an LDAP URL would be a reasonable option within issuerAltName.  While
the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer
if"
points, but I think he has identified a real need in our efforts to
deploy
PKI.

Ignoring, for the moment, how I obtained Bob's key-encryption cert in
the
first place, there are two other places I must go to before I can
evaluate
trust.

1)  I must find the certificate of the issuer (signer) of the
certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service
address
(DNS name) for each is specified in all PKI certs.  Call it optional
(to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked]
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an
optional
attribute
in a certificate that is associated with the Issuer's name somehow,
one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the
attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of
alternateSubjectName, or
it
could be some other alternateSubjectName attribute, or some other
attribute
entirely.

But is there at least some agreement about the potential utility of
this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Mon, 22 Feb 1999 14:45:40 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: A web of directories
Sender: [email-masked]

So, isn't the burden on the CA to include what they need for folks that need to rely on the certificates that they issue?  Private CAs may issue certificates with no linkage to them because they do not wish their certs used outside the domain of trust in which they were issued.

If a CA issues certs to be used in other domains, then the issuing CA needs to ascertain that the other domains or their CA can route requests from the relying parties in those domains back to themselves.

It just seems that this discussion may be trying to solve a problem that won't exist, or, if it does exist, raises competancy (and trust) questions about the CA issuing certs that are intended to be "global" without including the CRL distribution point in the certs they issue.  The alternative for bridging non-global (private) PKIs would most likely have the CAs that would accept the foreign certificates into their domain of trust building the interface or validation process into the system for their subscribers that act as relying parties.

I think that the main problems arising in this discussion come from the perception that the relying party is the source of trust, not the CAs (theirs or the correspondent's issuer or some trusted third party that one or both CAs subscribe to).

If, in Bob's analogy, one were to set up a global directory to whihc all could go, search, retrieve certs and CRLS, it still comes down to the relying party's CA and issuing CA subscribing to or authorizing use of such third party directory for relying on their certificates, thus CRL or OCSP distribution points in their issued certs.

Quite often, the relying party would go into theor own trust domain (i.e., their issuing CA) to let the CA sort out all of the problems with bridging domains of trust transparent to themselves.

The relying party should, in my opinion, always go to THEIR trusted source to see if they are including the received cert and indemnifying them from the pitfalls of a bad or revoked cert.

This trust issue is the crux of any PKI.  If any relying party gets to choose their own trust domains and can't find the source of trust on a received cert, then maybe that is a good thing and they are not supposed to be trusting that cert outside of its own domain of trust?

Michael

>>> "Kurn, David" <[email-masked]> 02/22/99 02:28PM >>>
Mike

Of course, if you *know* it's from the State of Utah.  But, let's consider
that I send you mail.  You have no idea who/what I am, so you look at my
signature certificate and try to deduce something from it.  Maybe if you're
a human being and bring to the table lots of context, you can guess where to
look for CRL,s or for the CA's web site, etc.  But, if you are a computer
program, it would be a lot easier if the certificate stated:

  To find the CRL and other stuff of the CA that issued me, please look in
this <URL or URI or something>.

David

-----Original Message-----
From: Mike Smith [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 12:48 PM
To: [email-masked]; [email-masked]; [email-masked] 
Cc: [email-masked] 
Subject: Re: A web of directories

Bob:

If you received a certificate from State of Utah for your drivers license,
fish and game or whatever, then shouldn't the CA that issued the cert
support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not
practical for any entity, whether corporate or human or animal (e.g.,
issuing a certificate of authenticity for a thoroughbred race horse with
it's DNA signed by the CA, or some such future application with biometric
filters as part of the biometric certificate authentication to activate the
information system that actually processes the "signature" of the entity
(say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more
business for our CA service).

Michael

From: "Kurn, David" <[email-masked]>
To: "'Mike Smith'" <[email-masked]>, "Kurn, David" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: A web of directories
Date: Mon, 22 Feb 1999 13:28:36 -0800
Sender: [email-masked]

Mike

Of course, if you *know* it's from the State of Utah.  But, let's consider
that I send you mail.  You have no idea who/what I am, so you look at my
signature certificate and try to deduce something from it.  Maybe if you're
a human being and bring to the table lots of context, you can guess where to
look for CRL,s or for the CA's web site, etc.  But, if you are a computer
program, it would be a lot easier if the certificate stated:

  To find the CRL and other stuff of the CA that issued me, please look in
this <URL or URI or something>.

David

-----Original Message-----
From: Mike Smith [mailto:[email-masked]]
Sent: Monday, February 22, 1999 12:48 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: A web of directories

Bob:

If you received a certificate from State of Utah for your drivers license,
fish and game or whatever, then shouldn't the CA that issued the cert
support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not
practical for any entity, whether corporate or human or animal (e.g.,
issuing a certificate of authenticity for a thoroughbred race horse with
it's DNA signed by the CA, or some such future application with biometric
filters as part of the biometric certificate authentication to activate the
information system that actually processes the "signature" of the entity
(say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more
business for our CA service).

Michael

Date: Mon, 22 Feb 1999 16:25:30 -0500
To: "Bob Jueneman" <[email-masked]>
From: Francois Rousseau <[email-masked]>
Subject: RE: Finding PKIX Servers!
Cc: [email-masked]
Sender: [email-masked]

Bob,

I agree with the concept you proposed although such an extension will
again make each subject's certificate bigger. I think that a new access
method under the authority information access extension could probably
meet your requirement:

<paraindent><param>left</param>AuthorityInfoAccessSyntax  ::=

</paraindent><paraindent><param>left,left</param>SEQUENCE SIZE (1..MAX)
OF AccessDescription

</paraindent><paraindent><param>left</param>

AccessDescription  ::=  SEQUENCE {

</paraindent><paraindent><param>left,left</param>accessMethod         
OBJECT IDENTIFIER,

accessLocation        GeneralName  }

</paraindent><paraindent><param>left</param>

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-repository OBJECT IDENTIFIER ::= { id-ad TBD }

Where this id-ad-repository OID is used to associate an Internet style
identity for the location of the repository to retrieve the issuer's
certificate in cases where such a location is not related to the issuer's
name.

</paraindent>

If this access location would happen to change for any reason before
certificates using this access method have expired then all these
certificates would have to be revoked and reissued unless two different
access locations could be maintained during the transition period.

Francois Rousseau

AEPOS Technologies

Bob Jueneman wrote:

[snip]

>So I'll say again, wouldn't it be a Good Thing if we could have an
optional attribute

>in a certificate that is associated with the Issuer's name somehow, one
that would 

>provide the DNS name of an LDAP server that contains the Issuer's
certificate?

>

>At this point in time, I don't care particularly what form the attribute
takes -- it could be

>an agreed-upon semantics for DNS name as a form of alternateSubjectName,
or it 

>could be some other alternateSubjectName attribute, or some other
attribute entirely.

>

>But is there at least some agreement about the potential utility of this
concept?

>

>Bob

>

>Robert R. Jueneman

>Security Architect

>Network Security Development

>Novell, Inc.

>122 East 1700 South

>Provo, UT 84606

>[email-masked]

>1-801-861-7387

>

>

Date: Mon, 22 Feb 1999 13:47:51 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: A web of directories
Sender: [email-masked]

Bob:

If you received a certificate from State of Utah for your drivers license, fish and game or whatever, then shouldn't the CA that issued the cert support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not practical for any entity, whether corporate or human or animal (e.g., issuing a certificate of authenticity for a thoroughbred race horse with it's DNA signed by the CA, or some such future application with biometric filters as part of the biometric certificate authentication to activate the information system that actually processes the "signature" of the entity (say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more business for our CA service).

Michael

>>> "Bob Jueneman" <[email-masked]> 02/22/99 12:37PM >>>
Was: Re: Finding PKIX Servers!

Tom and David,

Sometimes the simplest ideas solve very difficult problems, 
and then you kick yourself for not having thought of it earlier.

For years I have been troubled by the fact that I couldn't 
find a way of dealing with a residential person's DN, when 
there wasn't a monopoly directory service provider or even
a de facto name registration authority.

If my DN is c=US, st=UT, 
cn="Robert R. Jueneman"+driversLicense=159975481,
how can anyone find that entry in a directory if the state of 
Utah doesn't provide a centralized directory service?  Lots 
of directory service providers might actually include or list
that DN in their directory, including the US Post Office, 
the electric company, the gas company, several telephone 
companies, my ISP, etc., etc., not to mention the Utah 
Department of Wildlife Management that issued me a 
fishing license, my health insurance company, and probably 
the FBI, the Social Security Administration and sundry 
other agencies who maintain some kind dossier, not to
mention VeriSign who issued me a certificate, but how can 
anyone find them if they don't know that fact in advance?  

The solution to this problem which now seems increasingly 
obvious and desirable is that the DN itself should include an
optional reference to the directory service provider which 
does contain that DN, i.e., a URL to the 
directory itself.

Because the allowable PKIX name forms allow the use of a URL,
my first thought was to simply list the DN in the form of an LDAP URL:
LDAP://ldap.verisign.com/c=US,st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481.

But to paraphrase Richard Nixon, we could do that, but it 
would be wrong.

We shouldn't force all directory queries into one particular
format and protocol, especially one as restrictive as LDAP.

Instead, I propose creating a new optional attribute, called 
directoryProvider, that would normally be the first RDN in the 
DN, at least when the DN is expressed within a certificate or 
in some other context that is external to the directory itself, 
e.g., as a reference to the originator's name and certificate 
in an S/MIME message.

The tricky part of the definition is that the directoryProvider
attribute could conceivably be IMPLICIT within the directory 
that actually contains the rest of the RDN sequence, but 
could be used as an explicit reference for chaining and/or 
referral within or by a directory that did not contain the rest 
of the RDN sequence.

I'll let someone more expert in directories and ASN.1 suggest
how to best encode that thought, and also explore the 
implications, but roughly what I have in mind is something 
like the following, recognizing that there may be improvements 
possible in these constructs or the way they are encoded:

<  forgiveUsOurASN.1Transgressions ::= ON   >

DirectoryProvider ::= SEQUENCE {
          directoryAccessProtocol  DirectoryAccessProtocol,
          } OPTIONAL

DirectoryAccessProtocol  CHOICE {
           [0]  ldap        PData ("LDAP://", dnsD, ldapPort#   )             
           [1]  dap         PData  ("DAP://", dnsD, dapPort#)        OPTIONAL,     
           [2]  dsp          PData  ("DSP://" dnsD, dspPort#)          OPTIONAL,     
           [3]  http          PData  ("HTTP://", dnsD, httpPort#)      OPTIONAL,    
           [4]  https        PData  ("HTTPS://", dnsD, httpsPort#)  OPTIONAL,   
           [5]  otherAP   Pdata  OPTIONAL }     -- reserved for expansion and/or proprietary protocols

PData  SEQUENCE {
     protocolName    PrintableString,
     dnsD                  DnsD,
     separator            PrintableString ":"
     portNumber        INTEGER}

DnsD ::= DNSName                -- DNS name of the directory service provider's server 
                                                             --    for the named protocol.

By providing support for multiple directory access protocols, the 
directory service provider can offer a choice of methods to someone
who needs to find something in that directory.

Presumably most browsers would either use LDAP or HTTP, assuming 
the directory provider offers those services.

But the directory client would not be forced to go directly to the named 
directory.

Instead, the more reasonable and encouraged behavior would be for 
the client to first try to find the information in the client's own personal 
directory or cache, ignoring the directory provider information, and then 
in the user's own organization's directory, again ignoring the directory provider
information, and only if unsuccessful would it be necessary to go to 
(one or more of) the listed directory service(s).

Assuming that the user's organization directory supports X.500,
that directory should be able to chain directly to the other Directory
Service Agent using the DSP protocol, even though the original query 
might have come in via LDAP or HTTP to a directory front-end.
But if for some reason the user's DSA does not support chaining, it can
bounce the request back to the client, which can then do referral to 
the next directory service provider protocol in the set that it supports.

If we only had to deal with a single name in a certificate, for example
the Issuer, there would be a considerable advantage in making this
attribute completely separate, rather than including the attribute
within the DN itself.  But including a set or sequence of directory
provider names clearly points to a directory which can be assumed 
to have implemented the appropriate schema for the RDN attributes 
that make up the DN, and it will work for alternateSubjectNames 
that are in the form of a DN as well.  

Perhaps more importantly, by extending the DN in this manner, the 
scheme works for references to DNs that are outside of either a 
certificate or a directory construct.  For example, I would hope that
I could receive a signed S/MIME message that only identified the 
originator by his DN, and then go look up that DN without having 
to have the certificates sent down the line to me every time.

Finally, it is assumed that the client understands the various protocols, 
and is responsible for converting the standard DN attribute syntax into 
whatever form the protocol requires. Ideally, the client should also
be capable of doing referral, so that if the first directory provider that is
tried is unavailable or uses a directory access protocol which the 
client doesn't support, the client can move on to the next in the set
or sequence.

Some examples might make this clearer. I'll use a business card type of
output of the protocol string translation for simplicity:

LDAP://directory.verisign.com/c=US,o="XYZ Corp.", cn="John Smith"

DAP://voter.ut.us/c=US, st=UT, l=Provo, cn="Robert R. Jueneman"

http://adblitz.yahoo.com/c=US, rfc822="[email-masked]" 

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

>>> <[email-masked]> 02/22/99 09:51AM >>>
     I don't think the location of an LDAP server should be mandatory, but
an LDAP URL would be a reasonable option within issuerAltName.  While the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked] 
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer if"
points, but I think he has identified a real need in our efforts to deploy
PKI.

Ignoring, for the moment, how I obtained Bob's key-encryption cert in the
first place, there are two other places I must go to before I can evaluate
trust.

1)  I must find the certificate of the issuer (signer) of the certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service address
(DNS name) for each is specified in all PKI certs.  Call it optional (to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked] 
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or
it
could be some other alternateSubjectName attribute, or some other attribute
entirely.

But is there at least some agreement about the potential utility of this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             

From: "Kurn, David" <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: A web of directories
Date: Mon, 22 Feb 1999 12:01:50 -0800
Sender: [email-masked]

Bob et al

Nice generalization.  Of course, you have just re-invented a URI (or is it
URL), so why not in general allow the syntax:

<name-of-protocol>://<ip-address-and-maybe-portno>/<stuff-interpreted-by-the
-server

as the access to the certificate lookup service.  Obvious candidates are
ldap: http: https:

with "ldap:" probably being the default.

I have a problem with presuming any kind of default directory pointer (in
general) because you have no idea where or who will be using your
certificates.  As a metaphor, consider that I send you a snail-mail message,
and list on the top-left of the envelope a return address like:

  123 First Street
  Springfield

Now, as you may know, there are at least 26 instances of Springfield in the
US, but since you're in Utah, you should assume it means "Springfield Utah"?
Hmmm.... Bad idea.

I have no idea if there's any hope in our lifetime of affecting standards,
but at least the discussion is interesting.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, February 22, 1999 11:38 AM
To: Kurn, David; [email-masked]
Cc: [email-masked]
Subject: A web of directories

<snip>

Date: Mon, 22 Feb 1999 12:37:45 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: A web of directories
Sender: [email-masked]

Was: Re: Finding PKIX Servers!

Tom and David,

Sometimes the simplest ideas solve very difficult problems, 
and then you kick yourself for not having thought of it earlier.

For years I have been troubled by the fact that I couldn't 
find a way of dealing with a residential person's DN, when 
there wasn't a monopoly directory service provider or even
a de facto name registration authority.

If my DN is c=US, st=UT, 
cn="Robert R. Jueneman"+driversLicense=159975481,
how can anyone find that entry in a directory if the state of 
Utah doesn't provide a centralized directory service?  Lots 
of directory service providers might actually include or list
that DN in their directory, including the US Post Office, 
the electric company, the gas company, several telephone 
companies, my ISP, etc., etc., not to mention the Utah 
Department of Wildlife Management that issued me a 
fishing license, my health insurance company, and probably 
the FBI, the Social Security Administration and sundry 
other agencies who maintain some kind dossier, not to
mention VeriSign who issued me a certificate, but how can 
anyone find them if they don't know that fact in advance?  

The solution to this problem which now seems increasingly 
obvious and desirable is that the DN itself should include an
optional reference to the directory service provider which 
does contain that DN, i.e., a URL to the 
directory itself.

Because the allowable PKIX name forms allow the use of a URL,
my first thought was to simply list the DN in the form of an LDAP URL:
LDAP://ldap.verisign.com/c=US,st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481.

But to paraphrase Richard Nixon, we could do that, but it 
would be wrong.

We shouldn't force all directory queries into one particular
format and protocol, especially one as restrictive as LDAP.

Instead, I propose creating a new optional attribute, called 
directoryProvider, that would normally be the first RDN in the 
DN, at least when the DN is expressed within a certificate or 
in some other context that is external to the directory itself, 
e.g., as a reference to the originator's name and certificate 
in an S/MIME message.

The tricky part of the definition is that the directoryProvider
attribute could conceivably be IMPLICIT within the directory 
that actually contains the rest of the RDN sequence, but 
could be used as an explicit reference for chaining and/or 
referral within or by a directory that did not contain the rest 
of the RDN sequence.

I'll let someone more expert in directories and ASN.1 suggest
how to best encode that thought, and also explore the 
implications, but roughly what I have in mind is something 
like the following, recognizing that there may be improvements 
possible in these constructs or the way they are encoded:

<  forgiveUsOurASN.1Transgressions ::= ON   >

DirectoryProvider ::= SEQUENCE {
          directoryAccessProtocol  DirectoryAccessProtocol,
          } OPTIONAL

DirectoryAccessProtocol  CHOICE {
           [0]  ldap        PData ("LDAP://", dnsD, ldapPort#   )             
           [1]  dap         PData  ("DAP://", dnsD, dapPort#)        OPTIONAL,     
           [2]  dsp          PData  ("DSP://" dnsD, dspPort#)          OPTIONAL,     
           [3]  http          PData  ("HTTP://", dnsD, httpPort#)      OPTIONAL,    
           [4]  https        PData  ("HTTPS://", dnsD, httpsPort#)  OPTIONAL,   
           [5]  otherAP   Pdata  OPTIONAL }     -- reserved for expansion and/or proprietary protocols

PData  SEQUENCE {
     protocolName    PrintableString,
     dnsD                  DnsD,
     separator            PrintableString ":"
     portNumber        INTEGER}

DnsD ::= DNSName                -- DNS name of the directory service provider's server 
                                                             --    for the named protocol.

By providing support for multiple directory access protocols, the 
directory service provider can offer a choice of methods to someone
who needs to find something in that directory.

Presumably most browsers would either use LDAP or HTTP, assuming 
the directory provider offers those services.

But the directory client would not be forced to go directly to the named 
directory.

Instead, the more reasonable and encouraged behavior would be for 
the client to first try to find the information in the client's own personal 
directory or cache, ignoring the directory provider information, and then 
in the user's own organization's directory, again ignoring the directory provider
information, and only if unsuccessful would it be necessary to go to 
(one or more of) the listed directory service(s).

Assuming that the user's organization directory supports X.500,
that directory should be able to chain directly to the other Directory
Service Agent using the DSP protocol, even though the original query 
might have come in via LDAP or HTTP to a directory front-end.
But if for some reason the user's DSA does not support chaining, it can
bounce the request back to the client, which can then do referral to 
the next directory service provider protocol in the set that it supports.

If we only had to deal with a single name in a certificate, for example
the Issuer, there would be a considerable advantage in making this
attribute completely separate, rather than including the attribute
within the DN itself.  But including a set or sequence of directory
provider names clearly points to a directory which can be assumed 
to have implemented the appropriate schema for the RDN attributes 
that make up the DN, and it will work for alternateSubjectNames 
that are in the form of a DN as well.  

Perhaps more importantly, by extending the DN in this manner, the 
scheme works for references to DNs that are outside of either a 
certificate or a directory construct.  For example, I would hope that
I could receive a signed S/MIME message that only identified the 
originator by his DN, and then go look up that DN without having 
to have the certificates sent down the line to me every time.

Finally, it is assumed that the client understands the various protocols, 
and is responsible for converting the standard DN attribute syntax into 
whatever form the protocol requires. Ideally, the client should also
be capable of doing referral, so that if the first directory provider that is
tried is unavailable or uses a directory access protocol which the 
client doesn't support, the client can move on to the next in the set
or sequence.

Some examples might make this clearer. I'll use a business card type of
output of the protocol string translation for simplicity:

LDAP://directory.verisign.com/c=US,o="XYZ Corp.", cn="John Smith"

DAP://voter.ut.us/c=US, st=UT, l=Provo, cn="Robert R. Jueneman"

http://adblitz.yahoo.com/c=US, rfc822="[email-masked]" 

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> <[email-masked]> 02/22/99 09:51AM >>>
     I don't think the location of an LDAP server should be mandatory, but
an LDAP URL would be a reasonable option within issuerAltName.  While the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked] 
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer if"
points, but I think he has identified a real need in our efforts to deploy
PKI.

Ignoring, for the moment, how I obtained Bob's key-encryption cert in the
first place, there are two other places I must go to before I can evaluate
trust.

1)  I must find the certificate of the issuer (signer) of the certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service address
(DNS name) for each is specified in all PKI certs.  Call it optional (to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked] 
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or
it
could be some other alternateSubjectName attribute, or some other attribute
entirely.

But is there at least some agreement about the potential utility of this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

Date: Mon, 22 Feb 1999 12:08:46 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Qualified Certificates draft - Country name
Sender: [email-masked]

Deja vu all over again.

As in nearly all of these issues, it is important to understand what 
you are trying to accomplish, and in particular what the semantics
are.

I can think of three or four reasons why one might want to have a country
listed in a DN:

1. To provide a globally unambiguous name or reference.  Generally 
speaking, neither corporate names nor geopolitical names are unique
across countries -- Georgia could be a state within the United States, or
a state within the former USSR. IBM Corp is probably IBM Corp 
throughout the world, because they are vigilant about enforcing their
trademark.  But if the Laird McDonald has anything to say about it,
McDonalds may be a protected name in every country but Scotland.

2.  To provide a pointer to the country where an organization is incorporated.
This is related to the unambiguous naming problem, but it may also have a legal
connotation regarding choice of laws, legal/cultural nomenclature and other
references, as well as providing some indication of where you should send any
official legal notices.  In the case of a residential person, this might be used to 
indicate the citizenship of the individual (in which case, what should be done 
about those who have dual citizenship?), which might also have legal and 
tax consequences.

3.  To define the particular location where some entity actually resides and/or 
does business.  For example, I don't believe that Novell has a subsidiary that
is incorporated in Saudi Arabia, but I wouldn't be surprised if we had a sales office
there.  Should we then say c=Saudi Arabia, o=Novell?  Probably not.  Instead,
maybe c=US, o=Novell, Inc., ou="Europe, Africa, Middle East", c=Saudi Arabia, 
ou="Sales Office 123" should be used.  In the case of a residential person, 
the country code might indicate his country of residence, at least for the purposes
of this certificate.  

If you really want to go off the deep end, consider someone 
who has dual citizenship in one of the two countries, but the other country refuses
to recognize the other country, and therefore refuses to recognize the individual's
second citizenship.  The individual maintains a primary domicile for purposes of 
taxes, driver's licenses, etc., and intends eventually to return there, but that 
domicile is in yet a third country.  The individual is presently residing in a 
fourth country on a temporary basis -- perhaps attending school there. 
But while visiting a fifth country for three months on a back-packing 
vacation with no fixed address, he decides he needs an Internet 
connection and subscribes to one located in a sixth country, which 
he accesses via an Iridium link.  What country code or codes
should he include in his qualified certificate?

Once you have answered that question, consider what to use in the 
case of a stateless person such as who was a citizen of a country which 
no longer exists, who has no permanent domicile, but who is presently 
living and working on an off-shore oil tower located in international waters.

Oh, and don't forget such interesting anomalies as the Federated Islands 
of Micronesia, which operate under a compact of free association with 
the United States, and have a postal code corresponding to that of a state 
or territory within the US, but yet they are a sovereign country.

And I haven't even mentioned international organizations, some of which 
fall under the auspices of the United Nations and some of which do not,
but yet are not subsidiaries of an organization that is incorporated in a
traditional country.  A multinational organization of scientists living in
Antarctica would be an interesting case to speculate about, for example,
in addition to NATO, the World Health Organization, etc.

What problem are you trying to solve?

Bob

>>> <[email-masked]> 02/22/99 10:05AM >>>
     If the major reason for DN's without country names is to allow
international organizations to avoid specifying a home country, one could
define a country code (probably "00") to mean that the organization
specified is international.  This is approximately what X.400 did with the
Administrative Management Domain field, which was originally mandatory.  If
corporations are to be permitted to declare themselves trans-national for
directory purposes (although very possibly they should not), they would get
a different numeric country code.

          Tom Gindin

These opinions are mine, and are not necessarily those of my employer.

From: [email-masked]
To: Stefan Santesson <[email-masked]>
cc: "Miklos, Sue A." <[email-masked]>, [email-masked]
Date: Mon, 22 Feb 1999 12:05:21 -0500
Subject: RE: Qualified Certificates draft - Country name
Sender: [email-masked]

     If the major reason for DN's without country names is to allow
international organizations to avoid specifying a home country, one could
define a country code (probably "00") to mean that the organization
specified is international.  This is approximately what X.400 did with the
Administrative Management Domain field, which was originally mandatory.  If
corporations are to be permitted to declare themselves trans-national for
directory purposes (although very possibly they should not), they would get
a different numeric country code.

          Tom Gindin

These opinions are mine, and are not necessarily those of my employer.

From: [email-masked]
To: "Kurn, David" <[email-masked]>
cc: [email-masked]
Date: Mon, 22 Feb 1999 11:51:41 -0500
Subject: RE: Finding PKIX Servers!
Sender: [email-masked]

     I don't think the location of an LDAP server should be mandatory, but
an LDAP URL would be a reasonable option within issuerAltName.  While the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer if"
points, but I think he has identified a real need in our efforts to deploy
PKI.

Ignoring, for the moment, how I obtained Bob's key-encryption cert in the
first place, there are two other places I must go to before I can evaluate
trust.

1)  I must find the certificate of the issuer (signer) of the certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service address
(DNS name) for each is specified in all PKI certs.  Call it optional (to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked]
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or
it
could be some other alternateSubjectName attribute, or some other attribute
entirely.

But is there at least some agreement about the potential utility of this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

From: "Duran, Robert" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: DN in a cert
Date: Mon, 22 Feb 1999 11:00:58 -0500
Sender: [email-masked]

I have a question in regards to  the DN/Subject of a certficate. Is it
acceptable generate a certificate with a DN= O=Comapny OU=People UID=UserID?
Id like to avoid CommonName becasue it may change but the UID would not (at
least in my situation)

Rob D.
Aetna -  IT Sercuirty
(860) 636-2462
[email-masked]
 <<Duran, Robert.vcf>> 

Date: Mon, 22 Feb 1999 10:39:28 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Subject: RE: Finding PKIX Servers!
Sender: [email-masked]

Would it be possible to cut out the personal sniping and get back to
discussing matters of technical substance?  (That's assuming there are 
any to be found in this topic.)

I'm sorely tempted to go find out how to implement the equivalent of a 
"kill file" for the pkix list mailings.  At this point I know of
several names that seem to fit on such a list, at least judging by the 
evidence presented by recent exchanges.

	paul

Date: Mon, 22 Feb 1999 15:49:04 +0100
To: "Miklos, Sue A." <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: RE: Qualified Certificates draft - Country name
Sender: [email-masked]

Sue,

You have a point. We have had this issue up before (with NATO as example,
brougt up by Al Arsenault) and we said "-Well lets start with countryName
mandatory and see what reactions we get"

I feel rather convinced now that countryName should NOT be mandatory.

We will discuss this issue on the next IETF meeting.

/Stefan

At 09:03 AM 2/22/99 -0500, Miklos, Sue A. wrote: 
RE: SEIS:  RE: Comments to Qualified Certificates draft 

Please forgive what may be an ignorant question, but when I saw the Country
= mandatory, I became confused.   

I am thinking about international organizations (Red Cross, NATO, etc) that
do not wish to include a country in the name, as there is no singular
country 'owning' that name space.  The implementations have left that field
blank and go directly to the Organization = element of the name.   

Is this configuration supported?  If you are only working in the individual
name space, please forgive my potentially misinformed comment.   

Sandi 

---------- 
From:   Stefan Santesson[SMTP:[email-masked]] 
Sent:   Friday, February 19, 1999 10:07 AM 
To:     Anders Rundgren 
Cc:     'SEIS-List'; [email-masked]; [email-masked] 
Subject:        SEIS:  RE: Comments to Qualified Certificates draft 

--- Message on the SEIS mailing list ([email-masked]) 

Sorry, My fault. 

You are right. Country IS mandatory. 
Guess we have to think about that. I still think it makes sence to keep it 
there. 

/Stefan 

At 03:26 PM 2/19/99 +0100, Anders Rundgren wrote: 
>Hi,  
>Verbatim from the draft: 
>
>The subject field SHALL include one of the following choices of sets of 
>mandatory attributes: 
>Choice  I:  countryName commonName 
>Choice II:  countryName givenName surname 
>
>>The CountryName attribute is optional. If you find it redundant, then leave 
>>it out. There are on the other hand many certificates that do use this 
>>attribute so I would not prevent it from being used. 
>
>So SHALL and mandatory is to be interpreted as optional?  Mandatory is 
equivalent to MUST 
>at least outside of the PKIX-world. 
>
>>The purpose of the example certificate is only to show an example of how 
>>the profile may be implemented. It does NOT imply that the present 
>>attributes SHALL be present in any speciffic application. 
>
>I just wanted to express my view that the example was "untypical" . 
>
>For those who are a little bit leaning towards the practical side of 
things it does not 
>hurt with more than one example and maybe even mention what the example
could 
>be used for.  Naturally stating that they are just an examples and should 
not be 
>interpreted as policies, rules, recommendations, or whatever. 
>
>>>On a physical card personal data may be of interest to establish the 
>>connection between the person and 
>>>the card/certificate.  But what is inside the certificate, is a different 
>>story. 
>
>>I guess I lost you here. 
>
>What I said was just that the contents of a QC do not have to match its 
container in the way a SEIS ID-card does. 
>This is indeed very interesting to discuss given all projects in the 
making (SEIS, Germany, Finland, and Estonia). 
>
>>>Just my 2 öres. 
>>(What does this mean???? ;-) ) 
>
>I think it means something like "My opinion for what it is worth" 
>
>Anders Rundgren 
>Senior Internet e-commerce Architect 
>
>
>
------------------------------------------------------------------- 
Stefan Santesson                <[email-masked]> 
Accurata Systemsäkerhet AB      
Lotsgatan 27 D                  Tel. +46-40 152211               
216 42  Malmö                   Fax. +46-40 150790               
Sweden                        Mobile +46-70 5247799 

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0 
------------------------------------------------------------------- 

----------------- SEIS mailing list ([email-masked]) 
Info about this list:
<http://www.nc-forum.com/seis>http://www.nc-forum.com/seis 
SEIS Contact: [email-masked] 

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

Date: Mon, 22 Feb 1999 12:28:16 +0100
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: RE: Comments to Qualified Certificates draft
Cc: Paul Koning <[email-masked]>, [email-masked], "Bob Jueneman" <[email-masked]>
Sender: [email-masked]

This sound reasonable.

Could you help me suggest what we should put into the draft.
Surname or GivenName as mandatory attribute for registered name in CHOICE II.

It doesn't seem that you all have the same opinion here. My knowledge here
is unfortunately very limited.

We should though keep in mind that CHOICE I (commonName) also may be used
for any name form.

/Stefan

At 02:11 PM 2/19/99 -0500, Paul Koning wrote:
> > At 10:49 AM 2/18/99 +0100, Anders Rundgren wrote:
> >> --- Message on the SEIS mailing list ([email-masked])
> >> 
> >> Hi, >The subject field SHALL include one of the following choices
> >> of sets of
> > mandatory attributes:
> >> >Choice I: countryName commonName >Choice II: countryName
> >> givenName surname
>
> > One other comment.  Individuals with a single name, usually
> > rendered as a surname, are fairly common in Indonesia - and
> > possibly some other countries as well.  X.402 section
> > 18.3.12 defines a personal name with surname mandatory and
> > the other three subfields (given name, initials, and
> > generation) optional.  I believe that the Indonesian
> > situation is the reason why, and that that definition is
> > correct.
>
>Yes, the point that insisting on two part names is wrong has been made 
>before.  (It's discouraging that apparently that was ignored...)
>
>It seems more logical to consider the single name a given name (since
>that's what it is) but what the heck.
>
>On "given name, initials..." does that imply that given name is the
>first given name and initials are the starting letter of the
>subsequent given names?  If so, that's not the right definition.  Many
>people use a given name other than their first name as the name by
>which they are known, so that their full name looks like "G. Paul
>Koning".  Insisting on the first name being given in full is not
>correct.
>
>	paul
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

Date: Mon, 22 Feb 1999 11:07:17 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: Trevor Freeman <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Usage of CRL Issuing Distribution Point
Sender: [email-masked]

Steve,

You said " Hopefully we now agree that inclusion of a CDP extension in a cert
..". Not quite.

This technique only allows one case of partitioning where it can be said: for
this certificate, go there. Other schemes are not supported..

However there is a much more important concern. If we go this way we are going
to overload the content of *every* certificate. The same would apply to get
information about OCSP responders. If we are going to store certificates in
smart cards this is going to be a problem.

We should look for another solution able to solve this concern. Placing all
this administrative information in a *single* and new data structure signed by
the CA would need to be explored.

Opinions ?

Denis

> Trevor,
>
> Yes, this message thread certainly does seem to have become confused.
> Hopefully we now agree that inclusion of a CDP extension in a cert allows a
> relying party to determine whether it has the right CRL for the cert in
> question, subject to the usual CRL validation processes.  Note that, in
> this case, the relying party does not care whether there are multiple CRLs
> or not, since the the CDP extension provided the necessary pointer.
>
> Steve

From: Alan Lloyd <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 22 Feb 1999 12:28:44 +1100
Sender: [email-masked]

If one talks of respect - it has to be earnt.
Putting out comments which seem so wrong does not earn that.

Opinions can be wrong and people have different experiences and
different perspectives on things - so not is the same by all - hence the
reason for debate.

Pehaps when you state your directory experiences to those who are
working on directory service supported PKI systems - large ones, be
mindful that where you publically and wrongly   "put down" directory
services and their capabilities (in the PKI role)  that responses will
be forth coming.

	regards alan

> -----Original Message-----
> From:	Phillip M Hallam-Baker 
> Sent:	Wednesday, February 17, 1999 2:47 AM
> To:	Alan Lloyd; David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> Oh goody, protocol correctness!
> 
> 
> > Comments in line - to  more incorrect statements
> 
> > >  This is the 'directory
> > > dependent' model of PKI, I don't like that idea.
> 
> > 	Thats because I think you are not seeing the utility of
> > directory systems correctly.
> 
> Alan, if you can't respect other members of the working group
> you are completely wasting your time here.
>  

Date: Sun, 21 Feb 1999 16:34:12 -0500
To: "Peter Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: cRLIssuer names and management domain correlation
Cc: <[email-masked]>
Sender: [email-masked]

Peter,

I would assume either the default case in which the CA must have signed the
CRL, or must have issued a cert (directly) to an entity who signed the CRL
and that cert should have the keyusage restriction extsnsion set to
indicate that the key in question is to be used only for CRL signing (and I
would mark this extension critical).  In either case, it then is apparent
that the entity signing the CRL has been authorized to do so by the CA who
issued the cert with the CDP extension.

Steve

Date: Sun, 21 Feb 1999 16:33:37 -0500
To: "Phillip M Hallam-Baker" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: CMC Comments?
Cc: "Pkix" <[email-masked]>
Sender: [email-masked]

Phill,

I thought CMC extended the existing use of PKCS for cert management, and
added CMS, and so it would not seem that CMC is backwards compatible with
the primitive cert management capabilities in the vast majority of
browsers.  One may legitimately say that there is a common theme here, but
backwards compatablity seems to stretch the point.

Steve

Date: Fri, 19 Feb 1999 14:24:27 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments to Qualified Certificates draft
Sender: [email-masked]

>On "given name, initials..." does that imply that given name is the
first given name and initials are the starting letter of the
subsequent given names?  If so, that's not the right definition.  Many
people use a given name other than their first name as the name by
which they are known, so that their full name looks like "G. Paul
Koning".  Insisting on the first name being given in full is not
correct.

	paul

And don't forget Harry S (no period) Truman.  Not all single characters are
initials.

Likewise, I don't know what you do about Thai and other languages that don't use
a space as a delimiter between words.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

From: Santosh Chokhani <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Trevor Freeman <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Fri, 19 Feb 1999 15:16:42 -0500
Sender: [email-masked]

In addition, the relying party must validate the contents of the Issuing
DP (which is within the signed envelope of the CRL) against the contents
of the CDP (which is in the signed envelop of the certificate).  The
specific validation rules (once again at the risk of being redundant)
are listed in the Annex M of the X.509 9/98 PDAM.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Friday, February 19, 1999 9:56 AM
> To:	Trevor Freeman
> Cc:	[email-masked]'
> Subject:	RE: Usage of CRL Issuing Distribution Point
> 
> Trevor,
> 
> Yes, this message thread certainly does seem to have become confused.
> Hopefully we now agree that inclusion of a CDP extension in a cert
> allows a
> relying party to determine whether it has the right CRL for the cert
> in
> question, subject to the usual CRL validation processes.  Note that,
> in
> this case, the relying party does not care whether there are multiple
> CRLs
> or not, since the the CDP extension provided the necessary pointer.
> 
> Steve

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Pkix" <[email-masked]>, "David P. Kemp" <[email-masked]>
Subject: RE: CMC Comments? 
Date: Fri, 19 Feb 1999 15:24:15 -0500
Importance: Normal
Sender: [email-masked]

>I would make an analogy to the modem world, where two functionally
>similar protocols were candidates for standardization.  X2 and Flex
>both provide 56K connections, but are not interoperable.  International
>Standard V.90 also provides a 56K connection, but is not interoperable
>with either of the earlier protocols.  Modem vendors and ISP equipment
>vendors are free to include 1, 2, or all 3 of the protocols in their
>equipment, as dictated by cost and market considerations.  However,
>the V.90 standard DOES NOT require support for either X2 or Flex as
>a condition of conformance.

The modem people did provide backwards compatibility in effect, if
the modems could not agree at 56K they would back off to the previously
agreed 28.8K standard. 

>That is real Standardization.  There was big money at stake, but the
>competing participants still managed to agree on a single standard.

That is ISO model standardization, not IETF model standardization.
Remember the mantra:

	'There will be NO flag days'

Backwards compatibility is what the INTER-net is all about. When you 
have an installed base of 100 million odd clients you make sure that
the standards proposed support them wherever possible.

It does not seem unreasonable to want use the term 'CMC compatible' 
as a synonym for 'works with the stuff you bought already'. 

		Phill

From: "Peter Williams" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: cRLIssuer names and management domain correlation
Date: Fri, 19 Feb 1999 12:17:11 -0600
Sender: [email-masked]

Assume a user certificate contains a CRL distribution
point URI indication and names the expected/required issuer of
the CRL (fragment) in a manner conforming with RFC 2459.

Does the management/certification domain responsible
for reliably authenticating the user certificate need to
the same as that which reliably authenticates the issuer
of the CRL (fragment) to meet 2459 conformance
requirements?

For example:

A user certificate has cRLDistributionPoints extension identifying
 "c=US, o=IETF" as the required (DN-name-formed)
issuer of the CRL (fragment) for that cert.

To help authentication, multiple CAs (in 
multiple management domains) may all have
issued identity certificates for "c=US, o=IETF"
and all these domains may be registered in the
users system as equally valid/trusted sources of 
authentication information for objects received 
from a given URI.

Under 1422 rules, where it is the case that
multiple PCAs may have certifed the
nominal CA "c=US, o=IETF" which
issues CRLs, the relying party gets to choose which
management domain (PCA) controls
the validation of the CRL. Of course,
alternative trust chains, issued under the
rules of two different management domains,
may both authenticate the same identity
of "c=US, o=IETF".
 
If a given PKI management domain is relied upon
for verifying a user certificate's signature, but a second
domain is relied upon when validating the CRL ( which 
helps verify and validate the user certificate) does any 
subtle 2459 language or intended interpretation 
put any constraints on relying party systems for
this situation?

Peter.

Date: Fri, 19 Feb 1999 09:55:37 -0500
To: Trevor Freeman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Trevor,

Yes, this message thread certainly does seem to have become confused.
Hopefully we now agree that inclusion of a CDP extension in a cert allows a
relying party to determine whether it has the right CRL for the cert in
question, subject to the usual CRL validation processes.  Note that, in
this case, the relying party does not care whether there are multiple CRLs
or not, since the the CDP extension provided the necessary pointer.

Steve

Date: Fri, 19 Feb 1999 14:11:56 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Comments to Qualified Certificates draft
Sender: [email-masked]

 > At 10:49 AM 2/18/99 +0100, Anders Rundgren wrote:
 >> --- Message on the SEIS mailing list ([email-masked])
 >> 
 >> Hi, >The subject field SHALL include one of the following choices
 >> of sets of
 > mandatory attributes:
 >> >Choice I: countryName commonName >Choice II: countryName
 >> givenName surname

 > One other comment.  Individuals with a single name, usually
 > rendered as a surname, are fairly common in Indonesia - and
 > possibly some other countries as well.  X.402 section
 > 18.3.12 defines a personal name with surname mandatory and
 > the other three subfields (given name, initials, and
 > generation) optional.  I believe that the Indonesian
 > situation is the reason why, and that that definition is
 > correct.

Yes, the point that insisting on two part names is wrong has been made 
before.  (It's discouraging that apparently that was ignored...)

It seems more logical to consider the single name a given name (since
that's what it is) but what the heck.

On "given name, initials..." does that imply that given name is the
first given name and initials are the starting letter of the
subsequent given names?  If so, that's not the right definition.  Many
people use a given name other than their first name as the name by
which they are known, so that their full name looks like "G. Paul
Koning".  Insisting on the first name being given in full is not
correct.

	paul

From: [email-masked]
To: Stefan Santesson <[email-masked]>
cc: Anders Rundgren <[email-masked]>, ietf-pkix <[email-masked]>, "'SEIS-List'" <[email-masked]>
Date: Fri, 19 Feb 1999 12:50:39 -0500
Subject: RE: Comments to Qualified Certificates draft
Sender: [email-masked]

Stefan Santesson <[email-masked]> on 02/19/99 03:48:53 AM

To:   Anders Rundgren <[email-masked]>, ietf-pkix
      <[email-masked]>
cc:   "'SEIS-List'" <[email-masked]> (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Comments to Qualified Certificates draft

Comments in line.

At 10:49 AM 2/18/99 +0100, Anders Rundgren wrote:
>--- Message on the SEIS mailing list ([email-masked])
>
>Hi,
> >The subject field SHALL include one of the following choices of sets of
mandatory attributes:
>     >Choice  I:  countryName commonName
>     >Choice II:  countryName givenName surname

One other comment.  Individuals with a single name, usually rendered as a
surname, are fairly common in Indonesia - and possibly some other countries
as well.  X.402 section 18.3.12 defines a personal name with surname
mandatory and the other three subfields (given name, initials, and
generation) optional.  I believe that the Indonesian situation is the
reason why, and that that definition is correct.
>      snip..

Date: Fri, 19 Feb 1999 10:47:03 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: CMC Comments? 
To: [email-masked]
Cc: [email-masked], [email-masked]
Content-MD5: Qe+z82rcAfv+gYD/O4N2eA==
Sender: [email-masked]

> From: Brian LaMacchia <[email-masked]>
> To: "'Luke Koops'" <[email-masked]>
> Date: Wed, 23 Dec 1998 14:58:39 -0800
> 
> 	Is there a need to lower the bar for PKIX compliance to this level?
> 
> Obviously, the long-term goal is to use Full PKI Request and Response
> messages throughout.  However, CMC also has a goal of supporting
> industry-standard PKCS#10/7 as a subset of the protocol, so that current
> clients and servers can also participate in the CMC world.

This conformance proposal sounds more like pork-barrel politics than
standardization.

We have two alternative mechanisms for accomplishing the same purpose -
one which has been in use for some time and covers 80% (or 90%, not
to quibble over numbers) of the application space, the other has
been designed to cover 99% of the application space but is less widely
implemented.  The Full Request and Response messages were created by
and agreed to by proponents of both PKCS#10 and PKIX Part 3, and they
accommodate the needs of all interested parties.

I would make an analogy to the modem world, where two functionally
similar protocols were candidates for standardization.  X2 and Flex
both provide 56K connections, but are not interoperable.  International
Standard V.90 also provides a 56K connection, but is not interoperable
with either of the earlier protocols.  Modem vendors and ISP equipment
vendors are free to include 1, 2, or all 3 of the protocols in their
equipment, as dictated by cost and market considerations.  However,
the V.90 standard DOES NOT require support for either X2 or Flex as
a condition of conformance.

That is real Standardization.  There was big money at stake, but the
competing participants still managed to agree on a single standard.

One can accept that the differences between email protocols are so
significant that the IETF is justified in standardizing two of them,
in two different working groups.  However, it is difficult to
believe that the differences between PKCS#10 and CRMF are so great
that the IETF should mandate support for both of them.
Reasonable people can disagree over whether the single IETF standard
should be the 80% or the 99% version.  But saying "each has its place,
so let's make them both MUSTs for servers" is a cop out.

> The basic idea is as follows (perhaps we should add a Conformance section to
> the draft to explicitly call this out):
> 
> A minimally-compliant CMC server:
> a) MUST accept a Full PKI Request message
> 	i) MUST accept CRMF Request Bodies within a Full PKI Request
> 	ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request
> b) MUST accept a Simple Enrollment Request message
> c) MUST be able to return a Full PKI Response.  (A Full PKI Response is
> always a valid response, but for interoperability with downlevel clients a
> compliant server SHOULD use the Simple Enrollment Response whenever
> possible.)
> 
> A minimally-complaint CMC client:
> a) MAY use either the Simple Enrollment Message or the Full PKI Request.
> 	i) clients MUST use PKCS#10 with the Simple Enrollment Message
> 	ii) clients MAY use either PKCS#10 or CRMF with the Full PKI Request
> b) MUST understand the Simple Enrollment Response.
> c) MUST understand the Full PKI Response.

That would be a fine proposal (with the MUSTs changed to lower-case
shoulds) if CMC were an Informational RFC intended to facilitate
interoperability between PKIX and PKCS#10 implementations.

But if CMC is intended to be a Standards Track RFC, it should say
simply:

   A minimally-compliant CMC server
     a) MUST accept a Full PKI Request message with a CRMF Request Body
     b) MUST be able to return a Full PKI Response

   A minimally-compliant CMC client:
     a) MUST generate a Full PKI Request with a CRMF Request Body
     b) MUST understand the Full PKI Response
     
   Compliant CMC servers and clients MAY (or SHOULD) support the following
   additional messages ...

Current [PKCS#10-based] clients and servers will be able to
participate in this CMC world as long as vendors find it useful to
support two standards in their products.

Date: Fri, 19 Feb 1999 13:42:14 +0100
From: Juergen Walter <[email-masked]>
Reply-To: [email-masked]
To: Stefan Santesson <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: Comments on Qualified Certificates draft
Sender: [email-masked]

Sorry for the delay.

Comments in line,

Stefan Santesson wrote:
> 
> Thank you for your comments,
> 
> I have been busy for a while so forgive my late reply.
> 
> I give some short comments in-line.
> 
> At 06:32 PM 2/11/99 +0100, Juergen Walter wrote:
> >I would like to add some comments to the QC draft. The topics are the
> >following
> >
> >1) Properties of Qualified certificates,
> >2) CPS and the semantics of name fields,
> >3) countryName usage,
> >4) commonName
> >5) Security Considerations.
> >
> >Comments 1),2),4) are more or less editorial, while comments 3), 5) are
> >more general.
> >
> >1) Properties of Qualified Certificates
> >
> >"2.1  Properties
> >
> >   A Qualified Certificate as defined in this standard is assumed to
> >   have the following properties:
> >
> >   - Issued by a CA that makes a public statement that the certificate
> >   serves the purpose of a Qualified Certificate, as discussed in sec-
> >   tion 2.3
> >   - Indicate a certificate policy consistent with liabilities, prac-
> >   tices and procedures undertaken by the CA, as discussed in 2.4
> >   - Be issued to a natural person (living human being).
> >   - Contain an unmistakable identity based on a pseudonym name or a
> >   real name of the subject.
> >   - Exclusively indicates non-repudiation key usage for the certified
> >   public key.
> >   - Fully complies with the certificate profile defined in RFC 2459"
> >[PKIX-QC]
> >
> >The last three properties should be replaced by
> >   - Fully complies with the certificate profile defined in RFC 2459 and
> >chapter 3 of    this document.
> >
> 
> Actually it should be the other way around. The reference to rfc 2459
> should not be here. The meaning of this section is to say something about
> what makes a certificate a "Qualified Certificate". rfc 2459 and this
> profile does not make a certificate a "Qualified certificate" they are just
> a usable format for expressing them.

I beg to differ. This draft is part of PKIX work. Therefore, the
reference to rfc 2459 is necessary. In the context of PKIX the draft
should address when a PKIX profiled certificate becomes a qualified
certificate. The extensions in chapter 3 may be meaningless in the
context of other certificate profiles or definitions (eg EDIFACT).
Sure, you are free to define a qualified certificate independently of
the profile. But personally, I think this "abstract" definition has to
be tailored by the draft for PKIX purposes.

> 
> >The profile of Qualified Certificates is defined in chapter 3 of
> >[PKIX-QC]. The fourth and fifth property do not cover the profile given
> >in chapter 3 completely.
> >
> >The security requirements defined in chapter 4 should be linked
> >explicitly. Therefore the following property should be added:
> >
> >   - Issued by a CA in compliance with reasonable securitity measures
> >following the security considerations in chapter 4.
> >
> >
> >
> >2) CPS and the semantics of name fields
> >(subsection 3.1.1, last paragraph)
> >
> >"It should be noted, however, that a relying party MAY have to consult
> >identified certificate policies and/or the issuer's CPS, in order to
> >determine semantics of name fields and legal jurisdiction." [PKIX-QC]
> >
> >This paragraph should be moved to the introduction of chapter 3. Not
> >only the Issuer field (subsection 3.1.1) contains name fields but also
> >some of the remaining sections of chapter 3 contain name fields (e. g.
> >3.2.1. Subject Alternative Name). Then in addition, "name field" may be
> >replaced by "a particullary field" because this note applies to other
> >fields like placeOfBirth as well. So, "The manner in which the date of
> >birth is associated with the subject is outside the scope of this
> >document." may be avoidable. Such phrases can be found in various
> >sections.
> >
> 
> I will think about this. I'm not so sure that your change does it more
> clear but you have a point.
> 
> >
> >
> >3) countryName usage
> >
> >The field countryName is defined in subsection 3.1.2 and 3.2.1
> >respectively. At a first glance, it is a field associated to the
> >subject. But [PKIX-QC] says about usage in both subsections:
> >
> >"The countryName attribute value specifies a general context in which
> >other attributes are to be understood. The country attribute does not
> >necessarily match the subject's country of citizenship or country of
> >residence, nor does it have to match the country of issuance." (*)
> >
> >I am confused. [PKIX-QC] says "The givenName and surname attribute types
> >SHALL, if present, contain the registered name of the subject, depending
> >on the laws under which the CA prepares the certificate." Either this
> >contradicts the countryName usage specification (*) or the draft allows
> >that the general context (whatever this means) of other subject´s
> >attributes differ from which of the givenName and surname attribute. By
> >the way, there is a difference in meaning between "prepare" and "issue",
> >isn´t it?
> >
> >The countryName usage (*) should be replaced by the following:
> >
> >- The countryName attribute value contained in the ISSUER field
> >specifies a general context in which other attributes are to be
> >understood. It should be noted that, the optional attributeSemantics
> >value may specify variations for attributes contained in the
> >PersonalData field.
> >
> >- The countryName attribute value contained in the SUBJECT field SHALL
> >match one of subject´s countryOfCitizenship or countryOfResidence. The
> >value may be chosen by subject´s or CA´s preference.
> >
> >- The countryName attribute contained in the PersonalData field SHALL if
> >present coincide with the value in the SUBJECT field.
> >
> >Have I overseen some discussion about the countryName usage? Why should
> >a countryName different from subject´s countryOfCitizenship or
> >countryOfResidence have any relevance in Qualified Certificates?
> >
> 
> Yes, this could be written more clear and you have some good suggestions.
> But I don't want to require that country SHALL match either citizenship or
> residence. I can't give a simple exact case right now but I'm sure there is
> one.

There should be at least one meaningful case within the PKIX framework.
If there is one then they may use the attributeSemantics.

> The idea is to let the country attribute be a dynamic country specifier
> used by any attributeSemantics value to give the context for various name
> properties. It could also give the country value for any specified
> registrationAuthority.

Provided that the general context of an attribute is not clear (ie it
differs from issuer´s countryName) I see the following cases

1) the attributeSemantics defines it,

2) the certificate policy/CPS gives guidance,

3) registration of new OIDs for the concerned attributes.

Just a thought. Is attributeSemantics really necessary? I tend to the
second case if applicable. Nevertheless, the combination of issuer´s
countryName and subject´s countryName should be sufficient in most
examples.
 
> 
> We will look into this.
> 
> >
> >
> >3) commonName
> >
> >In the 7th paragraph of subsection 3.1.2 [PKIX-QC]
> >
> >"To understand the nature of the name presented in commonName, complying
> >applications may have to examine present values of the givenName and
> >surname attributes and if necessary, the personal data field in the
> >subjectAltName extension."
> >
> >should be replaced by
> >
> >"To understand the nature of the name presented in commonName, complying
> >applications may have to examine present values of the givenName and
> >surname attributes contained in the personal data field of the
> >subjectAltName extension if necessary."
> >
> >The phrase applies to "Choice I" of subject field definition. Then the
> >fields givenName and surname are absent in the subject field even if
> >they may present in the PersonalData record of the subjectAltName field.
> >The conjunction "and if ..." is therefore misleading in the original
> >phrase.
> >
> 
> There is nothing that says that givenName and surname are absent when
> commonName is present. The Choice I and II are only choices of mandatory
> attribute. All other attributes are optionally present.

Sorry, you are right. CHOICE was misleading :-). So, besides the surname
and givenName we have optionally commonName. Thanks for clarification.

> 
> >4) Security Considerations
> >
> >[PKIX-QC, chapter 4] "Both the private key
> >   holder as well as the relying party should make sure that the private
> >   key is used only with the consent of the legitimate key holder and
> >   only after the key holders conscious acceptance of the signed message
> >   content."
> >
> >How could the relying party do this? This topic should be reformulated
> >in the following sense. On the one hand there are security requirements
> >according to the personal security environment; on the other hand there
> >are security requirements for certificate path validation.
> >
> 
> Yes you are right. The relying party can never be "SURE". But he will have
> to have an opinion, consciously or not. By trusting the certificate in a
> non-repudiation service, the relying party also chooses to trust the
> signers signing system. This is what has to be made clear. We will rephrase
> it.

I beg to differ. I focus on the signing component of signer´s
cryptographic module. The signer must be sure he signs the data that he
wants to sign. The signer has to be responsible for this not the relying
party. On the other hand, the relying party must be sure that he gets
the correct signature verification result. In order to do this, he
trusts a CA. Other modells need clarification in my opinion.

Juergen 

> 
> >
> >I hope it helps.
> >
> 
> It does.  Thank you.
> 
> >Juergen
> >
> >
> 
> /Stefan
> -------------------------------------------------------------------
> Stefan Santesson                <[email-masked]>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. +46-40 152211
> 216 42  Malmö                   Fax. +46-40 150790
> Sweden                        Mobile +46-70 5247799
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------

Date: Fri, 19 Feb 1999 09:48:53 +0100
To: Anders Rundgren <[email-masked]>, ietf-pkix <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Comments to Qualified Certificates draft
Cc: "'SEIS-List'" <[email-masked]>
Sender: [email-masked]

Comments in line.

At 10:49 AM 2/18/99 +0100, Anders Rundgren wrote:
>--- Message on the SEIS mailing list ([email-masked])
>
>Hi,
> >The subject field SHALL include one of the following choices of sets of
mandatory attributes:
>     >Choice  I:  countryName commonName
>     >Choice II:  countryName givenName surname
>      snip..
>   >The countryName attribute value specifies a general context in which
other attributes are to be
>   >understood. The country attribute does not necessarily match the
subject's country of
>   >citizenship or country of residence, nor does it have to match the
country of issuance.
>
>To me, this loose specification makes countryName redundant.  The issuer
domain should
>be enough to know how to interpret attributes. SUBJECT countryName just
adds confusion unless
>it denotes citizenship or residence.  None of the latter should affect
interpretation though.

The CountryName attribute is optional. If you find it redundant, then leave
it out. There are on the other hand many certificates that do use this
attribute so I would not prevent it from being used.

>
>A completely other comment regarding the sample certificate.  The sample
is in my opinion not
>very typical.  It contains birth data and gender.  I would say that for
e-commerce this kind
>of data is undesirable.   I believe that in reality dnQalifier of the CA
or the subject organization
>is what we will see.  For employment certificates birth, sex, and
nationality are of no interest.  
>This is established by other means (in the cases you really care) and
stored somewhere else.
>For personal ID-cards organization and role is of no interest.
>So my question is: What kind of use do you anticipate that your
>sample certificate would have?  This is a little bit of track but unless
you go into apps it
>is hard to have opinions about attributes, interpretations etc.
Suggestion: Make a few
>more samples for different purposes.
>

The purpose of the example certificate is only to show an example of how
the profile may be implemented. It does NOT imply that the present
attributes SHALL be present in any speciffic application.

>On a physical card personal data may be of interest to establish the
connection between the person and
>the card/certificate.  But what is inside the certificate, is a different
story.

I guess I lost you here.

>
>Just my 2 öres.
(What does this mean???? ;-) )

>
>Anders Rundgren
>Senior Internet e-commerce Architect
>
>

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

Content-return: allowed
Date: Thu, 18 Feb 1999 14:40:42 -0500
From: "Childs, Ed" <[email-masked]>
Subject: CMP and "waiting" status
To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

The CMP document states that a CA can return a response message that
indicates 
a "waiting" status - necessary if a request cannot be immediately
authenticated and 
a certificate granted or the request rejected. However, it does not
explicitly state (or at 
least I cannot find it) how a requestor, who received "waiting" status,
should ultimately 
get the results of the authentication.

How does a requestor obtain the results and receive the certificate if
granted?

From: "Sikac,John,CNA Insurance" <[email-masked]>
To: [email-masked]
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Wed, 17 Feb 1999 11:28:41 -0600
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE5A9A.9E4B615A
Content-Type: text/plain

Does anyone have any input to or is anyone aware of any issues 
related to co-residing the Entrust Directory with the LDAP server?

John

------_=_NextPart_001_01BE5A9A.9E4B615A
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>RE: Usage of CRL Issuing Distribution Point</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Does anyone have any input to or is anyone aware of any issues </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">related to co-residing the Entrust Directory with the LDAP server?</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">John</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE5A9A.9E4B615A--

From: "Ambarish Malpani" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Tue, 16 Feb 1999 18:14:18 -0800
Importance: Normal
Sender: [email-masked]

Hi Trevor,
    If you look at the original description of how I said a
client should process a CRL/CRLDP, it actually covered the
issue you were talking about. To quote:

-----BEGIN QUOTE-----
P.S. To figure out which CRLs apply to the certificate you are
trying to check, you normally look for the path to the CRLs in
the certificate. Once you retrieve the CRL, you need to check
that the CRL has the same name as the one you thought you
were retrieving. So the extension you look for in the cert
is the one with OID id-ce-cRLDistributionPoints, while the name
of the CRL can be found in the CRL (if present), with the
OID id-ce-issuingDistributionPoint.
-----END QUOTE-----

Hope this clarifies the issue.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Trevor Freeman
> Sent: Tuesday, February 16, 1999 3:53 PM
> To: 'Stephen Kent'
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> As with a lot of threads on the list, there have been some
> miss-interpretations based on some terms having different meaning to
> different people. Let me return to the original point.
> It is important for the client to understand whether it is 
> dealing with a
> monolithic CRL or multiple CRL's. In the former case once it 
> finds a current
> CRL signed by the CA, it knows it is sufficient. Here the AKI 
> extension is a
> useful hint, but the signature check is conclusive proof the 
> client has
> found the right CRL. In the latter case there will be 
> multiple CRL's all of
> which current, and signed by the same CA. In these instances 
> it is dangerous
> for the CA to assume the reliability of the CRL distribution 
> mechanism, and
> therefore there is a need to include unambiguous information in the
> Certificate AND CRL to inform the client if the CRL is 
> partitioned, or not
> where are these CRL(s) and it needs to know  from the CRL 
> when it has found
> them. Our in other words finding a object signed by the right 
> authority at
> the end of a URL or in a directory is not enough. 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, February 16, 1999 7:46 AM
> To: Trevor Freeman
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> Trevor,
> 
> I am puzzled by your statements. It is true that CRLs have 
> some facilities
> to explicitly mark which classes of certs may be contrained 
> in them, e.g.,
> only CA certs or only some revocation reason codes.  However, 
> there is no
> prohibition
> against round robin assignment of certs to different CRLs 
> through the use
> of the CRL distribution point extension.  In fact, that would 
> seem to be a
> major feature of this extension.  Perhaps you are raising the 
> question of
> how one ought to note, in the CRL itself, that only a subset of certs
> (e.g., partiitioned by serial number) are contained in a given CRL.
> 
> Steve
> 

From: Santosh Chokhani <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Tue, 16 Feb 1999 19:05:57 -0500
Sender: [email-masked]

Please see the text for CRL processing in Annex M of the September 1998
PDAM to X.509.  It clarifies lots of issues in terms of how to determine
whether a CRL is appropriate, which has been the theme of this thread
for a while now.

I have also suggested that the Annex should be part of the pkix document
series or tied to pkix part 1 somehow.

> -----Original Message-----
> From:	Trevor Freeman [SMTP:[email-masked]]
> Sent:	Tuesday, February 16, 1999 6:53 PM
> To:	'Stephen Kent'
> Cc:	[email-masked]'
> Subject:	RE: Usage of CRL Issuing Distribution Point
> 
> As with a lot of threads on the list, there have been some
> miss-interpretations based on some terms having different meaning to
> different people. Let me return to the original point.
> It is important for the client to understand whether it is dealing
> with a
> monolithic CRL or multiple CRL's. In the former case once it finds a
> current
> CRL signed by the CA, it knows it is sufficient. Here the AKI
> extension is a
> useful hint, but the signature check is conclusive proof the client
> has
> found the right CRL. In the latter case there will be multiple CRL's
> all of
> which current, and signed by the same CA. In these instances it is
> dangerous
> for the CA to assume the reliability of the CRL distribution
> mechanism, and
> therefore there is a need to include unambiguous information in the
> Certificate AND CRL to inform the client if the CRL is partitioned, or
> not
> where are these CRL(s) and it needs to know  from the CRL when it has
> found
> them. Our in other words finding a object signed by the right
> authority at
> the end of a URL or in a directory is not enough. 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, February 16, 1999 7:46 AM
> To: Trevor Freeman
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> Trevor,
> 
> I am puzzled by your statements. It is true that CRLs have some
> facilities
> to explicitly mark which classes of certs may be contrained in them,
> e.g.,
> only CA certs or only some revocation reason codes.  However, there is
> no
> prohibition
> against round robin assignment of certs to different CRLs through the
> use
> of the CRL distribution point extension.  In fact, that would seem to
> be a
> major feature of this extension.  Perhaps you are raising the question
> of
> how one ought to note, in the CRL itself, that only a subset of certs
> (e.g., partiitioned by serial number) are contained in a given CRL.
> 
> Steve

From: Trevor Freeman <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Tue, 16 Feb 1999 15:52:56 -0800
Sender: [email-masked]

As with a lot of threads on the list, there have been some
miss-interpretations based on some terms having different meaning to
different people. Let me return to the original point.
It is important for the client to understand whether it is dealing with a
monolithic CRL or multiple CRL's. In the former case once it finds a current
CRL signed by the CA, it knows it is sufficient. Here the AKI extension is a
useful hint, but the signature check is conclusive proof the client has
found the right CRL. In the latter case there will be multiple CRL's all of
which current, and signed by the same CA. In these instances it is dangerous
for the CA to assume the reliability of the CRL distribution mechanism, and
therefore there is a need to include unambiguous information in the
Certificate AND CRL to inform the client if the CRL is partitioned, or not
where are these CRL(s) and it needs to know  from the CRL when it has found
them. Our in other words finding a object signed by the right authority at
the end of a URL or in a directory is not enough. 

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 7:46 AM
To: Trevor Freeman
Cc: [email-masked]'
Subject: RE: Usage of CRL Issuing Distribution Point

Trevor,

I am puzzled by your statements. It is true that CRLs have some facilities
to explicitly mark which classes of certs may be contrained in them, e.g.,
only CA certs or only some revocation reason codes.  However, there is no
prohibition
against round robin assignment of certs to different CRLs through the use
of the CRL distribution point extension.  In fact, that would seem to be a
major feature of this extension.  Perhaps you are raising the question of
how one ought to note, in the CRL itself, that only a subset of certs
(e.g., partiitioned by serial number) are contained in a given CRL.

Steve

Date: Tue, 16 Feb 1999 22:56:27 +0100
To: ietf-pkix <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Qualified certificates - European standardization
Sender: [email-masked]

All,

Next week then European Union initiative EESSI (European Electronic
Signature Standardization Initiative) will hold it's first meeting. The
purpose for this group is to coordinate european standardization necessary
to support cross border electronic signature acceptance (supporting the
electronic signature directive).

I'm invited in this fora to present our work on the Qualified certificates
draft. I will do my best to se through that European and IETF
standardization of certificate format goes hand in hand.

Before this meeting (february 24) I would like to get in contact with
people that can provide me with valuable input. 

If you know of other standardization initiatives covering the same topic ...
If you are considering implementing or utilizing such standard ...
If you have any valuable contribution of any kind ...

Please let me know.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

Date: Tue, 16 Feb 1999 22:36:01 +0100
To: ietf-pkix <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Example certs (Qualified Certificates)
Sender: [email-masked]

All,

Petra Glöckner has prepared an example certificate implementing the
Qualified Certificate profile  <draft-ietf-pkix-qc-00.txt>

Since some object identifiers are yet to be defined, some OID:s are just
temporary.

I you wish I can provide you with the text in word 97 or rtf format. Just
give me a reply and i return the document.

/Stefan

----------------------------------

EXAMPLES
Qualified user certificate

This section contains the ASN.1 structure and an hex dump of a 833  byte
version 3 qualified certificate. The certificate contains the following
information:

1. The serial number is 1
2. The certificate is signed with RSA and the SHA-1 hash algorithm
3. The issuer's distinguished name is O=GMD - Forschungszentrum
Informationstechnik GmbH,  C=DE
4. The subject's distinguished name is CN=Petra M. Gloeckner, O=GMD -
Forschungszentrum Informationstechnik GmbH, C=DE
5. The certificate was issued on February 5, 1999 and will expire on
February 5, 2000
6. The certificate contains a 1024 bit RSA key
7. The certificate includes a critical key usage extension exclusively
indicating non-repudiation 
8. The certificate includes a certificate policy identifier indicating the
practices and procedures undertaken by the issuing CA (temp. OID 1.3.36.8.9.1)
9. The certificate includes one subject alternative name - a PersonalData
structure (temp. OID 1.3.36.8.8) in the 
OtherName subfield containing the following attributes:

Registered by: [email-masked] 
surname:                Gloeckner
given name:             Petra
date of birth:          October, 14th 1971 (temp. OID 1.3.36.8.8.1)	
place of birth:         Darmstadt          (temp. OID 1.3.36.8.8.2)
country of citizenship: DE                 (temp. OID 1.3.36.8.8.3)
gender:                 female             (temp. OID 1.3.36.8.8.4)

Registered by: [email-masked], using the attribute semantics defined by the
temp. OID 1.3.36.8.9.2
organization:	    GMD
role:             project manager QC       (temp. OID 1.3.36.8.8.5)

ASN.1 Structure:

SEQUENCE length = 829 {
    SEQUENCE length = 682 {
        [0] (constructed) length = 3 {
            INTEGER 2
        }
        INTEGER 1
        SEQUENCE length = 9 {
            OBJECT IDENTIFIER 1.3.14.3.2.RSASignatureWithSHA1(29)
            NULL 
        }
        SEQUENCE length = 72 {
            SET length = 11 {
                SEQUENCE length = 9 {
                    OBJECT IDENTIFIER 2.5.4.countryName(6)
                    PrintableString "DE"
                }
            }
            SET length = 57 {
                SEQUENCE length = 55 {
                    OBJECT IDENTIFIER 2.5.4.organizationName(10)
                    PrintableString "GMD - Forschungszentrum
Informationstechnik GmbH"
                }
            }
        }
        SEQUENCE length = 30 {
            UTCTime "990205172517Z"
            UTCTime "000205172517Z"
        }
        SEQUENCE length = 101 {
            SET length = 11 {
                SEQUENCE length = 9 {
                    OBJECT IDENTIFIER 2.5.4.countryName(6)
                    PrintableString "DE"
                }
            }
            SET length = 57 {
                SEQUENCE length = 55 {
                    OBJECT IDENTIFIER 2.5.4.organizationName(10)
                    PrintableString "GMD - Forschungszentrum
Informationstechnik GmbH"
                }
            }
            SET length = 27 {
                SEQUENCE length = 25 {
                    OBJECT IDENTIFIER 2.5.4.commonName(3)
                    PrintableString "Petra M. Gloeckner"
                }
            }
        }
        SEQUENCE length = 159 {
            SEQUENCE length = 13 {
                OBJECT IDENTIFIER 1.2.840.113549.1.1.rsaEncryption(1)
                NULL 
            }
            BIT STRING number of bits = 1120  content:
30818902818100ff11a1fb756ea56c94e0a6043b5c123b6aea85b5b4d656c8d85df2791cb4a5
077eb123b1c2d5f070187902d03168739362a59a745154ee909501c7bf2149332d61df5e4fbd
0eed3c6e7df09b9d712a409ed323560dc15954cc83564d440564f11a3b6dff88a5a3aa683681
3982f395564ac80d3dac013febf6bde21fd3e5b19b0203010001
        }
        [3] (constructed) length = 288 {
            SEQUENCE length = 284 {
                SEQUENCE length = 14 {
                    OBJECT IDENTIFIER 2.5.29.keyUsage(15)
                    BOOLEAN TRUE
                    OCTET STRING length = 4  content: 03020640
                }
                SEQUENCE length = 18 {
                    OBJECT IDENTIFIER 2.5.29.certificatePolicies(32)
                    OCTET STRING length = 11  content: 3009300706052b24080901
                }
                SEQUENCE length = 245 {
                    OBJECT IDENTIFIER 2.5.29.subjectAltName(17)
                    OCTET STRING length = 237  content:
3081eaa081e706042b240808a081de3081db3081d830818e16176d756e69636970616c697479
407365656865696d2e6465307330120603550404310b1309676c6f65636b6e6572300e060355
042a310713055065747261301a06052b240808013111180f3139373131303134303030303030
5a301406052b24080802310b13094461726d7374616474300d06052b24080803310413024445
300c06052b2408080431031301463045160d676d642d726140676d642e646506052b24080902
302d300c060355040a31051303474d44301d06052b240808053114131270726f6a656374206d
616e61676572205143
                }
            }
        }
    }
    SEQUENCE length = 9 {
        OBJECT IDENTIFIER 1.3.14.3.2.RSASignatureWithSHA1(29)
        NULL 
    }
    BIT STRING number of bits = 1024  content:
3fac2aa9f2ef4dc8e09d8be0c4cad287e0cf770e9ed2eb2e7c8fdced7d0dea99670b4895d5c5
d9459b776674c9dd970e8a7c630f64173d04701a2642539599acf40b0f36aa18ae53fc2246de
71460845bbdcdf555d1a28502260a56973f91fbec4f1f486b29ca6ceb0fae0b83d0b4e3b76fd
d8c857dcf2c5e7aa5bbfe4fab23f
}

Structured hexdump:

0x00000000  T: 30 L: 82 03 3d{
0x00000004      T: 30 L: 82 02 aa{
0x00000008          T: a0 L: 03{
0x0000000a              T: 02 L: 01 C: 02
                    }
0x0000000d          T: 02 L: 01 C: 01
0x00000010          T: 30 L: 09{
0x00000012              T: 06 L: 05 C: 2b 0e 03 02 1d
0x00000019              T: 05 L: 00 C: 
                    }
0x0000001b          T: 30 L: 48{
0x0000001d              T: 31 L: 0b{
0x0000001f                  T: 30 L: 09{
0x00000021                      T: 06 L: 03 C: 55 04 06
0x00000026                      T: 13 L: 02 C: 44 45
                            }
                        }
0x0000002a              T: 31 L: 39{
0x0000002c                  T: 30 L: 37{
0x0000002e                      T: 06 L: 03 C: 55 04 0a
0x00000033                      T: 13 L: 30 C: 47 4d 44 20 2d 20 46 6f 72
73 63 68 75 6e 67 73 7a 65 6e 74 72 75 6d 20 49 6e 66 6f 72 6d 61 74 69 6f
6e 73 74 65 63 68 6e 69 6b 20 47 6d 62 48
                            }
                        }
                    }
0x00000065          T: 30 L: 1e{
0x00000067              T: 17 L: 0d C: 39 39 30 32 30 35 31 37 32 35 31 37 5a
0x00000076              T: 17 L: 0d C: 30 30 30 32 30 35 31 37 32 35 31 37 5a
                    }
0x00000085          T: 30 L: 65{
0x00000087              T: 31 L: 0b{
0x00000089                  T: 30 L: 09{
0x0000008b                      T: 06 L: 03 C: 55 04 06
0x00000090                      T: 13 L: 02 C: 44 45
                            }
                        }
0x00000094              T: 31 L: 39{
0x00000096                  T: 30 L: 37{
0x00000098                      T: 06 L: 03 C: 55 04 0a
0x0000009d                      T: 13 L: 30 C: 47 4d 44 20 2d 20 46 6f 72
73 63 68 75 6e 67 73 7a 65 6e 74 72 75 6d 20 49 6e 66 6f 72 6d 61 74 69 6f
6e 73 74 65 63 68 6e 69 6b 20 47 6d 62 48
                            }
                        }
0x000000cf              T: 31 L: 1b{
0x000000d1                  T: 30 L: 19{
0x000000d3                      T: 06 L: 03 C: 55 04 03
0x000000d8                      T: 13 L: 12 C: 50 65 74 72 61 20 4d 2e 20
47 6c 6f 65 63 6b 6e 65 72
                            }
                        }
                    }
0x000000ec          T: 30 L: 81 9f{
0x000000ef              T: 30 L: 0d{
0x000000f1                  T: 06 L: 09 C: 2a 86 48 86 f7 0d 01 01 01
0x000000fc                  T: 05 L: 00 C: 
                        }
0x000000fe              T: 03 L: 81 8d C: 00 30 81 89 02 81 81 00 ff 11 a1
fb 75 6e a5 6c 94 e0 a6 04 3b 5c 12 3b 6a ea 85 b5 b4 d6 56 c8 d8 5d f2 79
1c b4 a5 07 7e b1 23 b1 c2 d5 f0 70 18 79 02 d0 31 68 73 93 62 a5 9a 74 51
54 ee 90 95 01 c7 bf 21 49 33 2d 61 df 5e 4f bd 0e ed 3c 6e 7d f0 9b 9d 71
2a 40 9e d3 23 56 0d c1 59 54 cc 83 56 4d 44 05 64 f1 1a 3b 6d ff 88 a5 a3
aa 68 36 81 39 82 f3 95 56 4a c8 0d 3d ac 01 3f eb f6 bd e2 1f d3 e5 b1 9b
02 03 01 00 01
                    }
0x0000018e          T: a3 L: 82 01 20{
0x00000192              T: 30 L: 82 01 1c{
0x00000196                  T: 30 L: 0e{
0x00000198                      T: 06 L: 03 C: 55 1d 0f
0x0000019d                      T: 01 L: 01 C: ff
0x000001a0                      T: 04 L: 04 C: 03 02 06 40
                            }
0x000001a6                  T: 30 L: 12{
0x000001a8                      T: 06 L: 03 C: 55 1d 20
0x000001ad                      T: 04 L: 0b C: 30 09 30 07 06 05 2b 24 08
09 01
                            }
0x000001ba                  T: 30 L: 81 f5{
0x000001bd                      T: 06 L: 03 C: 55 1d 11
0x000001c2                      T: 04 L: 81 ed C: 30 81 ea a0 81 e7 06 04
2b 24 08 08 a0 81 de 30 81 db 30 81 d8 30 81 8e 16 17 6d 75 6e 69 63 69 70
61 6c 69 74 79 40 73 65 65 68 65 69 6d 2e 64 65 30 73 30 12 06 03 55 04 04
31 0b 13 09 67 6c 6f 65 63 6b 6e 65 72 30 0e 06 03 55 04 2a 31 07 13 05 50
65 74 72 61 30 1a 06 05 2b 24 08 08 01 31 11 18 0f 31 39 37 31 31 30 31 34
30 30 30 30 30 30 5a 30 14 06 05 2b 24 08 08 02 31 0b 13 09 44 61 72 6d 73
74 61 64 74 30 0d 06 05 2b 24 08 08 03 31 04 13 02 44 45 30 0c 06 05 2b 24
08 08 04 31 03 13 01 46 30 45 16 0d 67 6d 64 2d 72 61 40 67 6d 64 2e 64 65
06 05 2b 24 08 09 02 30 2d 30 0c 06 03 55 04 0a 31 05 13 03 47 4d 44 30 1d
06 05 2b 24 08 08 05 31 14 13 12 70 72 6f 6a 65 63 74 20 6d 61 6e 61 67 65
72 20 51 43
                            }
                        }
                    }
                }
0x000002b2      T: 30 L: 09{
0x000002b4          T: 06 L: 05 C: 2b 0e 03 02 1d
0x000002bb          T: 05 L: 00 C: 
                }
0x000002bd      T: 03 L: 81 81 C: 00 3f ac 2a a9 f2 ef 4d c8 e0 9d 8b e0 c4
ca d2 87 e0 cf 77 0e 9e d2 eb 2e 7c 8f dc ed 7d 0d ea 99 67 0b 48 95 d5 c5
d9 45 9b 77 66 74 c9 dd 97 0e 8a 7c 63 0f 64 17 3d 04 70 1a 26 42 53 95 99
ac f4 0b 0f 36 aa 18 ae 53 fc 22 46 de 71 46 08 45 bb dc df 55 5d 1a 28 50
22 60 a5 69 73 f9 1f be c4 f1 f4 86 b2 9c a6 ce b0 fa e0 b8 3d 0b 4e 3b 76
fd d8 c8 57 dc f2 c5 e7 aa 5b bf e4 fa b2 3f
0x00000341  }

hex dump:

0  3082033D 308202AA  A0030201 02020101      |0..=0...........|
     10  30090605 2B0E0302  1D050030 48310B30      |0...+......0H1.0|
     20  09060355 04061302  44453139 30370603      |...U....DE1907..|
     30  55040A13 30474D44  202D2046 6F727363      |U...0GMD - Forsc|
     40  68756E67 737A656E  7472756D 20496E66      |hungszentrum Inf|
     50  6F726D61 74696F6E  73746563 686E696B      |ormationstechnik|
     60  20476D62 48301E17  0D393930 32303531      | GmbH0...9902051|
     70  37323531 375A170D  30303032 30353137      |72517Z..00020517|
     80  32353137 5A306531  0B300906 03550406      |2517Z0e1.0...U..|
     90  13024445 31393037  06035504 0A133047      |..DE1907..U...0G|
     A0  4D44202D 20466F72  73636875 6E67737A      |MD - Forschungsz|
     B0  656E7472 756D2049  6E666F72 6D617469      |entrum Informati|
     C0  6F6E7374 6563686E  696B2047 6D624831      |onstechnik GmbH1|
     D0  1B301906 03550403  13125065 74726120      |.0...U....Petra |
     E0  4D2E2047 6C6F6563  6B6E6572 30819F30      |M. Gloeckner0..0|
     F0  0D06092A 864886F7  0D010101 05000381      |...*.H..........|
    100  8D003081 89028181  00FF11A1 FB756EA5      |..0..........un.|
    110  6C94E0A6 043B5C12  3B6AEA85 B5B4D656      |l....;\.;j.....V|
    120  C8D85DF2 791CB4A5  077EB123 B1C2D5F0      |..].y....~.#....|
    130  70187902 D0316873  9362A59A 745154EE      |p.y..1hs.b..tQT.|
    140  909501C7 BF214933  2D61DF5E 4FBD0EED      |.....!I3-a.^O...|
    150  3C6E7DF0 9B9D712A  409ED323 560DC159      |<n}...q*@..#V..Y|
    160  54CC8356 4D440564  F11A3B6D FF88A5A3      |T..VMD.d..;m....|
    170  AA683681 3982F395  564AC80D 3DAC013F      |.h6.9...VJ..=..?|
    180  EBF6BDE2 1FD3E5B1  9B020301 0001A382      |................|
    190  01203082 011C300E  0603551D 0F0101FF      |. 0...0...U.....|
    1A0  04040302 06403012  0603551D 20040B30      |.....@0...U. ..0|
    1B0  09300706 052B2408  09013081 F5060355      |.0...+$...0....U|
    1C0  1D110481 ED3081EA  A081E706 042B2408      |.....0.......+$.|
    1D0  08A081DE 3081DB30  81D83081 8E16176D      |....0..0..0....m|
    1E0  756E6963 6970616C  69747940 73656568      |unicipality@seeh|
    1F0  65696D2E 64653073  30120603 55040431      |eim.de0s0...U..1|
    200  0B130967 6C6F6563  6B6E6572 300E0603      |...gloeckner0...|
    210  55042A31 07130550  65747261 301A0605      |U.*1...Petra0...|
    220  2B240808 01311118  0F313937 31313031      |+$...1...1971101|
    230  34303030 3030305A  30140605 2B240808      |4000000Z0...+$..|
    240  02310B13 09446172  6D737461 6474300D      |.1...Darmstadt0.|
    250  06052B24 08080331  04130244 45300C06      |..+$...1...DE0..|
    260  052B2408 08043103  13014630 45160D67      |.+$...1...F0E..g|
    270  6D642D72 6140676D  642E6465 06052B24      [email-masked]..+$|
    280  08090230 2D300C06  0355040A 31051303      |...0-0...U..1...|
    290  474D4430 1D06052B  24080805 31141312      |GMD0...+$...1...|
    2A0  70726F6A 65637420  6D616E61 67657220      |project manager |
    2B0  51433009 06052B0E  03021D05 00038181      |QC0...+.........|
    2C0  003FAC2A A9F2EF4D  C8E09D8B E0C4CAD2      |.?.*...M........|
    2D0  87E0CF77 0E9ED2EB  2E7C8FDC ED7D0DEA      |...w.....|...}..|
    2E0  99670B48 95D5C5D9  459B7766 74C9DD97      |.g.H....E.wft...|
    2F0  0E8A7C63 0F64173D  04701A26 42539599      |..|c.d.=.p.&BS..|
    300  ACF40B0F 36AA18AE  53FC2246 DE714608      |....6...S."F.qF.|
    310  45BBDCDF 555D1A28  502260A5 6973F91F      |E...U].(P"`.is..|
    320  BEC4F1F4 86B29CA6  CEB0FAE0 B83D0B4E      |.............=.N|
    330  3B76FDD8 C857DCF2  C5E7AA5B BFE4FAB2      |;v...W.....[....|
    340  3F                                        |?               |

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

Date: Tue, 16 Feb 1999 22:18:37 +0100
To: [email-masked], [email-masked], [email-masked], ietf-pkix <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Comments to Qualified Certificates draft
Sender: [email-masked]

Thank you for your comments,

I have been busy for a while so forgive my late reply.

I give some short comments in-line.

At 06:32 PM 2/11/99 +0100, Juergen Walter wrote:
>I would like to add some comments to the QC draft. The topics are the
>following
>
>1) Properties of Qualified certificates,
>2) CPS and the semantics of name fields,
>3) countryName usage,
>4) commonName
>5) Security Considerations.
>
>Comments 1),2),4) are more or less editorial, while comments 3), 5) are
>more general.
>
>1) Properties of Qualified Certificates
>
>"2.1  Properties
>
>   A Qualified Certificate as defined in this standard is assumed to
>   have the following properties:
>
>   - Issued by a CA that makes a public statement that the certificate
>   serves the purpose of a Qualified Certificate, as discussed in sec-
>   tion 2.3
>   - Indicate a certificate policy consistent with liabilities, prac-
>   tices and procedures undertaken by the CA, as discussed in 2.4
>   - Be issued to a natural person (living human being).
>   - Contain an unmistakable identity based on a pseudonym name or a
>   real name of the subject.
>   - Exclusively indicates non-repudiation key usage for the certified
>   public key.
>   - Fully complies with the certificate profile defined in RFC 2459"
>[PKIX-QC]
>
>The last three properties should be replaced by 
>   - Fully complies with the certificate profile defined in RFC 2459 and
>chapter 3 of    this document.
>

Actually it should be the other way around. The reference to rfc 2459
should not be here. The meaning of this section is to say something about
what makes a certificate a "Qualified Certificate". rfc 2459 and this
profile does not make a certificate a "Qualified certificate" they are just
a usable format for expressing them.

>The profile of Qualified Certificates is defined in chapter 3 of
>[PKIX-QC]. The fourth and fifth property do not cover the profile given
>in chapter 3 completely.
>
>The security requirements defined in chapter 4 should be linked
>explicitly. Therefore the following property should be added:
>
>   - Issued by a CA in compliance with reasonable securitity measures
>following the security considerations in chapter 4.
>
>
>
>2) CPS and the semantics of name fields
>(subsection 3.1.1, last paragraph)
>
>"It should be noted, however, that a relying party MAY have to consult
>identified certificate policies and/or the issuer's CPS, in order to
>determine semantics of name fields and legal jurisdiction." [PKIX-QC]
>
>This paragraph should be moved to the introduction of chapter 3. Not
>only the Issuer field (subsection 3.1.1) contains name fields but also
>some of the remaining sections of chapter 3 contain name fields (e. g.
>3.2.1. Subject Alternative Name). Then in addition, "name field" may be
>replaced by "a particullary field" because this note applies to other
>fields like placeOfBirth as well. So, "The manner in which the date of
>birth is associated with the subject is outside the scope of this
>document." may be avoidable. Such phrases can be found in various
>sections.
>

I will think about this. I'm not so sure that your change does it more
clear but you have a point.

>
>
>3) countryName usage
>
>The field countryName is defined in subsection 3.1.2 and 3.2.1
>respectively. At a first glance, it is a field associated to the
>subject. But [PKIX-QC] says about usage in both subsections:
>
>"The countryName attribute value specifies a general context in which
>other attributes are to be understood. The country attribute does not
>necessarily match the subject's country of citizenship or country of
>residence, nor does it have to match the country of issuance." (*)
>
>I am confused. [PKIX-QC] says "The givenName and surname attribute types
>SHALL, if present, contain the registered name of the subject, depending
>on the laws under which the CA prepares the certificate." Either this
>contradicts the countryName usage specification (*) or the draft allows
>that the general context (whatever this means) of other subject´s
>attributes differ from which of the givenName and surname attribute. By
>the way, there is a difference in meaning between "prepare" and "issue",
>isn´t it?
>
>The countryName usage (*) should be replaced by the following:
>
>- The countryName attribute value contained in the ISSUER field
>specifies a general context in which other attributes are to be
>understood. It should be noted that, the optional attributeSemantics
>value may specify variations for attributes contained in the
>PersonalData field.
>
>- The countryName attribute value contained in the SUBJECT field SHALL
>match one of subject´s countryOfCitizenship or countryOfResidence. The
>value may be chosen by subject´s or CA´s preference.
>
>- The countryName attribute contained in the PersonalData field SHALL if
>present coincide with the value in the SUBJECT field.
>
>Have I overseen some discussion about the countryName usage? Why should
>a countryName different from subject´s countryOfCitizenship or
>countryOfResidence have any relevance in Qualified Certificates?
>

Yes, this could be written more clear and you have some good suggestions.
But I don't want to require that country SHALL match either citizenship or
residence. I can't give a simple exact case right now but I'm sure there is
one.
The idea is to let the country attribute be a dynamic country specifier
used by any attributeSemantics value to give the context for various name
properties. It could also give the country value for any specified
registrationAuthority.

We will look into this.

>
>
>3) commonName
>
>In the 7th paragraph of subsection 3.1.2 [PKIX-QC]
>
>"To understand the nature of the name presented in commonName, complying
>applications may have to examine present values of the givenName and
>surname attributes and if necessary, the personal data field in the
>subjectAltName extension."
>
>should be replaced by
>
>"To understand the nature of the name presented in commonName, complying
>applications may have to examine present values of the givenName and
>surname attributes contained in the personal data field of the
>subjectAltName extension if necessary."
>
>The phrase applies to "Choice I" of subject field definition. Then the
>fields givenName and surname are absent in the subject field even if
>they may present in the PersonalData record of the subjectAltName field.
>The conjunction "and if ..." is therefore misleading in the original
>phrase.
>

There is nothing that says that givenName and surname are absent when
commonName is present. The Choice I and II are only choices of mandatory
attribute. All other attributes are optionally present.

>4) Security Considerations
>
>[PKIX-QC, chapter 4] "Both the private key
>   holder as well as the relying party should make sure that the private
>   key is used only with the consent of the legitimate key holder and
>   only after the key holders conscious acceptance of the signed message
>   content."
>
>How could the relying party do this? This topic should be reformulated
>in the following sense. On the one hand there are security requirements
>according to the personal security environment; on the other hand there
>are security requirements for certificate path validation.
>

Yes you are right. The relying party can never be "SURE". But he will have
to have an opinion, consciously or not. By trusting the certificate in a
non-repudiation service, the relying party also chooses to trust the
signers signing system. This is what has to be made clear. We will rephrase
it.

>
>I hope it helps.
>

It does.  Thank you.

>Juergen
>
>

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Yes, and remove more of the alphabet from the PKIX soup
Date: Tue, 16 Feb 1999 15:06:40 -0500
Sender: [email-masked]

Hi Phill,

Thanks for the e-mail; it's always fun to see stuff from you on the list.

> ----------
> From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
> Sent: 	Tuesday, February 16, 1999 11:26 AM
> To: 	Carlisle Adams; Flanigan, Bill; 'Eric Bomarsi'
> Cc: 	'Al Arsenault'; [email-masked]
> Subject: 	RE: Yes, and remove more of the alphabet from the PKIX soup
> 
> In any case many folk 
> I have spoken to are under the influence of all sorts of bizare beliefs,
> 
If you'll forgive the personal advice, it seems to me that you might want to
be more careful about who you talk to...  :-)

> if we are meant to reject 'Popes, Kings and voting' then perhaps
> we can also leave out unsourced opinion polls?
> 
Fair enough.  Given that I don't have time to track people down and get
their permission to quote them before responding to you, feel free to
pretend that everything I said is my own personal opinion.  How, exactly,
does that affect its truth value? 

> If you can provide concrete suggestions for how we can overcome the
> undefined shortcommings you see in CMC you should send them to the
> list. 
> 
The shortcomings in CMC are hardly "undefined" -- I have harped on them at
every IETF meeting for the past year and a half and sent a relatively
detailed posting on the latest draft to the list last December.  As a result
of these efforts and those of a number of other people, the specification is
now much improved.  Is it possible that you have missed some of these
discussions and activity?

> I don't understand the point you are making regarding DNS and OCSP.
> Clearly OCSP is one option for certificate revocation - but nobody
> is suggesting that if you use CMC then you must also use OCSP. 
> 
I agree.  Nobody is suggesting this (including me).

> Equally there is no bar to users of CMP using OCSP 
> 
Agreed again.  Perhaps you missed my sentence about mixing and matching the
protocols and technologies in the different environments...

> (except to the
> extent that the only vendor of CMP products does not at 
> present support OCSP).
> 
It seems that you have missed recent vendor announcements.  There are now
several vendors supporting CMP (they are in the midst of active
interoperability trials), and at least some of those have talked about
supporting OCSP as well. 

> Nor is anyone proposing that DNS is an alternative for X.500/LDAP,
> DNS is not a certificate repository! 
> 
Isn't this at least one of the things that DNSsec is all about?

In any case, the only point of my previous posting was that certificate
management in the Internet is not yet a solved problem.  It's getting there,
but it's not quite there yet.  Some enterprise environments cannot afford to
wait; fortunately, with some of these alternative mechanisms, they don't
need to.

Carlisle.

From: "Kurn, David" <[email-masked]>
To: [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Tue, 16 Feb 1999 11:45:02 -0800
Sender: [email-masked]

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer if"
points, but I think he has identified a real need in our efforts to deploy
PKI.  

Ignoring, for the moment, how I obtained Bob's key-encryption cert in the
first place, there are two other places I must go to before I can evaluate
trust.  

1)  I must find the certificate of the issuer (signer) of the certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service address
(DNS name) for each is specified in all PKI certs.  Call it optional (to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked]
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread 
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one that
would 
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or
it 
could be some other alternateSubjectName attribute, or some other attribute
entirely.

But is there at least some agreement about the potential utility of this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Tue, 16 Feb 1999 11:56:08 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Subject: RE: Finding PKIX Servers!
Sender: [email-masked]

On the heat vs. light scale, a lot of the commentary on this thread 
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

In my view, it is pointless to argue for the establishment of some global,
overarching directory structure as a _prerequisite_ for something else we
are trying to do.  As a former member of the North American Directories
Forum that tried to do that, I know that we finally gave up and threw in the
towel -- the problem was just too hard. Was then, and arguably is now. 
That doesn't it will stay that way forever, of course.  We used to talk about 
islands of directories beginning to emerge, and then later forming 
archipelagoes, and later yet merging to form continents. Hopefully this won't
take geological time frames, but it hasn't happened yet.

By the way, the primary problem was NOT technical, but rather intellectual
property issues.  The major value-added network providers at the time were
selling various proprietary directory services to their customers, and they didn't 
want to lose market share by integrating their valuable data into a directory 
that just anyone could access. So they didn't, and now most of them have
disappeared, along with the opportunity to put together a workable 
global system along the lines of what X.500 was ordinally envisioned to be.
Too bad -- a wasted opportunity.

Now, whether we like it of not, we have lots and lots of little islands of X.500 
and X.500-like directories all over the place, especially in the corporate world.

At present, virtually none of these directories are interconnected, except that
clients, including LDAP, can access multiple such directories if they just know 
how to do so.

(Brief digression re LDAP.  When Tim Howes was at U-Mich and wanted to 
deploy directory technology to the 100,000 students there, those students
were equipped with 8088s and 286-based machines that were slow and 
had very limited memory by today's standards.  He looked at DAP and decided,
perhaps rightly, that that protocol (a) provided more functionality than was needed
for his application, (b) was going to take too long to program given the very
limited technical staff that was available, and (c) wouldn't leave enough memory 
in the student's computers to do anything useful.  So he "simplified" the protocol
by throwing out everything he didn't need for his particular application, notably
including support for character sets other than English, strong authentication,
chaining and referral, etc., etc.  And so LDAP was born, and voila! it satisfied 
his needs, and some other early adopter's needs as well.  Now the market has 
spoken, and the answer is LDAP regardless of what the original question was, and 
so we are up to LDAP v3 and are still trying to restore the needed functionality 
and generality that DAP provided, and we are having to do it with lots of string 
parsing instead of more efficient structures, and it sure as heck isn't light weight
any more, and now we are further away then ever from having a global directory. 
Sigh.)

But back to the real world.  Regardless of how it "shoulda" been done, the fact is 
tens of thousands of directory administrators have independently decided how to 
optimize their directory information trees, and guess what -- very, very few of them
took into account issues of globally unambiguous names, common schema, etc..
Most directories that are deployed today do NOT have country=XX at their root, 
most don't use the legal name of the corporation at the organization level,
and most don't follow anything even approximating a common schema, much 
less one that would be very useful for providing the kind of quasi-legal relying 
party information that people tend to expect that a certificate would contain.  

(In fact, once when I was giving a talk on this subject I used to example of my own 
DN (or "context," in NDS-terms), i.e., bjueneman.nsrd.prv.novell, and one person 
nodded approvingly saying that yes, all of their directory names ended in novell as 
well, since they were using NDS and NetWare!!

So this is the current reality, whether we like it or not. By FAR the most widely deployed
directory is NDS, with something on the order of 80 million users.  That's not to say 
that there aren't other directories out there, either as vaporware or for real, but they
don't have anywhere near the deployed base.  And NDS users in general have not
interconnected their directories with other users -- at least not yet.

What they are beginning to do, however, is to try to figure out how they can use their
already deployed directory structure (deployed to provide access control to print and
file servers, originally) to make use of these new-fangled certificate thingumabobs
we call a PKI.  First they are going to make use of their directory structure to support
internal applications, such as to authenticate a user's access to the PeopleSoft 
database so people can look at their 401K status and their other benefits.  

(And BTW, that is going to give rise to the first REAL use of nonrepudiation, one 
that will have nothing whatsoever to do with the commonly discussed model of retail 
commerce or banking, and will in fact be an open PKI where we have to deal 
with the so-called widows and orphans model of relying parties, because people 
will begin to do things that have real legal consequences, such as changing 
their life insurance beneficiaries, and their very real widows and dependents will 
want to rely on the digitally signed copy of the policy changes Dad left them.)

But back to the original point of this thread.  Sooner or later, those companies 
are going to start using S/MIME for their e-mail, including e-mail that goes outside the
company. Likewise, they may open up their firewall a crack to allow external users, e.g.,
customers, to access their networks to place just-in-time manufacturing orders, etc.

In the process, they are going to need to have a way of finding and validating
the certificates that are used to back up a digitally signed transaction, and sooner
or later they are going to get tired of sending the same set of certificates down the 
line over and over again.  Assuming that S/MIME provides a way of knowing the
originator's name, either in the form of a RFC822 e-mail name or some kind of a more
"normal" DN, then LDAP (or DAP) could be used to retrieve that certificate as 
necessary, and could also continue on to retrieve the rest of the certificates in the
chain.

But...

How does the relying party's software know in which directory that user's certificate is 
to be found, much less the issuer's certificate, absent the global PKI/directory in the sky?

In the e-mail name case, the RP is nearly clueless, because the e-mail name doesn't 
necessarily have anything at all to do with the originator's organization.  I routinely 
send to and receive mail from people who are using what appears to be a 
personal e-mail account for business purposes -- for one thing, they might like to 
have a certain consistency in their e-mail address even if they change 
companies.  And some small companies might have started out small and didn't 
have their own e-mail server originally, and continue to contract out that function, 
even if they now issue their own certificates.  So the user's organization DNS name,
the e-mail provider's DNS name, and the CA's DNS name may all be different. And
if one organization includes their DNS name as a DN, and another uses their
geopolitical name as a DN, the problem is close to hopeless.

But even if the user's organization does have a directory, that organization may or may
not be the organization that issued the certificate, and may or may not store that 
certificate in a directory.  If I get a certificate from VeriSign, I am not compelled to store
that certificate in my own organization's directory.  And even if I do, there is no absolute
guarantee that I also store my issuer's certificate in that directory, especially if my issuer's 
name doesn't fit within my own organization's directory schema.  But someone
probably could find my certificate in VeriSign's directory, listed under my name, 
if they only knew to look there (and if VeriSign could figure out how to cope with my
particular schema).

So what I was proposing was a relatively simple, pragmatic solution to this problem.

Some of the previous commentary on this thread took one of two diametrically 
opposed positions -- either that the "only" way to solve this problem was to 
posit a single globally interconnected PKI cum directory; or that such a directory, 
and perhaps even a global PKI was not only unnecessary but undesirable, and 
maybe even unthinkable, even between consenting adults.

I would reject both of those positions.  I just want something that will work in today's
environment, that doesn't require me to take my little immersion heater down to the 
ocean shore and plug it in and wait until the water comes to a boil.

So I'll say again, wouldn't it be a Good Thing if we could have an optional attribute
in a certificate that is associated with the Issuer's name somehow, one that would 
provide the DNS name of an LDAP server that contains the Issuer's certificate?

At this point in time, I don't care particularly what form the attribute takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or it 
could be some other alternateSubjectName attribute, or some other attribute entirely.

But is there at least some agreement about the potential utility of this concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, "Flanigan, Bill" <[email-masked]>, "'Eric Bomarsi'" <[email-masked]>
Cc: "'Al Arsenault'" <[email-masked]>, <[email-masked]>
Subject: RE: Yes, and remove more of the alphabet from the PKIX soup
Date: Tue, 16 Feb 1999 11:26:29 -0500
Importance: Normal
Sender: [email-masked]

> > I hope that means future CMP work is limited to incremental
> > fixes and improvements rather than competing with CMC
> > enhancements. Is this the case?
> > 
> These protocols need not be viewed as competing at all.  Many that I have
> spoken with seem to share the view that CMP is currently the 
> clear protocol
> for many enterprise environments,

I'm not particularly keen on this mode of argument, sourcing opinions
to anonymous sources does not seem quite fair. In any case many folk 
I have spoken to are under the influence of all sorts of bizare beliefs,
if we are meant to reject 'Popes, Kings and voting' then perhaps
we can also leave out unsourced opinion polls?

> CMC, on the other hand, may well mature to be the clear
> protocol for the Internet, along with some other repository technology
> (perhaps DNS), some other revocation technology (perhaps OCSP), 
> etc., etc..

I think that this is Bill's point. CMC is the IETF incarnation of the
protocol which is already the de-facto Internet protocol. Providing
the working group does not break backwards compatibility in the
standard drafting process it appears that CMC will be the Internet
standard.

Which is not something I would have expected you to accept since the
mandate of the Internet Engineering Task Force is limited to the 
standardization of Internet protocols.

If you can provide concrete suggestions for how we can overcome the
undefined shortcommings you see in CMC you should send them to the
list. The historical precedent has been that Internet protocols
trump those which are limited to 'enterprise' scope - for the 
obvious reasons of vendor interoperability and the fact that most
intranets turn out to have multiple domains of administrative
control, thus making them Internets.

I don't understand the point you are making regarding DNS and OCSP.
Clearly OCSP is one option for certificate revocation - but nobody
is suggesting that if you use CMC then you must also use OCSP. 
Equally there is no bar to users of CMP using OCSP (except to the
extent that the only vendor of CMP products does not at 
present support OCSP).

Nor is anyone proposing that DNS is an alternative for X.500/LDAP,
DNS is not a certificate repository! The issue is where the boundary
between the name space and the repository should lie. My argument
is simply that whatever means you choose for your certificate
repository (X.500, LDAP, HTTP, a custom kludge), that DNS should 
allow the location of the relevant certificate repository for a
DNS name. Again the issue is at least equally relevant to CMP.

		Phill

To: "Phillip M Hallam-Baker" <[email-masked]>
Cc: "Andrew Probert" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Finding PKIX Servers!
From: EKR <[email-masked]>
Date: 16 Feb 1999 08:17:05 -0800
Lines: 42
Sender: [email-masked]

"Phillip M Hallam-Baker" <[email-masked]> writes:
> > 	[Andrew Probert]  My personal experience is that strong
> > authentication has been pushed down into SSL model, then I had to 
> > do lots of
> > backflips and spend real development $$ to intercept SSL strong
> > authentication, encode it as HTTP header vars and pass it back up to my
> > applications which were on top of HTTP.  (Live ecommerce site, now doing
> > 20,000 transactions per month)
> 
> Which is why Eric and myself were integrating strong authentication 
> at the transfer/message layer. I still don't believe it is necessary
> to waste a round trip delay on a separate BIND operation.
Neither do I. 

> I don't see why an SSL implementation should have difficulty providing
> the necessary information to the application. Certainly I am familliar
> with several APIs which have provided the necessary information.
Correct. If you have to jump through hoops to get this information,
it's not because of a deficiency in SSL, but merely because of
your implementation. (Not that I haven't seen such implementations).
This is encouraged by the use of CGI, where pretty much everything
has to be stuffed in such variables.

> > 	[Andrew Probert]  Agree SSL is a good model and does cache access
> > control.  However, policy regarding timeouts of SSL sessions and 
> > generation
> > of new session keys is weak e.g. do I need to re-authentication every 10
> > minutes, 1 hour etc, normally a server side setting!
> 
> I believe the TLS folk have been addressing this.
Not particularly well. There's a sort of consensus that a day
is about right, but it's not written down as a requirement.

That said, it can't be only a server setting. Both client and
server have to agree. To see why, realize that clients typically
store this information in memory, so there's got to be a way
for the client to not cache the information. 

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

Date: Tue, 16 Feb 1999 10:46:05 -0500
To: Trevor Freeman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Trevor,

I am puzzled by your statements. It is true that CRLs have some facilities
to explicitly mark which classes of certs may be contrained in them, e.g.,
only CA certs or only some revocation reason codes.  However, there is no
prohibition
against round robin assignment of certs to different CRLs through the use
of the CRL distribution point extension.  In fact, that would seem to be a
major feature of this extension.  Perhaps you are raising the question of
how one ought to note, in the CRL itself, that only a subset of certs
(e.g., partiitioned by serial number) are contained in a given CRL.

Steve

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Alan Lloyd" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Tue, 16 Feb 1999 10:47:02 -0500
Importance: Normal
Sender: [email-masked]

Oh goody, protocol correctness!

> Comments in line - to  more incorrect statements

> >  This is the 'directory
> > dependent' model of PKI, I don't like that idea.

> 	Thats because I think you are not seeing the utility of
> directory systems correctly.

Alan, if you can't respect other members of the working group
you are completely wasting your time here.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Andrew Probert" <[email-masked]>, <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Tue, 16 Feb 1999 10:26:36 -0500
Importance: Normal
Sender: [email-masked]

> 	[Andrew Probert]  I am not taking a dig at HTTP, merely stating a
> partitioning example of functionality up into infrastructure, the 
> work's got
> to be done somewhere!

Not if it is make work. The problem with FTP and to a lesser extent 
X.500 DAP is that the model is of a user at a terminal interfacing 
to a database. So the protocol follows the steps the user would take,
first login, then perform a series of transactions, then log out.

> 	Why do you think BIND/UNBIND is unnecessary?  

The authentication handshake need not be separated from the data
request. In general the authentication handshake and a URL will
easilly fit into a packet. Combining the two is much more efficient.

> 	[Andrew Probert]  My personal experience is that strong
> authentication has been pushed down into SSL model, then I had to 
> do lots of
> backflips and spend real development $$ to intercept SSL strong
> authentication, encode it as HTTP header vars and pass it back up to my
> applications which were on top of HTTP.  (Live ecommerce site, now doing
> 20,000 transactions per month)

Which is why Eric and myself were integrating strong authentication 
at the transfer/message layer. I still don't believe it is necessary
to waste a round trip delay on a separate BIND operation.

I don't see why an SSL implementation should have difficulty providing
the necessary information to the application. Certainly I am familliar
with several APIs which have provided the necessary information.

> 	[Andrew Probert]  Agree SSL is a good model and does cache access
> control.  However, policy regarding timeouts of SSL sessions and 
> generation
> of new session keys is weak e.g. do I need to re-authentication every 10
> minutes, 1 hour etc, normally a server side setting!

I believe the TLS folk have been addressing this.

		Phill

Date: Tue, 16 Feb 1999 08:11:31 -0500
To: "Aniruddha Shrotri" <[email-masked]>, <[email-masked]>
From: Al Arsenault <[email-masked]>
Subject: Re: Questions regarding RAs
Sender: [email-masked]

Ani,

	In answer to some of your questions:

At 02:22 PM 2/16/99 +0000, Aniruddha Shrotri wrote:
>Hi all,
>
>I have some questions related to Registration Authorities (RAs), variously
>referred to as LRAs, ORAs, registration agents in various parts of the PKIX
>suite of drafts and falls under the PKI Management entities category:
>
>
>1. In the model where a CA is serving several RAs which in turn are serving
>several EEs each, are there any formal ways for the CA to divide the
>name-space between the RAs ? In case of CA hierarchies, the old PEM model
>used a strictly hierarchical structure even for name-spaces, i.e., the DN of
>a subordinate CA had to be strictly in the subtree with the parent CA as the
>root of that subtree, and similarly, the EEs' DN had to be in the subtree
>under the penultimate CA. Later, in the current standards, this was amended
>to use Name Space constraints. The parent CA can use Name Space constraint
>extension to limit the scope of a subordinate CA. However, this extension is
>currently defined only for a CA certificate. Would it make sense to use this
>extension for an RA certificate ? Or is the division of name-space between
>RAs a local implementation matter ?
>
>
AWA:  It's a local implementation matter.  Essentially, an RA is only
sending a request to a CA:  "Will you please sign & issue this cert, for
this user, whom I (may) have determined is the right owner, possesses the
private key, and is entitled to these properties?"  It's up to the CA to
make the decision and enforce whatever rules apply.

A CA's local policy could certainly be set up to enforce "RA's can only
request certificates in certain name subtrees, and any request for a name
not in that subtree will be rejected", but that shouldn't be mandated as
any part of a standard.

>
>2. Continuing on name-space issue, Section 5.1.2 of PKIX RoadMap says:
>
>"Suppose for example that a rootCA is established with DN "O=IETF,
>OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for names
>subordinate to it."
>
>Is this strictly true ? Is the CA required to issue certificates *only* for
>names subordinate to it ? This will be true only if the Name constraints in
>the CA's cert mention this DN in the included subtrees. In general, there
>need not be any relation between the CAs DN and the DN of the EEs that it
>is certifying. If it is there, it will only be a local policy /
>implementation issue and not an issue which standards should enforce.
>

AWA:  Oops, darned unfortunate wording there.  That section is referring to
the fact that names in PKIX don't have to be "globally unique", just unique
within a domain of interest.  Name constraints and "name subordination"
aren't even relevant.  We'll figure out some alternative wording that gets
the same point across, without dragging in name constraints.

>
>3. How does one figure out from an EE's cert which RA it belongs to ? Is
>this even a requirement ? What bearing does the current thread of discussion
>"Finding PKIX Servers" have on this question, considering that the EEs will
>typically consider the RAs as their PKIX Server.
>

AWA:  This is a "local matter", you can't in general expect to find out
which RA to contact from looking at an EE's cert.  If you really wanted to
do it in your specific case, there are several ways it could be
accomplished, but it's not mandatory and not everybody wants to do it.

>
>
>
>4. What purpose does a "hierarchy" of RAs serve ? Particularly, considering
>that the "hierarchy" of RAs would have no relation to the trust hierarchy.
>That is, is it reasonable to have an architecture where an RA registers
>not only end entities (EEs) but other RAs ? CMC allows for such a thing and
>other parts of PKIX drafts do not preclude it. It does have some utility for
>distributing the proofing and registration responsibilities. But couldn't
>same purpose be served by having additional RAs at the same level ?
>
>
>
>5. Does it make sense for a top level RA to be under multiple CAs ? This
>certainly is indicated as a possibility in section 1.2.3 of CMP. In this
>case, how does the RA route the cert request it gets from an end entity
>to the appropriate CA ?
>

AWA:  Yes, I've built PKIs in which RAs are subordinate to mulitple
different CAs.  Basically, the RA has to have a database/rule engine/some
other algorithm by which it looks at an EE request and says "this goes to
CA1" or "this goes to CA2".  For example, the RA could make its decision
based on the EE's name; or on the source of the request (e.g, the subnet or
domain); or on some other attribute in the requested certificate.

					Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.

Date: Tue, 16 Feb 1999 11:20:21 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Validation of Electronic Signatures
Sender: [email-masked]

The validation of Electronic Signatures poses several difficult and
interesting problems, in particular when it is necessary to validate
an Electronic signature for example 20 years later, when the signer
key has been compromised and revoked, the CA keys have been
compromised, the crypto algorithm or key length used at the
signature time is no longer secure, and the hash function
used at at the signature time now exhibits message collisions.

The validation problem changes over the different time frames:
- near term, when all involved certificates are still valid and
  generally available,
- long term, when one or more of the involved certificates have expired,
- archival, when the initial cryptography used is no longer secure.

Another interesting point to consider is how it is possible to know and
trust the signing time as indicated by the signer.

A "white paper" dealing with these kinds of situations has been written and
demonstrates the use of time-stamping.

This paper can serve as a tutorial to this difficult subject, but also as
input for the discussion of a common validation model for electronic
signatures. The paper can be found at the following addresses:

http://www.openmaster.com/whitepapers/es_validation.pdf
http://www.id2tech.com/news/pdf/ES_validation.pdf

Denis Pinkas

From: "Aniruddha Shrotri" <[email-masked]>
To: <[email-masked]>
Subject: Questions regarding RAs
Date: Tue, 16 Feb 1999 14:22:31 -0000
Sender: [email-masked]

Hi all,

I have some questions related to Registration Authorities (RAs), variously
referred to as LRAs, ORAs, registration agents in various parts of the PKIX
suite of drafts and falls under the PKI Management entities category:

1. In the model where a CA is serving several RAs which in turn are serving
several EEs each, are there any formal ways for the CA to divide the
name-space between the RAs ? In case of CA hierarchies, the old PEM model
used a strictly hierarchical structure even for name-spaces, i.e., the DN of
a subordinate CA had to be strictly in the subtree with the parent CA as the
root of that subtree, and similarly, the EEs' DN had to be in the subtree
under the penultimate CA. Later, in the current standards, this was amended
to use Name Space constraints. The parent CA can use Name Space constraint
extension to limit the scope of a subordinate CA. However, this extension is
currently defined only for a CA certificate. Would it make sense to use this
extension for an RA certificate ? Or is the division of name-space between
RAs a local implementation matter ?

2. Continuing on name-space issue, Section 5.1.2 of PKIX RoadMap says:

"Suppose for example that a rootCA is established with DN "O=IETF,
OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for names
subordinate to it."

Is this strictly true ? Is the CA required to issue certificates *only* for
names subordinate to it ? This will be true only if the Name constraints in
the CA's cert mention this DN in the included subtrees. In general, there
need not be any relation between the CAs DN and the DN of the EEs that it
is certifying. If it is there, it will only be a local policy /
implementation issue and not an issue which standards should enforce.

3. How does one figure out from an EE's cert which RA it belongs to ? Is
this even a requirement ? What bearing does the current thread of discussion
"Finding PKIX Servers" have on this question, considering that the EEs will
typically consider the RAs as their PKIX Server.

4. What purpose does a "hierarchy" of RAs serve ? Particularly, considering
that the "hierarchy" of RAs would have no relation to the trust hierarchy.
That is, is it reasonable to have an architecture where an RA registers
not only end entities (EEs) but other RAs ? CMC allows for such a thing and
other parts of PKIX drafts do not preclude it. It does have some utility for
distributing the proofing and registration responsibilities. But couldn't
same purpose be served by having additional RAs at the same level ?

5. Does it make sense for a top level RA to be under multiple CAs ? This
certainly is indicated as a possibility in section 1.2.3 of CMP. In this
case, how does the RA route the cert request it gets from an end entity
to the appropriate CA ?

I have tried to look at the mailing list archives to see if these issues
were discussed before, but could not find any definitive references. It is
possible that I might have missed some threads and I apologize in advance if
that indeed has happened.

Thanks

Ani

----------------------------------------------
Aniruddha P. Shrotri (ani)
Director Engineering, E-Lock Technologies Inc.
----------------------------------------------

Date: Tue, 16 Feb 1999 09:28:59 +0200
From: Moshe Litvin <[email-masked]>
To: Trevor Freeman <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Usage of CRL Issuing Distribution Point
Sender: [email-masked]

Trevor,

A CA can divide the certificate to CRL without telling anyone about the reason
for the division. All it should do it put in the CDB the name (location) of the
CRL, and issue an appropriate CRL with the corresponding IDP.

It can even divide the certificate to CRLs according to the third letter of the
CN. The relying party doesn't have to know or care why it divided it that way.
All that important is that it has a way to retrieve the CRL  (the
DistributionPointName attribute), and when it got it to verify that it
correspond to the certificate (by comparing the IDP).

Moshe

Trevor Freeman wrote:

> Alex,
> While I agree it is not the intent of the standard to exclude future
> development and future work may well do as you suggest. As of today with
> RFC2459, bottom line is still that the documented extensions cannot do as
> you suggest.
>
> -----Original Message-----
> From: Alex Deacon [mailto:[email-masked]]
> Sent: Friday, February 12, 1999 2:24 PM
> To: Trevor Freeman
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
>
> >From reading the docs, I don't get the impression that CDP and IDP
> explicitly exclude the use other attributes.  I take this to (implicitly)
> imply that other attributes CAN be used to partition CRL's. Is this to big
> of a leap of faith to make?
>
> Partitioning a CRL by serialNumber sounds very reasonable to me.  So does
> partitioning a CRL by some extension value which may be present in all certs
> issued by a particular CA.  Why not partition a CRL by using the notBefore
> validity date on the cert?  Or, perhaps the CA keeps an internal counter and
> creates a new partition for every 20 certs it issues.  In an extreme case,
> you may want each cert to have it own CRL partition.
>
> If CDP's and IDP's are being used properly, (i.e. they are present in all
> certs and CRL's issued by a CA) then what difference does it make as to how
> the partitions were created?
>
> Alex
>
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Friday, February 12, 1999 12:47 PM
> > To: 'Alex Deacon'
> > Cc: [email-masked]'
> > Subject: RE: Usage of CRL Issuing Distribution Point
> >
> >
> > What extensions in these documents provide for other
> > attributes to be used
> > to partition CRLs?
> > -----Original Message-----
> > From: Alex Deacon [mailto:[email-masked]]
> > Sent: Friday, February 12, 1999 12:40 PM
> > To: Trevor Freeman
> > Cc: [email-masked]'
> > Subject: RE: Usage of CRL Issuing Distribution Point
> >
> >
> > Trevor,
> >
> > Could you specify what document states that it is not
> > permitted for CRL's to
> > be partitioned on the basis of other attributes such as
> > serial number?  I
> > cant recall ever seeing such a statement in either PKIX Part
> > 1 or X.509.
> >
> > Thanks
> > Alex
> >

--
-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

[email-masked]            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------

From: Andrew Probert <[email-masked]>
To: [email-masked]
Subject: Appropo finding X.509 Names
Date: Tue, 16 Feb 1999 09:37:42 +1100
Sender: [email-masked]

Appropo registration of X.509 names.

The Dante project is running a web page pointing to national authorities -
USA / ANSI, UK - BSI etc.

http://www.dante.net/np/reg-auth.html

I am sure there are lots more....  Please let them know..

Note, this does not prescribe interconnectivity, but it is the mechanism for
name registration into the X.500 namespace.

These standards authorities can register your OID prefix for you.  Here,
Standards Australia have a neat optimisation where OIDs are by convention
encoded as 1.2.36.AustralianCompanyNumber, so every incorporated company has
their OID prefix pre-assigned!

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Andrew Probert [SMTP:[email-masked]]
> Sent:	Monday, February 15, 1999 9:44 AM
> To:	'Phillip M Hallam-Baker'; [email-masked]; Andrew Probert
> Cc:	David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> Disagree on some items..
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  +61 3 9690 8877
> Fax +61 3 9690 8171
> 
> 
> 
> > -----Original Message-----
> > From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> > Sent:	Saturday, February 13, 1999 3:36 AM
> > To:	[email-masked]; Andrew Probert
> > Cc:	David P. Kemp; [email-masked]
> > Subject:	RE: Finding PKIX Servers!
> > 
> 	[Andrew Probert]  <snip>
> > Actually, the idea we had was to remove the unnecessary work from
> > the application. FTP's twin connection is far more complex for any
> > application to manage than the HTTP 'idempotent request' model.
> > Similarly the LDAP BIND operation achieves nothing of real value.
> > 
> > The 'complexity' of HTTP/1.1 is due to the caching model. No other
> > retrieval protocol I am aware of has any caching model - the
> applications
> > were too busy performing unnecessary operations such as BIND and UNBIND.
> > Caching is not a particular burden on applications however.
> > 
> 	[Andrew Probert]  I am not taking a dig at HTTP, merely stating a
> partitioning example of functionality up into infrastructure, the work's
> got
> to be done somewhere!
> 
> 	Why do you think BIND/UNBIND is unnecessary?  
> 
> 
> > Even with every 1.1 boondoggle, HTTP is by far the most straightforward
> > protocol to implement at the application level.
> > 
> 	[Andrew Probert]  My personal experience is that strong
> authentication has been pushed down into SSL model, then I had to do lots
> of
> backflips and spend real development $$ to intercept SSL strong
> authentication, encode it as HTTP header vars and pass it back up to my
> applications which were on top of HTTP.  (Live ecommerce site, now doing
> 20,000 transactions per month)
> 
> 	Where's the integrated authentication in this model?
> >  
> > In retrospect I think that the confusion that HTTP ended concerned
> > the interface between the authentication/authorization model (an
> > application concern) and the transport connection. 
> 	[Andrew Probert]  Disagree, see above.
> > For some reason it
> > was assumed to be a good idea to keep TCP/IP sessions going
> > indefinitely - instead of simply caching the access control context
> > at each end.
> > 
> 	[Andrew Probert]  Agree SSL is a good model and does cache access
> control.  However, policy regarding timeouts of SSL sessions and
> generation
> of new session keys is weak e.g. do I need to re-authentication every 10
> minutes, 1 hour etc, normally a server side setting!
> 
> > Unfortunately some folk took this a bit far, maybe Eric can remember
> > the name of that chap from Chicago who he used to work with who had
> > the idea of downloding every image in a page as a separate TCP/IP
> > connection. That was definitely a bad idea!
> > 
> 	[Andrew Probert]  Agree..
> 
> > 		Phill

From: Trevor Freeman <[email-masked]>
To: "'Alex Deacon'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Mon, 15 Feb 1999 10:56:31 -0800
Sender: [email-masked]

Alex,
While I agree it is not the intent of the standard to exclude future
development and future work may well do as you suggest. As of today with
RFC2459, bottom line is still that the documented extensions cannot do as
you suggest.  

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
Sent: Friday, February 12, 1999 2:24 PM
To: Trevor Freeman
Cc: [email-masked]'
Subject: RE: Usage of CRL Issuing Distribution Point

>From reading the docs, I don't get the impression that CDP and IDP
explicitly exclude the use other attributes.  I take this to (implicitly)
imply that other attributes CAN be used to partition CRL's. Is this to big
of a leap of faith to make? 

Partitioning a CRL by serialNumber sounds very reasonable to me.  So does
partitioning a CRL by some extension value which may be present in all certs
issued by a particular CA.  Why not partition a CRL by using the notBefore
validity date on the cert?  Or, perhaps the CA keeps an internal counter and
creates a new partition for every 20 certs it issues.  In an extreme case,
you may want each cert to have it own CRL partition.

If CDP's and IDP's are being used properly, (i.e. they are present in all
certs and CRL's issued by a CA) then what difference does it make as to how
the partitions were created?  

Alex

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, February 12, 1999 12:47 PM
> To: 'Alex Deacon'
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> What extensions in these documents provide for other 
> attributes to be used
> to partition CRLs? 
> -----Original Message-----
> From: Alex Deacon [mailto:[email-masked]]
> Sent: Friday, February 12, 1999 12:40 PM
> To: Trevor Freeman
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> Trevor, 
> 
> Could you specify what document states that it is not 
> permitted for CRL's to
> be partitioned on the basis of other attributes such as 
> serial number?  I
> cant recall ever seeing such a statement in either PKIX Part 
> 1 or X.509.
> 
> Thanks
> Alex
> 

From: Alan Lloyd <[email-masked]>
To: [email-masked], [email-masked]
Subject: A white paper on directory based messaging and transaction system s FYI
Date: Mon, 15 Feb 1999 11:51:38 +1100
Sender: [email-masked]

Dear all - this is a futures paper - FYI
comments welcome
regards alan
http://www.opendirectory.com/Whitepapers/DirMail.html

From: Alan Lloyd <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 15 Feb 1999 11:31:00 +1100
Sender: [email-masked]

Comments in line - to  more incorrect statements

> -----Original Message-----
> From:	Phillip M Hallam-Baker 
> Sent:	Thursday, February 11, 1999 8:03 AM
> To:	David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> > I'm at a loss to understand Phill's suggestion to use DNS SRV
> records
> > (instead of just putting the CA's URL in the cert itself), and Alan
> > Lloyd's suggestion that putting a URL in a cert would require an
> > army of administrators.  Running a directory tightly coupled to
> > the security management infrastructure requires the army; running
> > a loosely coupled directory/repository named in a URL is easier.
> 
> The URL in the cert method is fine but some folk have a problem. For
> example
> the revocation service may be other than the CA originally specified.
> It may
> not be possible to access the URL specified in the Cert when the time
> comes
> to rely on it.
	Absolutly - in addition if a URL is tied to a server - and not a
named object in a directory system - that may be replicated for
redundancy and local context reasons to ensure serviceability, then
using URLs would be restrictive. 

> My interpretation of Alan's post was that he is proposing much more.
> He wants to weld the PKI to the directory so that if the Directory is
> down it is certain the PKI will be as well.
> 
	What if DNS goes down, or the cert database, or the (anything
else you want to name) goes down.   

	Can I repeat this yet again 
	A PKI is a function  - a directory is a function - they are
applied with products into an operational system according to the system
design and business requirements.
	ie if  I remove the old fashion database from the PKI function
and replaced it with a directory on the same platform - and this was not
connected to the world - the system has the same construction and
limitations , but using the directory service instead of a traditional
RDB  - means that it can use the standard distribution, replication and
authentication/ACI features to connect with other PKI and directory
processes as the system scales - in a uniform manner.

	A database approach is a restricted approach - a directory
approach - for the same cost - offers functional and information
scaleability.

>  This is the 'directory
> dependent' model of PKI, I don't like that idea.
	Thats because I think you are not seeing the utility of
directory systems correctly.

> The 'directory linked' approach I believe is sensible uses the
> directory,
> but only for purposes that are a good fit - i.e. locating parties -
> One problem is how you obtain the cert in the first place given that
> you probably are looking for a Cert which maps to [email-masked] so you
> can
> do email. URLs in the cert don't help in this case :-)
	Perhaps we are looking for a Cert by the DN = subject name in a
directory system.

> According to Alan you go to the Global X.500 directory system and
> perform a lookup. This approach only has three problems, first no such
> directory exists, 
> 
	wrong perception - a directory is a function that is being
applied - There will never be ONE and only ONE directory service. eg we
have a public telephone system - we also have many private networks for
voice communication...
	One tends to build systems - that have a sphere of influence -
and the naming and service provisioning issues are tied to that.

> second if it did it might get tiresome doing a search of
> the entire directory space for an entry with the right attribute, 
> 
	directories dont actually do that - operationally (real world
again :-)) - and this comment is a pointless comment.
	directories are about defined schema with reasonably defined
accesses - if you dont apply this then  limit parameters
(size/time/context) get applied by the system.
> third
> X.500 is only standardized over the OSI network stack and not over IP,
> 
	this is wrong, wrong and wrong - I think all those who have ever
dealt with directory systems at all KNOW that DAP, DSP, DISP and LDAP do
run over TCP/IP
> LDAP does not include the replication protocols being promoted as the
> basis
> for the 'global scalability' claim.
	? well we all know about the limitations of LDAP. That is why
the industry is using it for access only and X.500 for the core systems.

> In conclusion I really don't know why we need the argument. We have
> established a function for directories in PKIX that makes sense. We
> have revocation mechanisms which make sense. I don't know why we need
> to conflate revocation of authentication credentials and the
> directory.
> Authorization credentials might be another matter, but those are not
> currently in PKIX scope.
> 
	But these are in the scope of those who are designing systems
that incorporate PKI, directories, messaging, information management,
and end user services. Just because the PKIX  group explicitly has not
dealt with distributed and mutual authentication across large scale
information systems using X.509 - it does not mean that a) it wont be,
b) it wont take input from those that do or c) that those who deal with
the bigger issues of PKI - dont want to understand these things in an
open forum.

	I think first and foremost - is not useful to put statements on
this list (for debate) that are so wrong.
	Secondly it must be seen that PKIs without directory capability
at the functional level will hit scaling issues by definition.
	And that there are those around this planet (lots of us) that
understand directory systems at many levels, and PKI systems at many
levels who see the value and utility in applying both - Big customers
have recognised such integration and benefit.

	To debate the integration of two functions with incorrect
statements about one of them is absolutely pointless.
	regards alan
> 		Phill

From: Andrew Probert <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, [email-masked], Andrew Probert <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 15 Feb 1999 09:44:25 +1100
Sender: [email-masked]

Disagree on some items..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Saturday, February 13, 1999 3:36 AM
> To:	[email-masked]; Andrew Probert
> Cc:	David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
	[Andrew Probert]  <snip>
> Actually, the idea we had was to remove the unnecessary work from
> the application. FTP's twin connection is far more complex for any
> application to manage than the HTTP 'idempotent request' model.
> Similarly the LDAP BIND operation achieves nothing of real value.
> 
> The 'complexity' of HTTP/1.1 is due to the caching model. No other
> retrieval protocol I am aware of has any caching model - the applications
> were too busy performing unnecessary operations such as BIND and UNBIND.
> Caching is not a particular burden on applications however.
> 
	[Andrew Probert]  I am not taking a dig at HTTP, merely stating a
partitioning example of functionality up into infrastructure, the work's got
to be done somewhere!

	Why do you think BIND/UNBIND is unnecessary?  

> Even with every 1.1 boondoggle, HTTP is by far the most straightforward
> protocol to implement at the application level.
> 
	[Andrew Probert]  My personal experience is that strong
authentication has been pushed down into SSL model, then I had to do lots of
backflips and spend real development $$ to intercept SSL strong
authentication, encode it as HTTP header vars and pass it back up to my
applications which were on top of HTTP.  (Live ecommerce site, now doing
20,000 transactions per month)

	Where's the integrated authentication in this model?
>  
> In retrospect I think that the confusion that HTTP ended concerned
> the interface between the authentication/authorization model (an
> application concern) and the transport connection. 
	[Andrew Probert]  Disagree, see above.
> For some reason it
> was assumed to be a good idea to keep TCP/IP sessions going
> indefinitely - instead of simply caching the access control context
> at each end.
> 
	[Andrew Probert]  Agree SSL is a good model and does cache access
control.  However, policy regarding timeouts of SSL sessions and generation
of new session keys is weak e.g. do I need to re-authentication every 10
minutes, 1 hour etc, normally a server side setting!

> Unfortunately some folk took this a bit far, maybe Eric can remember
> the name of that chap from Chicago who he used to work with who had
> the idea of downloding every image in a page as a separate TCP/IP
> connection. That was definitely a bad idea!
> 
	[Andrew Probert]  Agree..

> 		Phill

From: "Ambarish Malpani" <[email-masked]>
To: <[email-masked]>
Subject: CRL Distribution Points
Date: Sat, 13 Feb 1999 19:02:09 -0800
Importance: Normal
Sender: [email-masked]

Hi All,
    I would like to repost a question I had asked in a previous
mail (in case it got lost).

Here goes:

Are there any CAs/product vendors that support CRLDP as a way to
break up a CRL into smaller chunks, or is everybody just
using CRLDP to point to the one monolithic CRL they publish?

Also, is anybody using CRLDP to create multiple CRLs (potentially
published at different frequencies), where the CRLs are
used for different revocation reasons - keyCompromise etc.

Anybody using CRLDP in other interesting ways?

Anybody planning to support CRLDP in all these different modes?

If people don't want to post to the whole list, I would
still appreciate private emails (and if there is no
confidentiality involved, would be happy to post a summary
on the list).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

From: "Ambarish Malpani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Fri, 12 Feb 1999 17:17:29 -0800
Importance: Normal
Sender: [email-masked]

I agree with Alex's interpretation of the spec. There is
nothing to prevent a CA from creating a new DP for every n
certificates it issues. All it needs to do, is give the new
DP a name and put that name in the certificate. 

Any application that is trying to verify the status of that
certificate, can go retrieve the appropriate DP and ensure
that the cert isn't in it.

By the way, are there any CAs that support CRLDP as a way to
break up a CRL into smaller chunks, or is everybody just
using CRLDP to point to the one monolithic CRL they publish?

Also, is anybody using CRLDP to create multiple CRLs (potentially
published at different frequencies), where the CRLs are
used for different revocation reasons - keyCompromise etc.

Anybody planning to support CRLDP in those ways?

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Alex Deacon
> Sent: Friday, February 12, 1999 2:24 PM
> To: 'Trevor Freeman'
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> 
> >From reading the docs, I don't get the impression that CDP and IDP
> explicitly exclude the use other attributes.  I take this to 
> (implicitly)
> imply that other attributes CAN be used to partition CRL's. 
> Is this to big
> of a leap of faith to make? 
> 
> Partitioning a CRL by serialNumber sounds very reasonable to 
> me.  So does
> partitioning a CRL by some extension value which may be 
> present in all certs
> issued by a particular CA.  Why not partition a CRL by using 
> the notBefore
> validity date on the cert?  Or, perhaps the CA keeps an 
> internal counter and
> creates a new partition for every 20 certs it issues.  In an 
> extreme case,
> you may want each cert to have it own CRL partition.
> 
> If CDP's and IDP's are being used properly, (i.e. they are 
> present in all
> certs and CRL's issued by a CA) then what difference does it 
> make as to how
> the partitions were created?  
> 
> Alex
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Friday, February 12, 1999 12:47 PM
> > To: 'Alex Deacon'
> > Cc: [email-masked]'
> > Subject: RE: Usage of CRL Issuing Distribution Point
> > 
> > 
> > What extensions in these documents provide for other 
> > attributes to be used
> > to partition CRLs? 
> > -----Original Message-----
> > From: Alex Deacon [mailto:[email-masked]]
> > Sent: Friday, February 12, 1999 12:40 PM
> > To: Trevor Freeman
> > Cc: [email-masked]'
> > Subject: RE: Usage of CRL Issuing Distribution Point
> > 
> > 
> > Trevor, 
> > 
> > Could you specify what document states that it is not 
> > permitted for CRL's to
> > be partitioned on the basis of other attributes such as 
> > serial number?  I
> > cant recall ever seeing such a statement in either PKIX Part 
> > 1 or X.509.
> > 
> > Thanks
> > Alex
> > 
> 

From: Carlisle Adams <[email-masked]>
To: "Flanigan, Bill" <[email-masked]>, "'Eric Bomarsi'" <[email-masked]>
Cc: "'Al Arsenault'" <[email-masked]>, [email-masked]
Subject: RE: Yes, and remove more of the alphabet from the PKIX soup
Date: Fri, 12 Feb 1999 18:38:45 -0500
Sender: [email-masked]

Hi Eric,

> ----------
> From: 	Eric Bomarsi[SMTP:[email-masked]]
> Sent: 	Friday, February 12, 1999 1:17 PM
> To: 	Flanigan, Bill
> Cc: 	'Al Arsenault'; [email-masked]
> Subject: 	Re: Yes, and remove more of the alphabet from the PKIX soup
> 
> Al and Bill:
> 
> Thanks, the chronology helps put things in perspective.
> 
> It sounds as though some view CMC as the next phase
> certificate management protocol which will address
> deficiencies in CMP and CRS.
> 
Some may perhaps view it in this way, but I would propose that this is not a
correct view.

> I hope that means future CMP work is limited to incremental
> fixes and improvements rather than competing with CMC
> enhancements. Is this the case?
> 
These protocols need not be viewed as competing at all.  Many that I have
spoken with seem to share the view that CMP is currently the clear protocol
for many enterprise environments, along with LDAP/X.500 repositories, CRLs,
etc., etc..  CMC, on the other hand, may well mature to be the clear
protocol for the Internet, along with some other repository technology
(perhaps DNS), some other revocation technology (perhaps OCSP), etc., etc..
[This is not to say that there can be no mix-and-match in the two
environments, but at the moment they seem to fall more neatly into these two
categories.]

Certificate management in the Internet is not yet a solved problem, but some
of these protocols and technologies are helping that situation.  Certificate
management in the enterprise environment is quite a bit clearer.  CMP and
CMC need not compete; they may simply be seen as complementary (targeted at
different environments).

Carlisle.

From: [email-masked]
To: Alex Deacon <[email-masked]>
cc: "'Trevor Freeman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Fri, 12 Feb 1999 17:47:02 -0500
Subject: RE: Usage of CRL Issuing Distribution Point
Sender: [email-masked]

     Is there some confusion here between partitioning CRL's by certificate
attributes, which doesn't seem to be supported, and assigning new
certificates to CRL Distribution Points, which seems to be an internal
function of the CA with few rules except that the ID of the CRL
Distribution Point must go into the appropriate extension?

From: Alex Deacon <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Fri, 12 Feb 1999 14:24:28 -0800
Sender: [email-masked]

>From reading the docs, I don't get the impression that CDP and IDP
explicitly exclude the use other attributes.  I take this to (implicitly)
imply that other attributes CAN be used to partition CRL's. Is this to big
of a leap of faith to make? 

Partitioning a CRL by serialNumber sounds very reasonable to me.  So does
partitioning a CRL by some extension value which may be present in all certs
issued by a particular CA.  Why not partition a CRL by using the notBefore
validity date on the cert?  Or, perhaps the CA keeps an internal counter and
creates a new partition for every 20 certs it issues.  In an extreme case,
you may want each cert to have it own CRL partition.

If CDP's and IDP's are being used properly, (i.e. they are present in all
certs and CRL's issued by a CA) then what difference does it make as to how
the partitions were created?  

Alex

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, February 12, 1999 12:47 PM
> To: 'Alex Deacon'
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> What extensions in these documents provide for other 
> attributes to be used
> to partition CRLs? 
> -----Original Message-----
> From: Alex Deacon [mailto:[email-masked]]
> Sent: Friday, February 12, 1999 12:40 PM
> To: Trevor Freeman
> Cc: [email-masked]'
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> Trevor, 
> 
> Could you specify what document states that it is not 
> permitted for CRL's to
> be partitioned on the basis of other attributes such as 
> serial number?  I
> cant recall ever seeing such a statement in either PKIX Part 
> 1 or X.509.
> 
> Thanks
> Alex
> 

From: Trevor Freeman <[email-masked]>
To: "'Alex Deacon'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Fri, 12 Feb 1999 12:47:05 -0800
Sender: [email-masked]

What extensions in these documents provide for other attributes to be used
to partition CRLs? 
-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
Sent: Friday, February 12, 1999 12:40 PM
To: Trevor Freeman
Cc: [email-masked]'
Subject: RE: Usage of CRL Issuing Distribution Point

Trevor, 

Could you specify what document states that it is not permitted for CRL's to
be partitioned on the basis of other attributes such as serial number?  I
cant recall ever seeing such a statement in either PKIX Part 1 or X.509.

Thanks
Alex

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, February 12, 1999 11:07 AM
> To: 'Ambarish Malpani'; [email-masked]
> Cc: [email-masked]
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> 
> When a CA publishes a CRL, the CA should put sufficient 
> information into the
> CRL to unambiguous identify its intent. If you CA is only 
> generating one CDP
> per signing key, then issuer and key identity is sufficient. The key
> identity in AKI is just a hint to enable you to pick the 
> right CRL first for
> you signature check. It also helps if you want to cache CRL 
> locally. Issuing
> CDP is required once a CA starts to partition the CRL based 
> e.g. on reason
> code or subject type. The current RFC does not permit CRL to 
> be partitioned
> on the basis other attributes such as serial number. The 
> Issuing CDP of a
> CRL tells you by a piece of signed data, that out of all the 
> CRL that are
> published by the CA and current what exactly was the intent 
> of the CA when
> it created this CRL.  Trusting where you find the CRL to give you this
> information is not good practice. Distribution mechanisms such as
> directories and url's cannot be trusted.
> 
> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Wednesday, February 10, 1999 12:11 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> 
> Hi Pau,
>     If your CA is "really" using CRLDP, then you need to be
> careful when you say you have "the" CRL. Part of the point of
> CRLDP (as opposed to simple CRLs), is, that a CA can now issue
> multiple little CRLs, depending on how it decides to partition
> revocation data.
> 
> For example, it may create one CRLDP for certificates with serial
> numbers between 1-100. Another one for certs from 101-200 and so
> on.
> 
> Also, it may decide to issue multple potential CRLs on which
> a particular cert may occur - for example, there may be one CRL
> for key compromise (which is updated very, very frequently), another
> for lost keys, etc.
> 
> So, there isn't necessarily a single CRL you need to look at.
> 
> If your CA decides to use CRLDP in its simplest form and just
> issue a single CRL that contains all revocation data, you
> still need to be careful. A CRL contains 2 times - a thisUpdate
> and a nextUpdate, where the thisUpdate is the time at which
> the CRL was issued, while the nextUpdate is the time
> at or *before* which the next CRL will be issued.
> 
> This means that there is *no* guarantee that the CRL you have
> from the CA is the latest one it issued. So depending on the
> sensitivity of the transaction, you may decide to go check
> the CA for a newer CRL, use the cached CRL, or wait till
> nextUpdate is in the past, go grab a new CRL from the CA at
> that time and verify that the cert is not on that CRL.
> 
> Hope this helps,
> Regards,
> Ambarish
> 
> P.S. To figure out which CRLs apply to the certificate you are
> trying to check, you normally look for the path to the CRLs in
> the certificate. Once you retrieve the CRL, you need to check
> that the CRL has the same name as the one you thought you
> were retrieving. So the extension you look for in the cert
> is the one with OID id-ce-cRLDistributionPoints, while the name
> of the CRL can be found in the CRL (if present), with the
> OID id-ce-issuingDistributionPoint.
> 
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect					         650.567.5457
> ValiCert, Inc.				        
> [email-masked]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf
> > Of [email-masked]
> > Sent: Monday, February 08, 1999 8:55 AM
> > To: [email-masked]
> > Subject: Usage of CRL Issuing Distribution Point
> > 
> > 
> > Hellow, I am a new comer to PKIX.
> > I have a question about the usage of the
> > CRL distribution point:
> > 
> > If I have the CRL, then do I still need to know
> > the distribution point ? Is this entension intended
> > for furture retrival of CRL's (and of course, to indicate
> > why the cert's in the list are revoked.) ?
> > 
> > If I don't know the distribution point, is there a
> > standard/suggested way to learn it without getting the
> > CRL ?
> > 
> > Thanks in advance.
> > 
> > 
> > Regards, Pau-Chen
> > 
> 

From: Alex Deacon <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Fri, 12 Feb 1999 12:40:23 -0800
Sender: [email-masked]

Trevor, 

Could you specify what document states that it is not permitted for CRL's to
be partitioned on the basis of other attributes such as serial number?  I
cant recall ever seeing such a statement in either PKIX Part 1 or X.509.

Thanks
Alex

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, February 12, 1999 11:07 AM
> To: 'Ambarish Malpani'; [email-masked]
> Cc: [email-masked]
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> 
> When a CA publishes a CRL, the CA should put sufficient 
> information into the
> CRL to unambiguous identify its intent. If you CA is only 
> generating one CDP
> per signing key, then issuer and key identity is sufficient. The key
> identity in AKI is just a hint to enable you to pick the 
> right CRL first for
> you signature check. It also helps if you want to cache CRL 
> locally. Issuing
> CDP is required once a CA starts to partition the CRL based 
> e.g. on reason
> code or subject type. The current RFC does not permit CRL to 
> be partitioned
> on the basis other attributes such as serial number. The 
> Issuing CDP of a
> CRL tells you by a piece of signed data, that out of all the 
> CRL that are
> published by the CA and current what exactly was the intent 
> of the CA when
> it created this CRL.  Trusting where you find the CRL to give you this
> information is not good practice. Distribution mechanisms such as
> directories and url's cannot be trusted.
> 
> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Wednesday, February 10, 1999 12:11 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Usage of CRL Issuing Distribution Point
> 
> 
> 
> Hi Pau,
>     If your CA is "really" using CRLDP, then you need to be
> careful when you say you have "the" CRL. Part of the point of
> CRLDP (as opposed to simple CRLs), is, that a CA can now issue
> multiple little CRLs, depending on how it decides to partition
> revocation data.
> 
> For example, it may create one CRLDP for certificates with serial
> numbers between 1-100. Another one for certs from 101-200 and so
> on.
> 
> Also, it may decide to issue multple potential CRLs on which
> a particular cert may occur - for example, there may be one CRL
> for key compromise (which is updated very, very frequently), another
> for lost keys, etc.
> 
> So, there isn't necessarily a single CRL you need to look at.
> 
> If your CA decides to use CRLDP in its simplest form and just
> issue a single CRL that contains all revocation data, you
> still need to be careful. A CRL contains 2 times - a thisUpdate
> and a nextUpdate, where the thisUpdate is the time at which
> the CRL was issued, while the nextUpdate is the time
> at or *before* which the next CRL will be issued.
> 
> This means that there is *no* guarantee that the CRL you have
> from the CA is the latest one it issued. So depending on the
> sensitivity of the transaction, you may decide to go check
> the CA for a newer CRL, use the cached CRL, or wait till
> nextUpdate is in the past, go grab a new CRL from the CA at
> that time and verify that the cert is not on that CRL.
> 
> Hope this helps,
> Regards,
> Ambarish
> 
> P.S. To figure out which CRLs apply to the certificate you are
> trying to check, you normally look for the path to the CRLs in
> the certificate. Once you retrieve the CRL, you need to check
> that the CRL has the same name as the one you thought you
> were retrieving. So the extension you look for in the cert
> is the one with OID id-ce-cRLDistributionPoints, while the name
> of the CRL can be found in the CRL (if present), with the
> OID id-ce-issuingDistributionPoint.
> 
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect					         650.567.5457
> ValiCert, Inc.				        
> [email-masked]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf
> > Of [email-masked]
> > Sent: Monday, February 08, 1999 8:55 AM
> > To: [email-masked]
> > Subject: Usage of CRL Issuing Distribution Point
> > 
> > 
> > Hellow, I am a new comer to PKIX.
> > I have a question about the usage of the
> > CRL distribution point:
> > 
> > If I have the CRL, then do I still need to know
> > the distribution point ? Is this entension intended
> > for furture retrival of CRL's (and of course, to indicate
> > why the cert's in the list are revoked.) ?
> > 
> > If I don't know the distribution point, is there a
> > standard/suggested way to learn it without getting the
> > CRL ?
> > 
> > Thanks in advance.
> > 
> > 
> > Regards, Pau-Chen
> > 
> 

Date: Fri, 12 Feb 1999 11:51:37 -0800
To: [email-masked]
From: [email-masked] (Dmitry Dolinsky)
Subject: [Q] AuthorityKeyIdentifier Question
Sender: [email-masked]

Hi all,

I have a question about matching authorityCertIssuer in
AuthorityKeyIdentifier extension with authority certificate.

I understand authorityCertIssuer has to match issuer (and/or?)
issuerAltName of the issuer certificate. Since authorityCertIssuer is
GeneralNames and issuer is a Name (distinguished name), in what manner one
should be matched against the other?

Alternatively, if authorityCertIssuer is supposed to be matched only with
issuerAltName, which is GeneralNames, doesn't it mean that presence of
authorityCertIssuer in the subject's certificate requires the presence of
issuerAltName in the issuer's certificate and the presence of
subjectAltName in the issuer issuer's certificate.

The clarification will be really appreciated.

--Dmitry

From: Trevor Freeman <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Fri, 12 Feb 1999 11:07:05 -0800
Sender: [email-masked]

When a CA publishes a CRL, the CA should put sufficient information into the
CRL to unambiguous identify its intent. If you CA is only generating one CDP
per signing key, then issuer and key identity is sufficient. The key
identity in AKI is just a hint to enable you to pick the right CRL first for
you signature check. It also helps if you want to cache CRL locally. Issuing
CDP is required once a CA starts to partition the CRL based e.g. on reason
code or subject type. The current RFC does not permit CRL to be partitioned
on the basis other attributes such as serial number. The Issuing CDP of a
CRL tells you by a piece of signed data, that out of all the CRL that are
published by the CA and current what exactly was the intent of the CA when
it created this CRL.  Trusting where you find the CRL to give you this
information is not good practice. Distribution mechanisms such as
directories and url's cannot be trusted.

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Wednesday, February 10, 1999 12:11 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Usage of CRL Issuing Distribution Point

Hi Pau,
    If your CA is "really" using CRLDP, then you need to be
careful when you say you have "the" CRL. Part of the point of
CRLDP (as opposed to simple CRLs), is, that a CA can now issue
multiple little CRLs, depending on how it decides to partition
revocation data.

For example, it may create one CRLDP for certificates with serial
numbers between 1-100. Another one for certs from 101-200 and so
on.

Also, it may decide to issue multple potential CRLs on which
a particular cert may occur - for example, there may be one CRL
for key compromise (which is updated very, very frequently), another
for lost keys, etc.

So, there isn't necessarily a single CRL you need to look at.

If your CA decides to use CRLDP in its simplest form and just
issue a single CRL that contains all revocation data, you
still need to be careful. A CRL contains 2 times - a thisUpdate
and a nextUpdate, where the thisUpdate is the time at which
the CRL was issued, while the nextUpdate is the time
at or *before* which the next CRL will be issued.

This means that there is *no* guarantee that the CRL you have
from the CA is the latest one it issued. So depending on the
sensitivity of the transaction, you may decide to go check
the CA for a newer CRL, use the cached CRL, or wait till
nextUpdate is in the past, go grab a new CRL from the CA at
that time and verify that the cert is not on that CRL.

Hope this helps,
Regards,
Ambarish

P.S. To figure out which CRLs apply to the certificate you are
trying to check, you normally look for the path to the CRLs in
the certificate. Once you retrieve the CRL, you need to check
that the CRL has the same name as the one you thought you
were retrieving. So the extension you look for in the cert
is the one with OID id-ce-cRLDistributionPoints, while the name
of the CRL can be found in the CRL (if present), with the
OID id-ce-issuingDistributionPoint.

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of [email-masked]
> Sent: Monday, February 08, 1999 8:55 AM
> To: [email-masked]
> Subject: Usage of CRL Issuing Distribution Point
> 
> 
> Hellow, I am a new comer to PKIX.
> I have a question about the usage of the
> CRL distribution point:
> 
> If I have the CRL, then do I still need to know
> the distribution point ? Is this entension intended
> for furture retrival of CRL's (and of course, to indicate
> why the cert's in the list are revoked.) ?
> 
> If I don't know the distribution point, is there a
> standard/suggested way to learn it without getting the
> CRL ?
> 
> Thanks in advance.
> 
> 
> Regards, Pau-Chen
> 

Date: Fri, 12 Feb 1999 13:17:13 -0500
From: Eric Bomarsi <[email-masked]>
Organization: xedia.com
To: "Flanigan, Bill" <[email-masked]>
Cc: "'Al Arsenault'" <[email-masked]>, [email-masked]
Subject: Re: Yes, and remove more of the alphabet from the PKIX soup
Sender: [email-masked]

Al and Bill:

Thanks, the chronology helps put things in perspective.

It sounds as though some view CMC as the next phase
certificate management protocol which will address
deficiencies in CMP and CRS.

I hope that means future CMP work is limited to incremental
fixes and improvements rather than competing with CMC
enhancements. Is this the case?

Still, if anyone experienced with both can summarize the
deficiencies that CMC is trying to address, it would be
appreciated.

Thanks in advance:
Eric Bomarsi

"Flanigan, Bill" wrote:

> Hello Al/Eric,
>
>     IMHO, CMC (needs a much-broader, descriptive name?) appears to be the
> "logical successor" to CMP as well as the rest of the PKIX alphabet soup of
> somewhat contradictory I-Ds/RFCs.  CMP now seems too narrowly focused and
> not fully formed.  This is to be expected, since CMP drew on the experience
> of only a small number of smart folks who had hands-on, post-pilot,
> PKI-implementation experience (they were probably the only ones on the
> planet at the time!).  CMC (or an updated, unified spec) offers the
> opportunity for many more folks who now have had hands-on experience with
> major PKI implementations (especially with the registration process and
> directories) to contribute to a more mature, deconflicted, and homogeneous
> protocol that can be implemented by many "flavors" of PKI using out-of-the
> box components without glueware.
>
> Bill
>
> -----Original Message-----
> From: Al Arsenault [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> Sent: Thursday, February 11, 1999 1:21 PM
> To: Eric Bomarsi; [email-masked] <mailto:[email-masked]>
> Subject: RE: Yes, and remove more of the alphabet from the PKIX soup
>
> Eric,
>
> At 12:23 PM 2/11/99 -0500, Eric Bomarsi wrote:
> >I am trying to understand the relationship between the various
> >certificate enrollment protocols and came across this archived
> >email thread. <snipped>
> >
> >Since then, CMP is going to RFC, CMMF seems to be
> >going away, and CMC work continues. Correct?
> >
>
> Correct.
>
> >So can someone with experience in each of these please
> >summarize the merits of each?
> >
> >Is CMC a follow-on to CMP and intended to improve some
> >deficiencies, or are they competing protocols.
>
>  [snip]
>
>         Yes, the two protocols (CMP and CMC) are "competing" with one
> another.  CMP was created first (it evolved out of the original PKIX-3
> document); then CMC (which was originally CRS) was proposed as an
> alternative by a group of people who didn't want to deal with the creation
> of a new protocol.  Vendors generally choose one or the other to implement;
> certain vendors (I'll let them speak for themselves) have said publically
> that they're going to support CMC and never implement CMP; other vendors
> have made similar commitments to CMP and seem to shun CMC.  I'm not aware of
> anybody who has made a public commitment to support both, but there might be
> somebody.
>
>   [snip]                                                         Al
> Arsenault
>
>  [snip] .

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "Andrew Probert" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Fri, 12 Feb 1999 11:36:25 -0500
Importance: Normal
Sender: [email-masked]

> Andrew Probert <[email-masked]> writes:
> > Yeah .. apologies, my typing was in haste, I know HTTP is over IP.
> Uh, not to be difficult, but not over IP either. Over TCP.

No, HTTP is layered on a transport layer which provides an 8 bit clean,
reliable connection. In the early days we used DECNET to a significant
degree (the DEC IP stack cost extra at the time!).

As a matter of fact, in those days I thought the OSI based Decnet
phase V was going to replace IP - mainly because of the address
space exhaustion issue. That was before firewalls, NAT and DCHP.

> > I meant to allude to simplicity of the transport i.e. you can
> Telnet to a
> > Web server and hand-type HTTP protocol, so the underlying comms is very
> > simple, but you are pushing a lot of stuff up into the HTTP application.

Actually, the idea we had was to remove the unnecessary work from
the application. FTP's twin connection is far more complex for any
application to manage than the HTTP 'idempotent request' model.
Similarly the LDAP BIND operation achieves nothing of real value.

The 'complexity' of HTTP/1.1 is due to the caching model. No other
retrieval protocol I am aware of has any caching model - the applications
were too busy performing unnecessary operations such as BIND and UNBIND.
Caching is not a particular burden on applications however.

Even with every 1.1 boondoggle, HTTP is by far the most straightforward
protocol to implement at the application level.

In retrospect I think that the confusion that HTTP ended concerned
the interface between the authentication/authorization model (an
application concern) and the transport connection. For some reason it
was assumed to be a good idea to keep TCP/IP sessions going
indefinitely - instead of simply caching the access control context
at each end.

Unfortunately some folk took this a bit far, maybe Eric can remember
the name of that chap from Chicago who he used to work with who had
the idea of downloding every image in a page as a separate TCP/IP
connection. That was definitely a bad idea!

		Phill

From: "Flanigan, Bill" <[email-masked]>
To: "'Al Arsenault'" <[email-masked]>, Eric Bomarsi <[email-masked]>
Cc: [email-masked]
Subject: RE: Yes, and remove more of the alphabet from the PKIX soup
Date: Fri, 12 Feb 1999 09:11:48 -0500
Importance: low
Sender: [email-masked]

Hello Al/Eric,
 
    IMHO, CMC (needs a much-broader, descriptive name?) appears to be the
"logical successor" to CMP as well as the rest of the PKIX alphabet soup of
somewhat contradictory I-Ds/RFCs.  CMP now seems too narrowly focused and
not fully formed.  This is to be expected, since CMP drew on the experience
of only a small number of smart folks who had hands-on, post-pilot,
PKI-implementation experience (they were probably the only ones on the
planet at the time!).  CMC (or an updated, unified spec) offers the
opportunity for many more folks who now have had hands-on experience with
major PKI implementations (especially with the registration process and
directories) to contribute to a more mature, deconflicted, and homogeneous
protocol that can be implemented by many "flavors" of PKI using out-of-the
box components without glueware. 
 
Bill

-----Original Message-----
From: Al Arsenault [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Thursday, February 11, 1999 1:21 PM
To: Eric Bomarsi; [email-masked] <mailto:[email-masked]> 
Subject: RE: Yes, and remove more of the alphabet from the PKIX soup

Eric,

At 12:23 PM 2/11/99 -0500, Eric Bomarsi wrote:
>I am trying to understand the relationship between the various
>certificate enrollment protocols and came across this archived
>email thread. <snipped>
>
>Since then, CMP is going to RFC, CMMF seems to be
>going away, and CMC work continues. Correct?
>

Correct.

>So can someone with experience in each of these please
>summarize the merits of each?
>
>Is CMC a follow-on to CMP and intended to improve some
>deficiencies, or are they competing protocols.

 [snip] 

        Yes, the two protocols (CMP and CMC) are "competing" with one
another.  CMP was created first (it evolved out of the original PKIX-3
document); then CMC (which was originally CRS) was proposed as an
alternative by a group of people who didn't want to deal with the creation
of a new protocol.  Vendors generally choose one or the other to implement;
certain vendors (I'll let them speak for themselves) have said publically
that they're going to support CMC and never implement CMP; other vendors
have made similar commitments to CMP and seem to shun CMC.  I'm not aware of
anybody who has made a public commitment to support both, but there might be
somebody.

  [snip]                                                         Al
Arsenault

 [snip] .

To: Andrew Probert <[email-masked]>
Cc: "'Phillip M Hallam-Baker'" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Finding PKIX Servers!
From: EKR <[email-masked]>
Date: 11 Feb 1999 20:53:28 -0800
Lines: 19
Sender: [email-masked]

Andrew Probert <[email-masked]> writes:
> Yeah .. apologies, my typing was in haste, I know HTTP is over IP.
Uh, not to be difficult, but not over IP either. Over TCP.

> I meant to allude to simplicity of the transport i.e. you can Telnet to a
> Web server and hand-type HTTP protocol, so the underlying comms is very
> simple, but you are pushing a lot of stuff up into the HTTP application.
It's not the simplicity of the transport that's the issue. There
are plenty of protocols that run directly over TCP that can't be
hand-typed (SSL comes to mind.) The simplicity comes in because
it's ASCII text. 

IMHO, as a protocol implementor, this is a major advantage, both
from the perspective of debugging and of implementing.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

From: Andrew Probert <[email-masked]>
To: "'EKR'" <[email-masked]>, Andrew Probert <[email-masked]>
Cc: "'Phillip M Hallam-Baker'" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Fri, 12 Feb 1999 12:55:57 +1100
Sender: [email-masked]

Yeah .. apologies, my typing was in haste, I know HTTP is over IP.

I meant to allude to simplicity of the transport i.e. you can Telnet to a
Web server and hand-type HTTP protocol, so the underlying comms is very
simple, but you are pushing a lot of stuff up into the HTTP application.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	EKR [SMTP:[email-masked]]
> Sent:	Friday, February 12, 1999 11:15 AM
> To:	Andrew Probert
> Cc:	'Phillip M Hallam-Baker'; David P. Kemp; [email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
> Andrew Probert <[email-masked]> writes:
> > > I don't see a need therefore to use LDAP or X.500 as the transfer
> > > protocol for OCSP. Not only is HTTP considerably more efficient,
> > > the much vaunted data model and replication protocols are a poor
> > > match for the particular needs of an online status protocol.
> > > 
> > 	[Andrew Probert]  Well .. HTTP is an overlay of simple verbs GET,
> > POST over Telnet, with some service controls and it is certainly a
> simple
> > protocol. 
> I don't know where you get the idea that HTTP is an overlay over
> TELNET. It most certainly is not. HTTP runs over a TCP connection,
> as does TELNET, yes, but that doesn't make HTTP an overlay over TELNET
> wny more than FTP is. RFC-854 specifies all sorts of stuff that HTTP
> doesn't have any notion of, including some terminal behavior, control
> information, etc.
> 
> -Ekr
> 
> -- 
> [Eric Rescorla                                   [email-masked]]

To: Andrew Probert <[email-masked]>
Cc: "'Phillip M Hallam-Baker'" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Finding PKIX Servers!
From: EKR <[email-masked]>
Date: 11 Feb 1999 16:14:51 -0800
Lines: 21
Sender: [email-masked]

Andrew Probert <[email-masked]> writes:
> > I don't see a need therefore to use LDAP or X.500 as the transfer
> > protocol for OCSP. Not only is HTTP considerably more efficient,
> > the much vaunted data model and replication protocols are a poor
> > match for the particular needs of an online status protocol.
> > 
> 	[Andrew Probert]  Well .. HTTP is an overlay of simple verbs GET,
> POST over Telnet, with some service controls and it is certainly a simple
> protocol. 
I don't know where you get the idea that HTTP is an overlay over
TELNET. It most certainly is not. HTTP runs over a TCP connection,
as does TELNET, yes, but that doesn't make HTTP an overlay over TELNET
wny more than FTP is. RFC-854 specifies all sorts of stuff that HTTP
doesn't have any notion of, including some terminal behavior, control
information, etc.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Fri, 12 Feb 1999 09:18:57 +1100
Sender: [email-masked]

Comments in line

> -----Original Message-----
> From:	Perry E. Metzger 
> Sent:	Tuesday, February 09, 1999 10:21 AM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
> Michael Sierchio <[email-masked]> writes:
> > Other than arguing against the need for such a global directory
> > infrastructure,  do you have philosophical or aesthetic problems
> > with it?
> 
> Since such an infrastructure would be very expensive and hard to
> manage, I'd say that the lack of need or use probably argues on its
> own against its implementation.
	I bet the same was said about canals and waterways, freeways,
the telephone system and air travel.
	 regards alan

> Perry

From: Andrew Probert <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, Andrew Probert <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Fri, 12 Feb 1999 09:16:13 +1100
Sender: [email-masked]

Comments inline ..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Friday, February 12, 1999 3:11 AM
> To:	Andrew Probert; David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> > 	[Andrew Probert]  If your DNS is down and you dont have backup
> > servers, then the Internet is down.
> 
> Which is why folk have backup servers and as a result the Internet is
> always up. 
> 
> > 	This is technology neutral, the issue is the same whether its a
> > directory server or any other form of server.
> 
> No, it is not. DNS supports a very minimal name translation service. As a 
> result replication is easy and does not introduce major interdependencies
> between servers.
> 
	[Andrew Probert]  PKI has complex data objects and requires more
complex interaction between servers, availability issues are similar,
service features are more complex!

> > 	As I understand Alan's Draft he is proposing extending the X.500
> > specification, 
> 
> PRECISELY.
> 
> Alan is not talking about X.500. He is talking about Alan.500, an unproven
> protocol with ZERO operational experience.
> 
	[Andrew Probert]  .. based upon extension of an existing protocol
and products with lots of experience.  The same comment can be said of OCSP,
ICAP etc. etc.  

> > > second if it did it might get tiresome doing a search of
> > > the entire directory space for an entry with the right attribute, 
> > > 
> > 	[Andrew Probert]  Why tiresome, I would assume software does this
> > transparently for you and easily, if the namespace is rational and
> > connectivity is there.  
> 
> But the namespace is not rational. The name space is IANA, partitioned
> over X.500 DN's.
> 
	[Andrew Probert]  No, Namespace of certficates is incoded as an
X.500 DN.  The namespace of the transport system is IANA.  You are mixing
two things that shouldn't be mixed.  See my previous postings about issues
of DN->URL assumptions.

> > > third
> > > X.500 is only standardized over the OSI network stack and not over IP,
> > > LDAP does not include the replication protocols being promoted as the
> > > basis
> > > for the 'global scalability' claim.
> > > 
> > 	[Andrew Probert]  LDAP is alive and kicking.  Microsoft have
> > included it..  Netscape and many others are promoting it.
> 
> And neither have yet agreed on a common replication protocol - except
> that neither wants to use the X.500 replication protocols.
> 
	[Andrew Probert]  See a previous posting.  DISP is replication.  DSP
is online query routing, multicasting to servers etc, which is particularly
useful to the topic in question.

> Standardization of server-server protocols in the same domain of authority
> is rarely urgent. I doubt that many enterprises will be installing 
> heterogeneous directory systems. Certainly interoperability between
> 'X.500' products from different vendors is less than seamless.
> 
	[Andrew Probert]  I agree its not urgent, unless you want global
interoperability.

> I don't see a need therefore to use LDAP or X.500 as the transfer
> protocol for OCSP. Not only is HTTP considerably more efficient,
> the much vaunted data model and replication protocols are a poor
> match for the particular needs of an online status protocol.
> 
	[Andrew Probert]  Well .. HTTP is an overlay of simple verbs GET,
POST over Telnet, with some service controls and it is certainly a simple
protocol.  OCSP is a service overlaid.

	Alans suggestion is to overlay a CRL lookup service over X.500
DAP/LDAP protocol, which would automatically inherit the existing technical
infrastructure to route these queries.  This can be gained by incremental
development over existing working protocols.  I see your logic above is to
defer the design issue.  His is to address it now!

	As to efficiency, Urban Myth again, when you compare apples to
apples, you find that computers can decode structures and pointers faster
than they can decode / parse text and delimiters.  Take a look at
application / decoder efficiency when you cite transport protocol
efficiency.

> 	Phill
> 

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: Andrew Probert <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Fri, 12 Feb 1999 09:15:24 +1100
Sender: [email-masked]

Sorry about being me again - but I just love these lines from people
that dictate what the whole world does.

> -----Original Message-----
> From:	Perry E. Metzger 
> Sent:	Tuesday, February 09, 1999 3:28 AM
> To:	[email-masked]
> Cc:	Andrew Probert; [email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
> Michael Sierchio <[email-masked]> writes:
> > "Perry E. Metzger" wrote:
> > 
> > > To put it another way: when you walk in to the book store to buy a
> > > book, the store doesn't care a bit about who you are. They care
> about
> > > whether they will be PAID, and knowing you have a valid cert tells
> > > them nothing about that. What they need is a signed statement from
> their
> > > accepting bank saying they will be paid -- and that doesn't
> require a
> > > Global PKI to set up. It might use a PKI set up by the bank or
> credit
> > > network for its own use, but it doesn't need a *GLOBAL* PKI.
> > 
> > There are two separate issues here -- if we're talking about
> > presenting a cert as part of authorizing a transaction,  the
> > merchant may very well be interested in identity -- certainly
> > in non-repudiation.
> 
> Again, no, this is not the case.
> 
	I would never, repeat never say in one paragraph what the whole
world does when vetting a transaction with a customer across a counter
and who does the authentication and transaction verification. One can
only cite that in some cases (a) happens and in some cases (b) happens.
Sometimes I get asked for a passport or driving licence to prove who I
am when doing bank transactions and sometimes not.

	By making such a statement (as below) one can only assume you
have met every merchant in the whole world :-)

	SNIP

	regards alan

Date: Thu, 11 Feb 1999 13:20:59 -0500
To: Eric Bomarsi <[email-masked]>, [email-masked]
From: Al Arsenault <[email-masked]>
Subject: RE: Yes, and remove more of the alphabet from the PKIX soup
Sender: [email-masked]

--=====================_261449250==_.ALT
Content-Type: text/plain; charset="us-ascii"

Eric,

At 12:23 PM 2/11/99 -0500, Eric Bomarsi wrote:
>I am trying to understand the relationship between the various
>certificate enrollment protocols and came across this archived
>email thread. <snipped>
>
>Since then, CMP is going to RFC, CMMF seems to be
>going away, and CMC work continues. Correct?
>

Correct.

>So can someone with experience in each of these please
>summarize the merits of each?
>
>Is CMC a follow-on to CMP and intended to improve some
>deficiencies, or are they competing protocols.

This is what the "PKIX Roadmap" says at this point: (text provided so that if
somebody thinks this is wrong, tell Sean & me before we release the next draft
:-)

DOCUMENT TITLE: Certificate Management Messages over CMS 
<draft-ietf-pkix-cmc-02.txt>

DESCRIPTION: This document defines the means by which PKI clients and
servers may exchange PKI messages when using S/MIME's Cryptographic
Message Syntax [CMS]as a transaction envelope.  CMC supports the certificate
request message body specified in the Certificate Request Message Format [CRMF]
documents, as well as a variety of other certificate management messages.  The
primary purpose of this specification is to allow the use of an existing
protocol (S/MIME)as a PKI management protocol, without requiring the
development of an entirely new protocol such as CMP. A secondary purpose is to
codify in IETF standards the current industry practice of using PKCS 10
messages [PKCS10] for certificate requests.  

        Yes, the two protocols (CMP and CMC) are "competing" with one another. 
CMP was created first (it evolved out of the original PKIX-3 document); then
CMC (which was originally CRS) was proposed as an alternative by a group of
people who didn't want to deal with the creation of a new protocol.  Vendors
generally choose one or the other to implement; certain vendors (I'll let them
speak for themselves) have said publically that they're going to support CMC
and never implement CMP; other vendors have made similar commitments to CMP and
seem to shun CMC.  I'm not aware of anybody who has made a public commitment to
support both, but there might be somebody.

        The decision made at the Washington IETF about 15 months ago was to go
ahead with the two different protocols at this point, and let the market decide
which one (or maybe both) would eventually win.

                                                        Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.

--=====================_261449250==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Eric,<br>
<br>
At 12:23 PM 2/11/99 -0500, Eric Bomarsi wrote:<br>
&gt;I am trying to understand the relationship between the various<br>
&gt;certificate enrollment protocols and came across this archived<br>
&gt;email thread. &lt;snipped&gt;<br>
&gt;<br>
&gt;Since then, CMP is going to RFC, CMMF seems to be<br>
&gt;going away, and CMC work continues. Correct?<br>
&gt;<br>
<br>
Correct.<br>
<br>
<br>
&gt;So can someone with experience in each of these please<br>
&gt;summarize the merits of each?<br>
&gt;<br>
&gt;Is CMC a follow-on to CMP and intended to improve some<br>
&gt;deficiencies, or are they competing protocols.<br>
<br>
<br>
This is what the &quot;PKIX Roadmap&quot; says at this point: (text
provided so that if somebody thinks this is wrong, tell Sean &amp; me
before we release the next draft :-)<br>
<br>
<font face="Courier New, Courier">DOCUMENT TITLE: Certificate Management
Messages over CMS <br>
&lt;draft-ietf-pkix-cmc-02.txt&gt;<br>
<br>
DESCRIPTION: This document defines the means by which PKI clients
and<br>
servers may exchange PKI messages when using S/MIME's Cryptographic<br>
Message Syntax [CMS]as a transaction envelope.&nbsp; CMC supports the
certificate request message body specified in the Certificate Request
Message Format [CRMF] documents, as well as a variety of other
certificate management messages.&nbsp; The primary purpose of this
specification is to allow the use of an existing protocol (S/MIME)as a
PKI management protocol, without requiring the development of an entirely
new protocol such as CMP. A secondary purpose is to codify in IETF
standards the current industry practice of using PKCS 10 messages
[PKCS10] for certificate requests.&nbsp; <br>
<br>
</font><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes,
the two protocols (CMP and CMC) are &quot;competing&quot; with one
another.&nbsp; CMP was created first (it evolved out of the original
PKIX-3 document); then CMC (which was originally CRS) was proposed as an
alternative by a group of people who didn't want to deal with the
creation of a new protocol.&nbsp; Vendors generally choose one or the
other to implement; certain vendors (I'll let them speak for themselves)
have said publically that they're going to support CMC and never
implement CMP; other vendors have made similar commitments to CMP and
seem to shun CMC.&nbsp; I'm not aware of anybody who has made a public
commitment to support both, but there might be somebody.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
decision made at the Washington IETF about 15 months ago was to go ahead
with the two different protocols at this point, and let the market decide
which one (or maybe both) would eventually win.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Al
Arsenault<br>
<br>
-- these are my opinions only. They do not necessarily reflect the <br>
opinions of my employer, or of any other organization with which I have a
<br>
relationship.<br>
<br>
<br>
<br>
</html>

--=====================_261449250==_.ALT--

Date: Thu, 11 Feb 1999 18:32:21 +0100
From: Juergen Walter <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], [email-masked], [email-masked], ietf-pkix <[email-masked]>
Subject: Comments to Qualified Certificates draft
Sender: [email-masked]

I would like to add some comments to the QC draft. The topics are the
following

1) Properties of Qualified certificates,
2) CPS and the semantics of name fields,
3) countryName usage,
4) commonName
5) Security Considerations.

Comments 1),2),4) are more or less editorial, while comments 3), 5) are
more general.

1) Properties of Qualified Certificates

"2.1  Properties

   A Qualified Certificate as defined in this standard is assumed to
   have the following properties:

   - Issued by a CA that makes a public statement that the certificate
   serves the purpose of a Qualified Certificate, as discussed in sec-
   tion 2.3
   - Indicate a certificate policy consistent with liabilities, prac-
   tices and procedures undertaken by the CA, as discussed in 2.4
   - Be issued to a natural person (living human being).
   - Contain an unmistakable identity based on a pseudonym name or a
   real name of the subject.
   - Exclusively indicates non-repudiation key usage for the certified
   public key.
   - Fully complies with the certificate profile defined in RFC 2459"
[PKIX-QC]

The last three properties should be replaced by 
   - Fully complies with the certificate profile defined in RFC 2459 and
chapter 3 of    this document.

The profile of Qualified Certificates is defined in chapter 3 of
[PKIX-QC]. The fourth and fifth property do not cover the profile given
in chapter 3 completely.

The security requirements defined in chapter 4 should be linked
explicitly. Therefore the following property should be added:

   - Issued by a CA in compliance with reasonable securitity measures
following the security considerations in chapter 4.

2) CPS and the semantics of name fields
(subsection 3.1.1, last paragraph)

"It should be noted, however, that a relying party MAY have to consult
identified certificate policies and/or the issuer's CPS, in order to
determine semantics of name fields and legal jurisdiction." [PKIX-QC]

This paragraph should be moved to the introduction of chapter 3. Not
only the Issuer field (subsection 3.1.1) contains name fields but also
some of the remaining sections of chapter 3 contain name fields (e. g.
3.2.1. Subject Alternative Name). Then in addition, "name field" may be
replaced by "a particullary field" because this note applies to other
fields like placeOfBirth as well. So, "The manner in which the date of
birth is associated with the subject is outside the scope of this
document." may be avoidable. Such phrases can be found in various
sections.

3) countryName usage

The field countryName is defined in subsection 3.1.2 and 3.2.1
respectively. At a first glance, it is a field associated to the
subject. But [PKIX-QC] says about usage in both subsections:

"The countryName attribute value specifies a general context in which
other attributes are to be understood. The country attribute does not
necessarily match the subject's country of citizenship or country of
residence, nor does it have to match the country of issuance." (*)

I am confused. [PKIX-QC] says "The givenName and surname attribute types
SHALL, if present, contain the registered name of the subject, depending
on the laws under which the CA prepares the certificate." Either this
contradicts the countryName usage specification (*) or the draft allows
that the general context (whatever this means) of other subject´s
attributes differ from which of the givenName and surname attribute. By
the way, there is a difference in meaning between "prepare" and "issue",
isn´t it?

The countryName usage (*) should be replaced by the following:

- The countryName attribute value contained in the ISSUER field
specifies a general context in which other attributes are to be
understood. It should be noted that, the optional attributeSemantics
value may specify variations for attributes contained in the
PersonalData field.

- The countryName attribute value contained in the SUBJECT field SHALL
match one of subject´s countryOfCitizenship or countryOfResidence. The
value may be chosen by subject´s or CA´s preference.

- The countryName attribute contained in the PersonalData field SHALL if
present coincide with the value in the SUBJECT field.

Have I overseen some discussion about the countryName usage? Why should
a countryName different from subject´s countryOfCitizenship or
countryOfResidence have any relevance in Qualified Certificates?

3) commonName

In the 7th paragraph of subsection 3.1.2 [PKIX-QC]

"To understand the nature of the name presented in commonName, complying
applications may have to examine present values of the givenName and
surname attributes and if necessary, the personal data field in the
subjectAltName extension."

should be replaced by

"To understand the nature of the name presented in commonName, complying
applications may have to examine present values of the givenName and
surname attributes contained in the personal data field of the
subjectAltName extension if necessary."

The phrase applies to "Choice I" of subject field definition. Then the
fields givenName and surname are absent in the subject field even if
they may present in the PersonalData record of the subjectAltName field.
The conjunction "and if ..." is therefore misleading in the original
phrase.

4) Security Considerations

[PKIX-QC, chapter 4] "Both the private key
   holder as well as the relying party should make sure that the private
   key is used only with the consent of the legitimate key holder and
   only after the key holders conscious acceptance of the signed message
   content."

How could the relying party do this? This topic should be reformulated
in the following sense. On the one hand there are security requirements
according to the personal security environment; on the other hand there
are security requirements for certificate path validation.

I hope it helps.

Juergen

Date: Thu, 11 Feb 1999 12:23:31 -0500
From: Eric Bomarsi <[email-masked]>
Organization: xedia.com
To: [email-masked]
Subject: RE: Yes, and remove more of the alphabet from the PKIX soup
Sender: [email-masked]

I am trying to understand the relationship between the various
certificate enrollment protocols and came across this archived
email thread.

Since then, CMP is going to RFC, CMMC seems to be
going away, and CMC work continues. Correct?

So can someone with experience in each of these please
summarize the merits of each?

Is CMC a follow-on to CMP and intended to improve some
deficiencies, or are they competing protocols.

Thanks in advance,
Eric Bomarsi

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

      To: [email-masked]
      Subject: RE: Yes, and remove more of the alphabet from the PKIX soup (Was: RE: Can we now kill
CMMF?)
      From: Warwick Ford <[email-masked]>
      Date: Fri, 18 Dec 1998 12:49:16 -0800
      Sender: [email-masked]

I think we all want to see the document structure rationalized, but I would
not want that objective to destabilize completion of the protocol specs.  I
see it as follows:  CMP and CRMF are (virtually) Proposed Standards now, and
we do not want to disturb them.  In their next iteration, we could certainly
consider folding CRMF into the CMP spec.  CMC has done the right thing in
eliminating its dependence on CMMC, so we are probably now able to drop CMMC
as Al proposed.  It is OK for CMC to reference CRMF for now; but the CMC
authors might consider folding in CRMF as well at some stage -- maybe a
future iteration, to be sure such a move does not disrupt publication of the
first CMC Proposed Draft.  However, it would not be helpful to try to merge
CMP and CMC at this stage -- this is something we can look at later on, in
the light of experience in implementing these protocols.

Warwick

> -----Original Message-----
> From: Aram Perez [mailto:[email-masked]]
> Sent: Friday, December 18, 1998 10:35 AM
> To: [email-masked]
> Subject: Re: Yes, and remove more of the alphabet from the PKIX soup
> (Was: RE: Can we now kill CMMF?)
>
>
> I like Bill suggestion. Less documentation is better (KISS ;-)
>
> Aram Perez
> Apple Computer, Inc.
>
> >Folks,
> >
> > 1.  I second Al's motion!
> >
> > 2.  Now, let's start working on reducing some more of this PKIX
> >alphabet-soup nonsense.
> >
> > 3.  Prime candidates would seem to include (for now) CRMF, CMP, and
> >CMC.  All can/should be rolled into one document.
> >
> > 4.  Since CMC is essentially a superset of CMMF and CRMF, the latter
> >two can/should be collapsed into the former.
> >
> > 5.  Since CMP and CMC/CMMF/CRMF are essentially supersets of one
> >another, one can/should be collapsed into the other.
> >
> > 6.  Since CMC/CMMF/CRMF is of more recent vintage, and currently
> >under very active and broad-based discussion, it will likely
> reflect many
> >new lessons learned (especially from the real world of
> registration), and
> >ipso facto obsolete CMP.
> >
> > 7.  So why not cut to the chase and collapse CMP into CMC/CMMF/CRMF
> >now?
> >
> > 8.  This will leave us with one, combined, substantially-revised,
> >updated, integrated, and thoroughly-scrubbed document:  the
> "new CMC".
> >One-stop shopping for implementers!  Interoperability
> nirvana at long last!
> >
> > Comments?
> >
> >Bill
> >
> >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >William F. Flanigan, Jr., Ph.D.       Voice:           (703) 681-2318
> >Defense Information Systems Agency      Fax:           (703)
> 681-2814
> >Information Assurance Office (JED)      DSN:
>      761
> >5600 Columbia Pike, Room 632     Voice Mail:           (703)
> 681-2318
> >Falls Church, VA 22041-2717        Internet:  <[email-masked]>
> >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >
> >
> >
> >> -----Original Message-----
> >> From: Al Arsenault [SMTP:[email-masked]]
> >> Sent: Wednesday, November 18, 1998 7:47 AM
> >> To: [email-masked]
> >> Subject: Can we now kill CMMF?
> >>
> > [snip]
> >
> >> So - I suggest that we now kill the CMMF document, as it
> serves no useful
> >> purpose.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Andrew Probert" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Thu, 11 Feb 1999 11:11:20 -0500
Importance: Normal
Sender: [email-masked]

> 	[Andrew Probert]  If your DNS is down and you dont have backup
> servers, then the Internet is down.

Which is why folk have backup servers and as a result the Internet is
always up. 

> 	This is technology neutral, the issue is the same whether its a
> directory server or any other form of server.

No, it is not. DNS supports a very minimal name translation service. As a 
result replication is easy and does not introduce major interdependencies
between servers.

> 	As I understand Alan's Draft he is proposing extending the X.500
> specification, 

PRECISELY.

Alan is not talking about X.500. He is talking about Alan.500, an unproven
protocol with ZERO operational experience.

> > second if it did it might get tiresome doing a search of
> > the entire directory space for an entry with the right attribute, 
> > 
> 	[Andrew Probert]  Why tiresome, I would assume software does this
> transparently for you and easily, if the namespace is rational and
> connectivity is there.  

But the namespace is not rational. The name space is IANA, partitioned
over X.500 DN's.

> > third
> > X.500 is only standardized over the OSI network stack and not over IP,
> > LDAP does not include the replication protocols being promoted as the
> > basis
> > for the 'global scalability' claim.
> > 
> 	[Andrew Probert]  LDAP is alive and kicking.  Microsoft have
> included it..  Netscape and many others are promoting it.

And neither have yet agreed on a common replication protocol - except
that neither wants to use the X.500 replication protocols.

Standardization of server-server protocols in the same domain of authority
is rarely urgent. I doubt that many enterprises will be installing 
heterogeneous directory systems. Certainly interoperability between
'X.500' products from different vendors is less than seamless.

I don't see a need therefore to use LDAP or X.500 as the transfer
protocol for OCSP. Not only is HTTP considerably more efficient,
the much vaunted data model and replication protocols are a poor
match for the particular needs of an online status protocol.

		Phill

From: Andrew Probert <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Thu, 11 Feb 1999 10:16:40 +1100
Sender: [email-masked]

Comments Inline..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Thursday, February 11, 1999 8:03 AM
> To:	David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> > I'm at a loss to understand Phill's suggestion to use DNS SRV records
> > (instead of just putting the CA's URL in the cert itself), and Alan
> > Lloyd's suggestion that putting a URL in a cert would require an
> > army of administrators.  Running a directory tightly coupled to
> > the security management infrastructure requires the army; running
> > a loosely coupled directory/repository named in a URL is easier.
> 
> The URL in the cert method is fine but some folk have a problem. For
> example
> the revocation service may be other than the CA originally specified. It
> may
> not be possible to access the URL specified in the Cert when the time
> comes
> to rely on it.
> 
> My interpretation of Alan's post was that he is proposing much more.
> He wants to weld the PKI to the directory so that if the Directory is
> down it is certain the PKI will be as well. This is the 'directory
> dependent' model of PKI, I don't like that idea.
> 
	[Andrew Probert]  If your DNS is down and you dont have backup
servers, then the Internet is down.

	If you are doing online/realtime checking of CRLs etc, then if a CRL
server is down, PKI is down.  

	This is technology neutral, the issue is the same whether its a
directory server or any other form of server.
>  
> The 'directory linked' approach I believe is sensible uses the directory,
> but only for purposes that are a good fit - i.e. locating parties -
> One problem is how you obtain the cert in the first place given that
> you probably are looking for a Cert which maps to [email-masked] so you can
> do email. URLs in the cert don't help in this case :-)
> 
	[Andrew Probert]  I think the current discussion is also centric on
having the cert and trying to find the CRL.  a)  You would be looking for a
Cert that matched the SubjectName, at the Issuer, all of which is encoded in
the X.509 Cert in the first place. Good fit. b) You would be querying a
server based upon IssuerDistinguishedName and Certficate Serial Number.
Extension required, but an easy one.

	Also, when you have a scenario where you want to route a query
server -> server -> server across the planet and trust the results, then its
also a good fit because strongly authenticated sessions are a part of the
protocol.

	As I understand Alan's Draft he is proposing extending the X.500
specification, to support OCSP-like functions.  This has the benefit of
inheriting a lot of features of X.500, as above, from mature deployed
technology.  Features are strong authentication between server - server,
client - server, flexible / extensible object model etc.

> According to Alan you go to the Global X.500 directory system and
> perform a lookup. This approach only has three problems, first no such
> directory exists, 
	[Andrew Probert]  Directories do exist now.  I know of CA's already
running them for certficiate and CRL publishing.  KeyPOST in Australia for
example.  Most CA vendors cite directory interoperability already.  CISCO,
Microsoft, Netcape, Sun and many more are promoting them.

> second if it did it might get tiresome doing a search of
> the entire directory space for an entry with the right attribute, 
> 
	[Andrew Probert]  Why tiresome, I would assume software does this
transparently for you and easily, if the namespace is rational and
connectivity is there.  Directories are a form of database, and if properly
design have Indexing strategies to ensure minimal resource usage.

> third
> X.500 is only standardized over the OSI network stack and not over IP,
> LDAP does not include the replication protocols being promoted as the
> basis
> for the 'global scalability' claim.
> 
	[Andrew Probert]  LDAP is alive and kicking.  Microsoft have
included it..  Netscape and many others are promoting it.

	Vendors have LDAP front-ends to X.500 backend servers, so an LDAP
client can transparently utilise the backend features of X.500.  This exists
today.

	DAP itself can easily run in workstations, if one wants tighter
control of what servers are doing, and contrary to Urban Myth, is in some
ways lighter than LDAP.  Besides people are putting strong authentication
into LDAP anyway.

	X.500 does run over IP, RFC1006 has been around for years to support
this, talk to all of the vendors!

> In conclusion I really don't know why we need the argument. We have
> established a function for directories in PKIX that makes sense. 
> 
	[Andrew Probert]  But .. other protocols are being invented, whereas
the alternate of extending existing products / protocols is avoided?  Why?
> We
> have revocation mechanisms which make sense. 
	[Andrew Probert]  Disagree.  Pasadena Ladies Club scenario, recently
discussed shows this is not the case.  Server to Server protocols have
immature.
> I don't know why we need
> to conflate revocation of authentication credentials and the directory.
> Authorization credentials might be another matter, but those are not
> currently in PKIX scope.
> 
	[Andrew Probert]  !
> 		Phill

From: Andrew Probert <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, Andrew Probert <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Thu, 11 Feb 1999 09:41:02 +1100
Sender: [email-masked]

Thks.  For clarification, I am not advocating SET or the banking naming
model as specific solutions, merely operational analogies to the
requirements.

I am suggesting is that there are design analogies for banking -> PKI that
are useful to consider for other industries / uses.  Banking is a high
volume business with a big customer base and they, driven by operational
needs, have adopted certain operational approaches, albeit highly
specilised...

Comments inline.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Peter Williams [SMTP:[email-masked]]
> Sent:	Thursday, February 11, 1999 4:07 AM
> To:	Andrew Probert; [email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> Andrew,
> 
> Like some others on this list, I took part in a design
> using  PKI in the banking-centric SET protocol. Banking
> infrastructure is indeed complex, and has little
> in common with residential or corporate infrastructures for
> email accounts. It has little to do with domain-names
> used by routers, and has even less to do with
> political/telco/postal notions of physical
> and telco addresses. It is true that as a global infrastructure,
> banking does tend to touch a little on all the above, as it joins
> in with the Internet. 
	[Andrew Probert]  Agreed and interfacing issues are going to
increase!  In different ways PKI is more complex, because we have to deal
with Privacy which SET avoided by dealing with account numbers, only.
> It touches on those ideas however
> in a banking regulation-induced manner, which it itself
> highly specialized.
> 
	[Andrew Probert]  Agreed.
> In summary, banking policies for global PKI is best
> addressed in specialist banking forums. 
	[Andrew Probert]  Agreed
> Our role
> is to ensure the underlying standard software can
> be configured in the field to enable those policies
> for each type of service infrastructure: banking, insurance,
> trading, switching, factoring, and any other
> similar business.
	[Andrew Probert]  These businesses have different policy drivers,
but similar infrastrcture needs.
> Where names are concerned, it would be right for
> IETF PKIX to advise that schematic support for
> naming architectures be built into the better PKI
> component implementations. 
	[Andrew Probert]  Absolutely!!
> It would be
> quite wrong to mandate that the
> SET protocol's prescribed banking name schema be
> supported by all conforming implementations
> for example.
	[Andrew Probert]  I agree and haven't been proposing this.

> Similarly, it is useful that PKIX interacts with
> directories using the X.500 information model. It
> would be quite wrong to mandate that all PKI
> implementations address chained and replicated
> directories, or even be forced to become dependent
> on the data accuracy and knowledge distribution
> issues associated with any (distributed) directory
> operation.
> 
	[Andrew Probert]  If they want to be "islands of incompatibility is
a sea of connectivity" its OK by me.  The first level of global
interoperability is a globally interoperable Name service for PKI.  That
should be put in place administratively, then connectivity should follow, as
required...

> What can one do to address these important
> but not critical matters to aid PKIX make
> a difference to the actual PKI deployment world?
> 
	[Andrew Probert]  I would agreed the Urgency is not high, but it is
Critical.  If naming is not properly addressed, then their will be a big
retrofit cost in a few years time.

> One could evangelize the PKI-oriented naming and
> chaining issues in the IETF directory groups.
> 
	[Andrew Probert]  Yep.
> One could also evangelize use of PKIX
> as a mandatory technical baseline in whichever
> industry groups you deal with - and
> encourage them to write up formal profiles
> and certification polices to tune PKIX
> technical infrastructure to their modes
> of doing business.
> 
	[Andrew Probert]  Agreed, totally!
> Peter.
> 
> 
> -----Original Message-----
> From: Andrew Probert <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Wednesday, February 10, 1999 12:43 AM
> Subject: RE: Finding PKIX Servers!
> 
> 
> >The discussion has slipped from infrastructure management to account
> >management alone, with the last couple of exchanges e.g. simply a Cert
> and
> >an Account number!
> >
> >Again .. Banking infrastructure relies upon giving a customer a simple
> >'name'  (card-number) within a naming scheme:
> >
> >   prefix-account number
> >
> >Where the prefixes are globally registered in a process agreed amongst
> >financial institutions, the authorities have an established registration
> >process and a naming convention for these, to ensure global
> >interoperability.  It works.
> >
> >The customer view of it all is very simple i.e. Card and PIN.
> >
> >The naming scheme's prefixes implicitly indicate the routing of
> transactions
> >to the Issuer for Authorisation.  Its a good model.  We are not seeing
> the
> >same design elegence in the current standards, we are seeing complicated
> >mechanisms.
> >
> >Behind the scenes in banking are *heavy* *costly* infrastructure to
> support
> >Online Authorisation providing receipts, which includes EFT terminal to
> >switch, switch to switch protocols, terminal key management, switch key
> >managment, plus of course the black lists handled by each issuer.
> >
> >Recent dialogue ignores the clerical and administrative effort that is
> >expended in managing the infrastructure, Help Desks, Technicians,
> Operators,
> >to a simple Cert <--> Account number technical paradigm.
> >
> >I like the banking system analogy if we look at the totality of its
> >operations.  I think a broader vision of the infrastructure that needs to
> be
> >managed, is required.
> >
> >
> >Andew Probert
> >Rotek Consulting   http://www.rotek.com.au
> >a Division of Secure Network Solutions
> >Tel  +61 3 9690 8877
> >Fax +61 3 9690 8171

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Wed, 10 Feb 1999 16:02:35 -0500
Importance: Normal
Sender: [email-masked]

> I'm at a loss to understand Phill's suggestion to use DNS SRV records
> (instead of just putting the CA's URL in the cert itself), and Alan
> Lloyd's suggestion that putting a URL in a cert would require an
> army of administrators.  Running a directory tightly coupled to
> the security management infrastructure requires the army; running
> a loosely coupled directory/repository named in a URL is easier.

The URL in the cert method is fine but some folk have a problem. For example
the revocation service may be other than the CA originally specified. It may
not be possible to access the URL specified in the Cert when the time comes
to rely on it.

My interpretation of Alan's post was that he is proposing much more.
He wants to weld the PKI to the directory so that if the Directory is
down it is certain the PKI will be as well. This is the 'directory
dependent' model of PKI, I don't like that idea.

The 'directory linked' approach I believe is sensible uses the directory,
but only for purposes that are a good fit - i.e. locating parties -
One problem is how you obtain the cert in the first place given that
you probably are looking for a Cert which maps to [email-masked] so you can
do email. URLs in the cert don't help in this case :-)

According to Alan you go to the Global X.500 directory system and
perform a lookup. This approach only has three problems, first no such
directory exists, second if it did it might get tiresome doing a search of
the entire directory space for an entry with the right attribute, third
X.500 is only standardized over the OSI network stack and not over IP,
LDAP does not include the replication protocols being promoted as the basis
for the 'global scalability' claim.

In conclusion I really don't know why we need the argument. We have
established a function for directories in PKIX that makes sense. We
have revocation mechanisms which make sense. I don't know why we need
to conflate revocation of authentication credentials and the directory.
Authorization credentials might be another matter, but those are not
currently in PKIX scope.

		Phill

From: "Ambarish Malpani" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Usage of CRL Issuing Distribution Point
Date: Wed, 10 Feb 1999 12:11:18 -0800
Importance: Normal
Sender: [email-masked]

Hi Pau,
    If your CA is "really" using CRLDP, then you need to be
careful when you say you have "the" CRL. Part of the point of
CRLDP (as opposed to simple CRLs), is, that a CA can now issue
multiple little CRLs, depending on how it decides to partition
revocation data.

For example, it may create one CRLDP for certificates with serial
numbers between 1-100. Another one for certs from 101-200 and so
on.

Also, it may decide to issue multple potential CRLs on which
a particular cert may occur - for example, there may be one CRL
for key compromise (which is updated very, very frequently), another
for lost keys, etc.

So, there isn't necessarily a single CRL you need to look at.

If your CA decides to use CRLDP in its simplest form and just
issue a single CRL that contains all revocation data, you
still need to be careful. A CRL contains 2 times - a thisUpdate
and a nextUpdate, where the thisUpdate is the time at which
the CRL was issued, while the nextUpdate is the time
at or *before* which the next CRL will be issued.

This means that there is *no* guarantee that the CRL you have
from the CA is the latest one it issued. So depending on the
sensitivity of the transaction, you may decide to go check
the CA for a newer CRL, use the cached CRL, or wait till
nextUpdate is in the past, go grab a new CRL from the CA at
that time and verify that the cert is not on that CRL.

Hope this helps,
Regards,
Ambarish

P.S. To figure out which CRLs apply to the certificate you are
trying to check, you normally look for the path to the CRLs in
the certificate. Once you retrieve the CRL, you need to check
that the CRL has the same name as the one you thought you
were retrieving. So the extension you look for in the cert
is the one with OID id-ce-cRLDistributionPoints, while the name
of the CRL can be found in the CRL (if present), with the
OID id-ce-issuingDistributionPoint.

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of [email-masked]
> Sent: Monday, February 08, 1999 8:55 AM
> To: [email-masked]
> Subject: Usage of CRL Issuing Distribution Point
> 
> 
> Hellow, I am a new comer to PKIX.
> I have a question about the usage of the
> CRL distribution point:
> 
> If I have the CRL, then do I still need to know
> the distribution point ? Is this entension intended
> for furture retrival of CRL's (and of course, to indicate
> why the cert's in the list are revoked.) ?
> 
> If I don't know the distribution point, is there a
> standard/suggested way to learn it without getting the
> CRL ?
> 
> Thanks in advance.
> 
> 
> Regards, Pau-Chen
> 

From: "Peter Williams" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Finding PKIX Servers!
Date: Wed, 10 Feb 1999 11:27:13 -0600
Sender: [email-masked]

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, February 10, 1999 9:52 AM
Subject: RE: Finding PKIX Servers!
 
>Similarly, the PKIX community should require that any proposal for
>a standardized cert retrieval mechanism enable a similar separation
>between CAs and repositories.  A repository can have one or more
>names; it doesn't matter whether they are in the DNS space or the
>X.500 space except that: 1) names registered under DNS are global
>today, and 2) if you are going to use the Internet to move data
>around, you have to wind up with an IP address for the repository
>at some point.  Mapping X.500 names to IP addresses involves
>either creating a separate infrastructure parallel to DNS, or using
>a three step lookup: X.500 name -> DNS name -> IP address.

PKIX already enables any deployment to separate CAs from
Repository agents. Today, a VeriSign Certificate can contain
a URL to a ValiCert OCSP responder. Or not. Similarly,
the same certificate can implicitly point a user to
the formal notice Repository (VeriSign Repository) or
explicitly point to one managed by the US Dept. of Defense.

I do not believe we need to first standardize a global name server 
infrastructure to enable PKIX to succeed. Nor should we
make a conformance condition hinge on the requirement
for PKIX conformance-claiming software to deal with
name servers. Of course it should be an option for
those making integrated PKI/Directory/URN solutions,
particularly in the corporate LAN world of NDS and 
ActiveDirectory.

 Peter.

From: "Peter Williams" <[email-masked]>
To: "Andrew Probert" <[email-masked]>, <[email-masked]>
Subject: Re: Finding PKIX Servers!
Date: Wed, 10 Feb 1999 11:06:30 -0600
Sender: [email-masked]

Andrew,

Like some others on this list, I took part in a design
using  PKI in the banking-centric SET protocol. Banking
infrastructure is indeed complex, and has little
in common with residential or corporate infrastructures for
email accounts. It has little to do with domain-names
used by routers, and has even less to do with
political/telco/postal notions of physical
and telco addresses. It is true that as a global infrastructure,
banking does tend to touch a little on all the above, as it joins
in with the Internet. It touches on those ideas however
in a banking regulation-induced manner, which it itself
highly specialized.

In summary, banking policies for global PKI is best
addressed in specialist banking forums. Our role
is to ensure the underlying standard software can
be configured in the field to enable those policies
for each type of service infrastructure: banking, insurance,
trading, switching, factoring, and any other
similar business.

Where names are concerned, it would be right for
IETF PKIX to advise that schematic support for
naming architectures be built into the better PKI
component implementations. It would be
quite wrong to mandate that the
SET protocol's prescribed banking name schema be
supported by all conforming implementations
for example.

Similarly, it is useful that PKIX interacts with
directories using the X.500 information model. It
would be quite wrong to mandate that all PKI
implementations address chained and replicated
directories, or even be forced to become dependent
on the data accuracy and knowledge distribution
issues associated with any (distributed) directory
operation.

What can one do to address these important
but not critical matters to aid PKIX make
a difference to the actual PKI deployment world?

One could evangelize the PKI-oriented naming and
chaining issues in the IETF directory groups.
One could also evangelize use of PKIX
as a mandatory technical baseline in whichever
industry groups you deal with - and
encourage them to write up formal profiles
and certification polices to tune PKIX
technical infrastructure to their modes
of doing business.

Peter.

-----Original Message-----
From: Andrew Probert <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, February 10, 1999 12:43 AM
Subject: RE: Finding PKIX Servers!

>The discussion has slipped from infrastructure management to account
>management alone, with the last couple of exchanges e.g. simply a Cert and
>an Account number!
>
>Again .. Banking infrastructure relies upon giving a customer a simple
>'name'  (card-number) within a naming scheme:
>
>   prefix-account number
>
>Where the prefixes are globally registered in a process agreed amongst
>financial institutions, the authorities have an established registration
>process and a naming convention for these, to ensure global
>interoperability.  It works.
>
>The customer view of it all is very simple i.e. Card and PIN.
>
>The naming scheme's prefixes implicitly indicate the routing of
transactions
>to the Issuer for Authorisation.  Its a good model.  We are not seeing the
>same design elegence in the current standards, we are seeing complicated
>mechanisms.
>
>Behind the scenes in banking are *heavy* *costly* infrastructure to support
>Online Authorisation providing receipts, which includes EFT terminal to
>switch, switch to switch protocols, terminal key management, switch key
>managment, plus of course the black lists handled by each issuer.
>
>Recent dialogue ignores the clerical and administrative effort that is
>expended in managing the infrastructure, Help Desks, Technicians,
Operators,
>to a simple Cert <--> Account number technical paradigm.
>
>I like the banking system analogy if we look at the totality of its
>operations.  I think a broader vision of the infrastructure that needs to
be
>managed, is required.
>
>
>Andew Probert
>Rotek Consulting   http://www.rotek.com.au
>a Division of Secure Network Solutions
>Tel  +61 3 9690 8877
>Fax +61 3 9690 8171

Date: Wed, 10 Feb 1999 19:01:10 +0100
From: Juergen Walter <[email-masked]>
Reply-To: [email-masked]
To: Denis Pinkas <[email-masked]>, Al Arsenault <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: POP section for next Roadmap draft
Sender: [email-masked]

Denis,

[key uniqueness section deleted]

> > Even if the signed data includes a cert identifier the threat
> > described by Al remains unsolved.
> 
> You would have to be more precise.

Sorry, the precise scenario was below. 

> 
> > Substitution of certs is a minor
> > problem (the cert identifier encapsulation has solved the problem as you
> > wrote, i. e. "new" mechanism). The major problem is key uniqueness. Even
> > the "new" mechanism needs POP.
> >
> > If CAs do not POP prior to certification then they probably allow that
> > two end entities share the same signature key.
> 
> If they really share the same key, then POP can be made by each entity and will not
> prevent the scenario to happen. 

The event that key sharing appears then unlikely happens, provided there
are some security measures (e. g. approved key generators, suitable key
length) in force. Nevertheless, some CAs may use POP to detect this
case.

>If they don't then only one (or no one) has the
> corresponding private key.

"only one" is key uniqueness and therefore no problem at all. "no one"
does not appear, if the CA does POP. Why should a public key be certfied
by a CA, when nobody knows the corresponding private key? If a CA does,
then it allows key reservation. And in addition, there are misleading
certificates containing these "reservated keys".

> 
> > This may be approriate in
> > certain circumstances, but this is definitely not appropriate in
> > non-repudiation framework. The other certificate applications may be
> > restricted according to their usage (see Al´s key management example).
> >
> > I would like to use Al´s signature key example where Alice and Mal are
> > involved. If I have understood correctly, a CA which does not POP may
> > issue two certificates with different subject identifiers (e. g.
> > distinguished names) and one identical public key. So, Alice may include
> > Mal´s identifier and sign the transaction. In the following the dispute
> > arises when Mal repudiated the transaction. Alice then repudiates the
> > possession of private key as well. Who is responsible for the
> > transaction? Mal?! What is about the case when there exist more than one
> > Mal (i. e. more than two certificates with identical public key and
> > different identities)?! What do you answer provided that Mal says,
> > sorry, it had been a joke? Is your agreement with Mal legally approved
> > for such cases?
> 
> If someone manages to get a certificate containing a public key for which someone
> else has the corresponding private key, then that entity has to be aware of problems
> that may occur. It is up to the entity to assume the possible consequences, but the
> CA does not have to be responsible.

The consequences are not restricted to Mal. The relying party has the
problem that Alice is able to deny her signature.  She retrieves Mal´s
certificate and signs transaction T including Mal´s certificate. Nobody
except Alice knows that Alice has signed T. Even if transaction T
includes a signed challenge i. e. POP is done at signature generation
time the signature token includes no evidence who signed T.

> 
> > Furthermore, if a person signs a document with its private key in a
> > non-repudiation framework, then it has accepted the information content.
> > When a CA signs the PRETENDED subject public key, then it has probably
> > accepted false information. One basic function of a CA is key
> > registration. But, if CAs does not verify POP, then the key is not
> > well-registered.
> 
> No, the CA can testify that this user wanted that public key in his certificate.

I have serious concerns about the terminology "certificate". X.509
definition does not say "pretended" public key. I think that the PKIX-1
section about POP is misleading according to the reason why CAs must do
POP.

> 
> > So, the CA does not warrant for information contained
> > in the issued certificate. Why a relying party should trust such CAs? A
> > new certificate extension "CA has done POP" is a very bad idea (see next
> > para).
> >
> > I think that the mechanism called "new" without POP is essentially an
> > attribute certification. The PRETENDED subject public key is then one of
> > the certified attributes. The attribute certificate binds the PRETENDED
> > subject public key to the end entity´s distinguished name and other
> > attributes if appropriate. May be, I have overseen somewhat, but your
> > solution is essentially a X.509 attribute certificate.
> 
> It can be used in the case where attributes are in the certificate, but this is not
> the essential point. The signer has always to include a reference of its certificate
> and to protect it under its signature.

I think that CAs doing no POP should issue attribute certificates
instead of public key certificates. Attribute certificates testify the
binding between entity´s attributes ,and either distinguished name or
certificate identifier. They are signed by a (attribute) CA. One
attribute may be entity´s pretended public key. Personally, I think that
has no worth but it may be reasonable for those CAs that do not want to
verify POP.

> 
> > Summarizing, POP is a key registration matter. At least the
> > non-repudiation framework REQUIRES POP.
> 
> No. POP is made at the protocol level (by signing the certificate identifier),
> rather than the registration phase.

I beg to differ. POP is a versatile matter e. g. protocol (as you
mentioned), key management, audit trail.

> 
> > POP SHOULD be done prior to
> > certification (personally, I prefer MUST). Alternatively, a CA MAY
> > ensure the uniqueness of the registered public keys.
> 
> There is no reason for this argument.

The reason is the following. If two entities share the same key then
they are able to generate identical signature tokens.

> 
> > If a CA receives a
> > public key that has not been certified yet for another entity, then it
> > MAY drop POP (for the moment?).
> > Those CAs that do this MUST reject a
> > registration request, that contains a public key always certified for a
> > different entity. When this registration request includes a POP and its
> > verification was succesful, the corresponding certificate MUST be
> > revoked immediately.
> 
> I do not follow you.

You are right. This was not correct, but we differ probably in the
reasoning. I think POP should be done prior to certification.

[snip]

Juergen

Date: Wed, 10 Feb 1999 10:49:19 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: RE: Finding PKIX Servers!
Sender: [email-masked]

> From: Andrew Probert <[email-masked]>
> 
> Again .. Banking infrastructure relies upon giving a customer a simple
> 'name'  (card-number) within a naming scheme:
> 
>    prefix-account number
> 
> Where the prefixes are globally registered in a process agreed amongst
> financial institutions, the authorities have an established registration
> process and a naming convention for these, to ensure global
> interoperability.  It works.  

Right.

In this thread it often appears that the distinction between Naming
authorities, Security authorities, and Retrieval mechanisms
(directories/repositories) is being either forgotten or intentionally
obfuscated.  It would be clearer (at least to me :-) if the discussion
and the architectural proposals maintained a clear separation of the
three and an explicit minimization of dependencies among them.

X.509 v3 extensions enabled the separation of naming and security
management: a car company "RR-Benz.com" or "C=de O=RR-Benz AG" could
outsource its CA functions to "CertFantastic.com" or
"C=US O=CertFantastic Inc." and I, as a relying party, could automatically
validate a cert path in which my root CA designated (after some
unspecified administrative process) CertFantastic as authoritative
for all of RR-Benz's certs.  Each entity could have names in one or
more global namespaces: the DNS namespace, the X.500 global DIT,
the banking global registered prefix space, or something else.
Those name(s) do not have any *required* connection to the path
of trust, although it makes life simpler if for some sets of
entities the trust path and the name heirarchy are topologically
related.

Similarly, the PKIX community should require that any proposal for
a standardized cert retrieval mechanism enable a similar separation
between CAs and repositories.  A repository can have one or more
names; it doesn't matter whether they are in the DNS space or the
X.500 space except that: 1) names registered under DNS are global
today, and 2) if you are going to use the Internet to move data
around, you have to wind up with an IP address for the repository
at some point.  Mapping X.500 names to IP addresses involves
either creating a separate infrastructure parallel to DNS, or using
a three step lookup: X.500 name -> DNS name -> IP address.

> From: "Tammy Carter" <[email-masked]>
> 
> I don't understand.  Several of the people on this list seem to
> believe that the way to find a CA is via some kind of advertisement.
> However, what I don't understand is why?  Bob's suggestion of using the
> certificate to contain information about where to find the CA seems to
> work AND it is more similar to the mechanism that we already have for
> finding revocation information.

Right.

I'm at a loss to understand Phill's suggestion to use DNS SRV records
(instead of just putting the CA's URL in the cert itself), and Alan
Lloyd's suggestion that putting a URL in a cert would require an
army of administrators.  Running a directory tightly coupled to
the security management infrastructure requires the army; running
a loosely coupled directory/repository named in a URL is easier.

> From: Andrew Probert <[email-masked]>
> 
> 1.  I think there is broad issue "Finding PKIX" servers in a global
> interoperable scenario, which needs to be addressed. I personally don't want
> hand code lots of browsers and software.  Is the agreed way to find a PKIX
> server going to be via URL/DNS reference as an active / informed decision.
> Requirements and discussion please?

Agreed, as above.

> 2.  I have responded to the Pasadena Ladies Club scenario, where coding a
> explicit reference into a cert to a bureau may cause an operational issue
> forcing re-issuance of all certificates, which hopefully people should admit
> is an problem?

Nope, I won't admit it's a problem.

If a CA issues a cert for a specific validity period, and contracts
out for repository services for that period, then the CA doesn't have
the option of changing its mind in the middle.  If the repository
goes bankrupt, it would seem reasonable to hand over operation of
the URL to some other organization.  If the repository willfully
decides not to honor the service contract, and as a result causes
damages because certs and CRLs can't be found, then take 'em to court.

Nothing forces re-issuance of all certificates; that's a red herring.

From: Andrew Probert <[email-masked]>
To: [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Wed, 10 Feb 1999 17:36:06 +1100
Sender: [email-masked]

The discussion has slipped from infrastructure management to account
management alone, with the last couple of exchanges e.g. simply a Cert and
an Account number!

Again .. Banking infrastructure relies upon giving a customer a simple
'name'  (card-number) within a naming scheme:

   prefix-account number

Where the prefixes are globally registered in a process agreed amongst
financial institutions, the authorities have an established registration
process and a naming convention for these, to ensure global
interoperability.  It works.  

The customer view of it all is very simple i.e. Card and PIN.

The naming scheme's prefixes implicitly indicate the routing of transactions
to the Issuer for Authorisation.  Its a good model.  We are not seeing the
same design elegence in the current standards, we are seeing complicated
mechanisms.

Behind the scenes in banking are *heavy* *costly* infrastructure to support
Online Authorisation providing receipts, which includes EFT terminal to
switch, switch to switch protocols, terminal key management, switch key
managment, plus of course the black lists handled by each issuer.

Recent dialogue ignores the clerical and administrative effort that is
expended in managing the infrastructure, Help Desks, Technicians, Operators,
to a simple Cert <--> Account number technical paradigm.

I like the banking system analogy if we look at the totality of its
operations.  I think a broader vision of the infrastructure that needs to be
managed, is required.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

Date: Tue, 09 Feb 1999 19:08:33 +0100
From: Juergen Walter <[email-masked]>
Reply-To: [email-masked]
To: Denis Pinkas <[email-masked]>, Al Arsenault <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: POP section for next Roadmap draft
Sender: [email-masked]

Denis,

thanks for the response. I stick on the issue why POP-CAs ensures key
uniqueness. The other issues remains open for the moment, I apologize.

To avoid misunderstandings POP by some means is ensured when the CA has
verified the binding between the private key and the public key, that
the entity wants to be certified. The concrete means are surely policy
matters and therefore outside the scope of PKIX.

More comments follow in line.

Denis Pinkas wrote:
> 
> Juergen,
> 
> Sorry for the delay. I have had difficulties to find some time available this week.
> 
> > Denis,
> >
> > I agree essentially with Al´s position. I would like to add some
> > comments.
> >
> > For non-repudiation key usage the CA must ensure that the public key is
> > UNIQUE.
> 
> I do not believe so.

I have to be more precise if I recommend public key uniqueness. More
precicely, I think that the risk of public key clashes should be
sufficiently small. This residual risk is again a policy matter and
outside the scope of PKIX work.
 
> Even if this would be the case, all the CAs of the world would
> not be bale to interconnect to verify this.

This is not necessary. But CAs can ensure public key uniqueness
implicitly. If they do POP then they ensure that no entity who does not
own the private key becomes certified (i. e. the CA issues a certificate
that contains the corresponding public key). CAs may recommend the usage
of a suitable key generator. Let me assume that this key generator works
correctly. Then the event of identical keys owned by two entities 
unlikely happens. An element of risk remains but this is certainly
small. Surely it is close to the risk of a brute force attack of the
signing key under the assumptions above. All public keys that are
distributed by CAs are (almost) unique. The distribution mechanism of
public keys is that a CA signs the entity´s certificate. All other
mechanisms like directory, repository or whatever are operational
issues.

If CAs do not POP by any means then this fact is no longer true. Then
there probably exist certified public keys that are not generated by a
suitable key generator, i. e. either the corresponding private key is
unknown or it is known to another entity. "knowledge" should be
interpreted as ability to apply the private key.

The first case leads to public key reservation that is really stupid.
(Is it analogously to the domain reservation?) 

In the second case the phenomena of public key hijacking appears, i. e.
an entity may retrieve a public key and manage the certification by a
non-POP-CA. It is not necessary that this non-POP-CA coincides with the
CA that issued the certificate for the hijacked public key.

Is public key hijacking possible when we consider non-POP-CAs? What is
about the public key distribution function of a non-POP-CA? It seems to
me there may be a lot of waste in its repository.

The possible consequences remain for further discussion if I find some
time.

[snip]

Juergen

Date: Tue, 09 Feb 1999 09:57:01 -0500
To: Michael Elkins <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Error in Path Validation description in RFC2549?
Cc: [email-masked]
Sender: [email-masked]

Thank you for pointing out the error.  That paragraph should read:

   The actions performed by the path processing software for each
   certificate i=1 through n are described below.  The self-signed
   certificate is certificate i=1, the end entity certificate is i=n.
   The processing is performed sequentially, so that processing
   certificate j affects the state variables for processing certificate
   (j+1). Note that actions (i) through (m) are not applied to the end
   entity certificate (certificate i=n).

Russ

At 01:59 PM 2/8/99 -0800, Michael Elkins wrote:
>In RFC2549, Section 6.1 ("Basic Path Validation"), paragraph 7, it is
>stated:
>
>   The actions performed by the path processing software for each
>   certificate i=1 through n are described below.  The self-signed
>   certificate is certificate i=1, the end entity certificate is i=n.
>   The processing is performed sequentially, so that processing
>   certificate i affects the state variables for processing certificate
>   (i+1). Note that actions (h) through (m) are not applied to the end
>   entity certificate (certificate n).
>
>Below that, item (h) is described:
>
>      (h)  Recognize and process any other critical extension present in
>      the certificate.
>
>The last statement of the first paragraph would seem to indicate that critical
>extensions in the end entity certificate can be ignored.  However, in
>section 4.2 ("Standard Certificate Extensions"), paragraph 1, it is stated:
>
>   A certificate using system MUST reject the certificate if it encounters
>   a critical extension it does not recognize; however, a non-critical
>   extension may be ignored if it is not recognized.
>
>Unless I am misreading something, this text is inconsistent..  The latter is
>clearly the correct procedure, is it not?
>
>me

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Error in Path Validation description in RFC2549?
Reply-To: [email-masked]
Date: Tue, 9 Feb 1999 18:02:20 (NZDT)
Sender: [email-masked]

>[Critical extensions]
>Unless I am misreading something, this text is inconsistent..  The latter is
>clearly the correct procedure, is it not?
 
Ah, you've just discovered the X.509 critical extension rathole :-).  For 
more information on this, you may want to look at 
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt.
 
Peter.

To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Finding PKIX Servers!
Reply-To: [email-masked]
From: "Perry E. Metzger" <[email-masked]>
Date: 08 Feb 1999 18:20:47 -0500
Lines: 11
Sender: [email-masked]

Michael Sierchio <[email-masked]> writes:
> Other than arguing against the need for such a global directory
> infrastructure,  do you have philosophical or aesthetic problems
> with it?

Since such an infrastructure would be very expensive and hard to
manage, I'd say that the lack of need or use probably argues on its
own against its implementation.

Perry

Date: Mon, 08 Feb 1999 15:12:05 -0800
From: Michael Sierchio <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: "[email-masked]" <[email-masked]>
Subject: Re: Finding PKIX Servers!
Sender: [email-masked]

"Perry E. Metzger" wrote:

> Cert directories are totally unneeded in the model I'm describing
> because the issuing bank can just store the cert (or even a naked
> public key) with the account information.

Agreed on that count.  I suppose that what I was trying to say is
that the signer of a cert (or issuer of a keypair,  maybe a bank?)
has an authoritative role.  A directory is just a collection, a
means of publication,  and has no authoritative role.

A business enterprise may find an internal (LDAP) directory of certs
useful for DH key agreement for IPsec, for example.  But there is
no need for a GLOBAL directory structure, AFAICT. 

Other than arguing against the need for such a global directory
infrastructure,  do you have philosophical or aesthetic problems
with it?

Date: Mon, 8 Feb 1999 13:59:41 -0800
From: Michael Elkins <[email-masked]>
To: [email-masked]
Subject: Error in Path Validation description in RFC2549?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In RFC2549, Section 6.1 ("Basic Path Validation"), paragraph 7, it is
stated:

   The actions performed by the path processing software for each
   certificate i=1 through n are described below.  The self-signed
   certificate is certificate i=1, the end entity certificate is i=n.
   The processing is performed sequentially, so that processing
   certificate i affects the state variables for processing certificate
   (i+1). Note that actions (h) through (m) are not applied to the end
   entity certificate (certificate n).

Below that, item (h) is described:

      (h)  Recognize and process any other critical extension present in
      the certificate.

The last statement of the first paragraph would seem to indicate that critical
extensions in the end entity certificate can be ignored.  However, in
section 4.2 ("Standard Certificate Extensions"), paragraph 1, it is stated:

   A certificate using system MUST reject the certificate if it encounters
   a critical extension it does not recognize; however, a non-critical
   extension may be ignored if it is not recognized.

Unless I am misreading something, this text is inconsistent..  The latter is
clearly the correct procedure, is it not?

me

From: [email-masked]
Date: Mon, 8 Feb 1999 11:55:18 -0500
To: [email-masked]
Subject: Usage of CRL Issuing Distribution Point
Content-Md5: nXMQ3VCCKOFkNJknPvw+YA==
Sender: [email-masked]

Hellow, I am a new comer to PKIX.
I have a question about the usage of the
CRL distribution point:

If I have the CRL, then do I still need to know
the distribution point ? Is this entension intended
for furture retrival of CRL's (and of course, to indicate
why the cert's in the list are revoked.) ?

If I don't know the distribution point, is there a
standard/suggested way to learn it without getting the
CRL ?

Thanks in advance.

Regards, Pau-Chen

To: [email-masked]
Cc: Andrew Probert <[email-masked]>, [email-masked]
Subject: Re: Finding PKIX Servers!
Reply-To: [email-masked]
From: "Perry E. Metzger" <[email-masked]>
Date: 08 Feb 1999 11:28:07 -0500
Lines: 49
Sender: [email-masked]

Michael Sierchio <[email-masked]> writes:
> "Perry E. Metzger" wrote:
> 
> > To put it another way: when you walk in to the book store to buy a
> > book, the store doesn't care a bit about who you are. They care about
> > whether they will be PAID, and knowing you have a valid cert tells
> > them nothing about that. What they need is a signed statement from their
> > accepting bank saying they will be paid -- and that doesn't require a
> > Global PKI to set up. It might use a PKI set up by the bank or credit
> > network for its own use, but it doesn't need a *GLOBAL* PKI.
> 
> There are two separate issues here -- if we're talking about
> presenting a cert as part of authorizing a transaction,  the
> merchant may very well be interested in identity -- certainly
> in non-repudiation.

Again, no, this is not the case.

What the merchant wants is to get word back from the accepting bank
that they will be paid. The issuing bank wants to know that you are
who you say you are -- not the merchant.

> One of the current hazards of ecommerce
> is that it is considered a "mail order" transaction,  and the
> merchant may be liable in the case of fraud -- both by statute
> and bank agreement.

That only happens right now because the issuing bank has no strong
authentication of the request to pay. Again, ultimately, the merchant
does not care who you are except for things like the ability to do
marketing or customer service -- and just knowing who you are tells
them *nothing* about whether they will be paid or not. Their real need 
is for a digitally signed message from the accepting bank saying "you
will be paid $100", not for some vague knowledge that somewhere out
there some bank has issued you a cert.

> The other issue is one of maintaining directories of such
> certs -- it has to be asked what purpose this serves.  It
> is a form of publishing trusted public key values, perhaps?
> A way for parties without prior agreement to exchange secure
> mail?  Does this have anything to do with PKI in se?   It 
> has no effect in the example described.

Cert directories are totally unneeded in the model I'm describing
because the issuing bank can just store the cert (or even a naked
public key) with the account information.

Perry

Date: Sun, 07 Feb 1999 23:25:40 -0800
From: Michael Sierchio <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: Andrew Probert <[email-masked]>, [email-masked]
Subject: Re: Finding PKIX Servers!
Sender: [email-masked]

"Perry E. Metzger" wrote:

> To put it another way: when you walk in to the book store to buy a
> book, the store doesn't care a bit about who you are. They care about
> whether they will be PAID, and knowing you have a valid cert tells
> them nothing about that. What they need is a signed statement from their
> accepting bank saying they will be paid -- and that doesn't require a
> Global PKI to set up. It might use a PKI set up by the bank or credit
> network for its own use, but it doesn't need a *GLOBAL* PKI.

There are two separate issues here -- if we're talking about
presenting a cert as part of authorizing a transaction,  the
merchant may very well be interested in identity -- certainly
in non-repudiation.  One of the current hazards of ecommerce
is that it is considered a "mail order" transaction,  and the
merchant may be liable in the case of fraud -- both by statute
and bank agreement.  So, that's the issue of identity, or
presenting a trusted credential (which is trusted because
the signer of the cert is trusted).

The other issue is one of maintaining directories of such
certs -- it has to be asked what purpose this serves.  It
is a form of publishing trusted public key values, perhaps?
A way for parties without prior agreement to exchange secure
mail?  Does this have anything to do with PKI in se?   It 
has no effect in the example described.

Cert directories,  however implemented,  are independent of whether
a hierarchical or web-of-trust model applies.   For the recipient
of a certificate the only thing that matters is if it is valid and
signed by a trusted party.  This has nothing to do with where we
find it.  A reference to a repository (other than that of the
signer) in the cert itself violates sense -- it doesn't matter.

From: Andrew Probert <[email-masked]>
To: "'Alan Lloyd'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: Andrew Probert <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 17:39:26 +1100 
Sender: [email-masked]

Agree..  We could see global PKIs from:  Postal Services, Health, Stock
Exchanges, Traffic control systems, Network control systems ad infinitum,
all with their own business purpose, policy etc.  Ideally, common
infrastructure can be designed once and deployed multiple times, saving
development costs, reinvention of wheel etc.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Alan Lloyd [SMTP:[email-masked]]
> Sent:	Monday, February 08, 1999 4:25 PM
> To:	[email-masked]'
> Cc:	Andrew Probert; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> Is there a point to this - re what we mean by global - 
> For my two bobs worth - and as I work with the bigger organisations -
> which I refer to as global - I like to think that the systems we
> build/design scale well into those operations. ie a global PKI is not
> THE global PKI. a global PKI just means the system as designed scales
> well, applies engineering, operational, information and commercial
> practices in the best knowledge that ensures really bad scaling, service
> level and operational cost factors wont be dropped on us or the
> customer.
> 
> Other comments in line
> > -----Original Message-----
> > From:	Perry E. Metzger 
> > Sent:	Monday, February 08, 1999 3:29 PM
> > To:	Alan Lloyd
> > Cc:	Andrew Probert; [email-masked]
> > Subject:	Re: Finding PKIX Servers!
> > 
> > 
> > Alan Lloyd <[email-masked]> writes:
> > > I think what Andy is implying is that we require a Banking
> > > infrastructure which is global
> > 
> > We have one already -- or hadn't you noticed?
> 	No - I just travel the globe 10 times a year - but I carry
> chickens and and a few vegies and barter with those. :-)
> 
> > > - similar to that of the telephone
> > > system. As said a PKI is a function. It will be applied into
> > vertical
> > > markets according to business models. Its a logical process to say
> > that
> > > because of the I in PKI that such functionality will be part of a
> > bigger
> > > infrastructure system and some organisations will apply that to
> > operate
> > > what they deem as global services.
> > 
> > Banks are never going to want a global PKI. 
> 	Thats a view - see definition of global above....
> 
> > Third party transaction
> > organization has the least possible application in the banking
> > industry, where the main function of the industry is itself management
> > 
> > and handling of transaction risk. Indeed, the actions of companies
> > like Verisign to try to eliminate their liability all but eliminate
> > them from usefulness to the banks.
> 	Thats a view also - I have different ones that are under NDAs.
> 
> > Remember, we are talking here about "Global" public key
> > infrastructure. Public key methods are obviously of use. "Global"
> > public key infrastructure is not of obvious use.
> 	See definition of Global above. A PKI is a function which is
> applied to a business services delivery model that has subscribers and
> providers that do transactions. Domains of these will exist and they
> will interoperate on a technical, operational or business level policy
> base. The size and scope of the PKI or PKIs that service such a market
> will be big by nature and built to commercial policy.
> 
> 	I would never say how big something will be, particularly when
> its someone elses investment that will define that.
> 	However, as an informations systems engineer - working on the
> subject matter I deal with, in the vertical markets that request our
> efforts - I dont like building obvious walls, limitations and
> operational costs purely to satisfy a "quick mechanism" to 2% of the
> problem. When that mechanism has to be followed through to get to the
> real solution to the real problem. IE. Appying PKI functionality to a
> business information and service requirement - for global use.
> 
> > > I never buy into the points that users dont care about the
> > technology -
> > > that is obvious.
> > 
> > "Don't care" is different from "don't need" or "don't want". Sure, we
> > can build computerized tongue depressors, but will the hot dog vendors
> > 
> > the eager manufacturer is  targeting WANT computerized tongue
> > depressors?
> 	no comment
> 
> 	regards alan
> > Perry

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Andrew Probert <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 16:25:09 +1100
Sender: [email-masked]

Is there a point to this - re what we mean by global - 
For my two bobs worth - and as I work with the bigger organisations -
which I refer to as global - I like to think that the systems we
build/design scale well into those operations. ie a global PKI is not
THE global PKI. a global PKI just means the system as designed scales
well, applies engineering, operational, information and commercial
practices in the best knowledge that ensures really bad scaling, service
level and operational cost factors wont be dropped on us or the
customer.

Other comments in line
> -----Original Message-----
> From:	Perry E. Metzger 
> Sent:	Monday, February 08, 1999 3:29 PM
> To:	Alan Lloyd
> Cc:	Andrew Probert; [email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
> Alan Lloyd <[email-masked]> writes:
> > I think what Andy is implying is that we require a Banking
> > infrastructure which is global
> 
> We have one already -- or hadn't you noticed?
	No - I just travel the globe 10 times a year - but I carry
chickens and and a few vegies and barter with those. :-)

> > - similar to that of the telephone
> > system. As said a PKI is a function. It will be applied into
> vertical
> > markets according to business models. Its a logical process to say
> that
> > because of the I in PKI that such functionality will be part of a
> bigger
> > infrastructure system and some organisations will apply that to
> operate
> > what they deem as global services.
> 
> Banks are never going to want a global PKI. 
	Thats a view - see definition of global above....

> Third party transaction
> organization has the least possible application in the banking
> industry, where the main function of the industry is itself management
> 
> and handling of transaction risk. Indeed, the actions of companies
> like Verisign to try to eliminate their liability all but eliminate
> them from usefulness to the banks.
	Thats a view also - I have different ones that are under NDAs.

> Remember, we are talking here about "Global" public key
> infrastructure. Public key methods are obviously of use. "Global"
> public key infrastructure is not of obvious use.
	See definition of Global above. A PKI is a function which is
applied to a business services delivery model that has subscribers and
providers that do transactions. Domains of these will exist and they
will interoperate on a technical, operational or business level policy
base. The size and scope of the PKI or PKIs that service such a market
will be big by nature and built to commercial policy.

	I would never say how big something will be, particularly when
its someone elses investment that will define that.
	However, as an informations systems engineer - working on the
subject matter I deal with, in the vertical markets that request our
efforts - I dont like building obvious walls, limitations and
operational costs purely to satisfy a "quick mechanism" to 2% of the
problem. When that mechanism has to be followed through to get to the
real solution to the real problem. IE. Appying PKI functionality to a
business information and service requirement - for global use.

> > I never buy into the points that users dont care about the
> technology -
> > that is obvious.
> 
> "Don't care" is different from "don't need" or "don't want". Sure, we
> can build computerized tongue depressors, but will the hot dog vendors
> 
> the eager manufacturer is  targeting WANT computerized tongue
> depressors?
	no comment

	regards alan
> Perry

To: Alan Lloyd <[email-masked]>
Cc: Andrew Probert <[email-masked]>, [email-masked]
Subject: Re: Finding PKIX Servers!
Reply-To: [email-masked]
From: "Perry E. Metzger" <[email-masked]>
Date: 07 Feb 1999 23:28:30 -0500
Lines: 33
Sender: [email-masked]

Alan Lloyd <[email-masked]> writes:
> I think what Andy is implying is that we require a Banking
> infrastructure which is global

We have one already -- or hadn't you noticed?

> - similar to that of the telephone
> system. As said a PKI is a function. It will be applied into vertical
> markets according to business models. Its a logical process to say that
> because of the I in PKI that such functionality will be part of a bigger
> infrastructure system and some organisations will apply that to operate
> what they deem as global services.

Banks are never going to want a global PKI. Third party transaction
organization has the least possible application in the banking
industry, where the main function of the industry is itself management 
and handling of transaction risk. Indeed, the actions of companies
like Verisign to try to eliminate their liability all but eliminate
them from usefulness to the banks.

Remember, we are talking here about "Global" public key
infrastructure. Public key methods are obviously of use. "Global"
public key infrastructure is not of obvious use.

> I never buy into the points that users dont care about the technology -
> that is obvious.

"Don't care" is different from "don't need" or "don't want". Sure, we
can build computerized tongue depressors, but will the hot dog vendors 
the eager manufacturer is  targeting WANT computerized tongue depressors?

Perry

Date: Sun, 07 Feb 1999 20:23:00 -0800
From: Brian Korver <[email-masked]>
Reply-To: [email-masked]
To: Krylov Pavel <[email-masked]>
CC: [email-masked]
Subject: Re: Authority Key Id.
Sender: [email-masked]

Krylov Pavel wrote:
> 
> Hi all!
> I read about Authority Key Id. and found some strange things.
> How I know, certificate is distinguishable from all others certificates
> by couple { IssuerCA, SerialNumber }. But Authority Key Id. ( AKId )
> contains authorityCertSerialNumber! Does it mean that I can separate CA
> certificate by couple {Issuer[of current end-user cert] + AltIssuerName,
> SerialNumber(from AKId)} ?

No.  AuthorityKeyIdentifier (in the non-KeyIdentifier usage) contains
the both the IssuerName and SerialNumber of the issuer certificate.  
That is, authorityCertIssuer and authorityCertSerialNumber must be
present as a pair.  The official ASN.1 looks something like:

AuthorityKeyIdentifier ::= SEQUENCE {
	keyIdentifier			[0] KeyIdentifier		OPTIONAL,
	authorityCertIssuer		[1] GeneralNames		OPTIONAL,
	authorityCertSerialNumber	[2] CertificateSerialNumber 	OPTIONAL }
	( WITH COMPONENTS 	{..., authorityCertIssuer PRESENT, 
					authorityCertSerialNumber PRESENT} |
	 WITH COMPONENTS	{..., authorityCertIssuer ABSENT,
					authorityCertSerialNumber ABSENT} )

> 
>    AuthorityKeyIdentifier ::= SEQUENCE {
>       keyIdentifier             [0] KeyIdentifier           OPTIONAL,
>       authorityCertIssuer       [1] GeneralNames            OPTIONAL,
>       authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
> 
> How I understand it's wrong. Example:
> 
> CA1 { SN1, Issuer1, Issuer1, .. }       CA2 {SN2, Issuer2, Issuer2, ..}
>                 |                                       |
>                 |                                       |
>                 |                                       |
> CA3:            V                                       V
>         { SN0, Issuer1, Subject3, .. }  {SN0, Issuer2, Subject3, .. }
>                                 |
>                                 |
>                                 |
> end-user                        V
> cert:           { SN123, Issuer3, Subject123, ..., AKId{[2] SN0}}

The end user cert would be:

                  { SN123, Issuer3, Subject123, ..., AKId{[1] Issuer1 [2] SN0}}

> 
> How can end-user software understand which certificate is needed?
> or Is authorityCertSerialNumber support field?
> 
> And another questions:
>         Certificate contains IssuerName and Alt.IssuerName. Well
>         then, for what purposes does AKId contain authorityCertIssuer?
>         Is it alias name for IssuerCA? or Does it match with
>         { IssuerName, Alt.IssuerName }?
> 
> What did I misunderstand?
> Thanks a lot.
> 
> ___________________________________________
> Pavel Krylov    [email-masked]

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Andrew Probert <[email-masked]>
Cc: [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 13:15:29 +1100
Sender: [email-masked]

I think what Andy is implying is that we require a Banking
infrastructure which is global - similar to that of the telephone
system. As said a PKI is a function. It will be applied into vertical
markets according to business models. Its a logical process to say that
because of the I in PKI that such functionality will be part of a bigger
infrastructure system and some organisations will apply that to operate
what they deem as global services.

I never buy into the points that users dont care about the technology -
that is obvious. But the suppliers of services for money do - so they
can understand the risk with it and manage that according to their
customer/service model.

What is important in this debate is that the engineering ideology
proposed in these standards scales in terms of its engineering, its
operations, its information management and its commercial costs.
Hand crafting MORE knowledge into certficates - that relates to servers
- which then has to relate this certficate to information objects in a
distributed business model - strikes me as utter duplication of effort
and probably doubles the cost of operation of the PKI for the customer.
With real large PKI costs estimated as 10s of millions of dollars - why
double that with hand crafted information to indirectly access something
(a server that needs to go to directory information) that can be
accessed directly through the use of directory technology.

Do it right - do it once, is a good motto.

regards alan
> -----Original Message-----
> From:	Perry E. Metzger 
> Sent:	Monday, February 08, 1999 11:36 AM
> To:	Andrew Probert
> Cc:	[email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
> Andrew Probert <[email-masked]> writes:
> > My thoughts run to business requirements like world-wide EDI
> trading,
> > shipping around contracts and documents, which require an integrated
> global
> > infrastructure.
> 
> No it doesn't. In fact, a global infrastructure is totally unneeded
> for this.
> 
> This sort of claim shows up all the time among people who haven't
> actually analyzed the real needs of real businesses. The truth of the
> matter is that no global PKI is either needed or desirable.
> 
> When people trade, they don't care about identities. They care about
> things like getting paid. That means you need a working banking
> infrastructure, not a PKI. Public key methods can help assure a
> transacting entity that its bank will pay it if it presents an
> electronic draft, or to help a transacting entity order the creation
> of such a payment, but such protocols are necessarily bilateral.
> 
> To put it another way: when you walk in to the book store to buy a
> book, the store doesn't care a bit about who you are. They care about
> whether they will be PAID, and knowing you have a valid cert tells
> them nothing about that. What they need is a signed statement from
> their
> accepting bank saying they will be paid -- and that doesn't require a
> Global PKI to set up. It might use a PKI set up by the bank or credit
> network for its own use, but it doesn't need a *GLOBAL* PKI.
> 
> 
> Perry

From: Andrew Probert <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 13:10:08 +1100 
Sender: [email-masked]

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Perry E. Metzger [SMTP:[email-masked]]
> Sent:	Monday, February 08, 1999 12:42 PM
> To:	Andrew Probert
> Cc:	[email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
	[Andrew Probert]  <SNIP> 

	The point, probably oblique, that I was trying to make is that for
PKI to work it needs infrastructure of Naming and transaction routing
(EFTPOS analogy).. and of course a driving business case.  

	In our country, its all CardNumbers over SSL and application of MOTO
rules to Internet tranding.  The risk of GETTING PAID hasn't been addressed.
I can agree SET is not yet relevant.

	<snip>

> > 	[Andrew Probert]  Banks dont need global PKI, as they will set up
> > their own.  Others do, for lessor things.
> 
> Who? For what?
> 
> 
	[Andrew Probert]  I personally think there are many applications for
PKI that are not related to GETTING PAID i.e. digitally signed documents for
non-ecommerce such as Health and Medical, Access Control systems, EDI
ordering (proof of authority etc) .  Therefore, the operational scenarios
are important.  So your question above is a vital one!

> Perry

From: Alan Lloyd <[email-masked]>
To: "'Andrew Probert'" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 13:01:55 +1100
Sender: [email-masked]

And mine - in line.

> -----Original Message-----
> From:	Andrew Probert 
> Sent:	Monday, February 08, 1999 11:09 AM
> To:	[email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> Comments inline...
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  +61 3 9690 8877
> Fax +61 3 9690 8171
> 
> 
> 
> > -----Original Message-----
> > From:	Tammy Carter [SMTP:[email-masked]]
> > Sent:	Saturday, February 06, 1999 5:20 AM
> > To:	[email-masked]; Bob Jueneman;
> [email-masked];
> > [email-masked]; [email-masked]
> > Subject:	RE: Finding PKIX Servers!
> > 
> > I don't understand.  Several of the people on this list seem to
> believe
> > that the way to find a CA is via some kind of advertisement.
> However,
> > what I don't understand is why?  Bob's suggestion of using the
> certificate
> > to contain information about where to find the CA seems to work AND
> it is
> > more similar to the mechanism that we already have for finding
> revocation
> > information.  
> > 
> 	[Andrew Probert]  I dont propose advertisement.  A structured
> approach is fine.  The proposed method for finding revocation works
> for some
> of the simple scenarios, but ..
> 
> > Why do we want to come up with something different?  Is there
> something
> > wrong with what we already have?  This debate must have been waged
> before,
> > and must have been lost.  Has something changed in the world since
> then?
> > 
> 	[Andrew Probert]  The Pasadena Ladies Club scenario doesn't work
> under one scenario!   Is it acceptable to re-issue all certficates if
> one
> changes revocation servers, bureaus etc?  
> 
> 	It is acceptable to have revocation servers rely on DNS/URL
> resolving name-> IP address.  What are the implications of
> vulnerability to
> DNS?
> 
> 	To go with the current scenario ...
> 
> 	*  If I am a CA, am I better off coding
> ocsp://123.123.123.123:pppp/parms in certs, as a hardcoded IP
> reference to
> my revocation server with a hardcoded 'port', as a way of proofing my
> customers against a denial of service attack on their nearest DNS
> server
> (with a cheaper-net ISP whom I hardly trust)?  
> 
> 	*  If I do this and then I need to I change my IP addressing
> scheme,
> I've got to recall all certs and re-issue!
> 
> 	*  What if I have the newest / next generation revocation server
> that has just been lobbed in as Draft-xx, which solves lots of CRL
> problems
> I discovered in the last month or two, but its a totally new protocol
> and I
> want to turn it on.  Do I reissue certs for this, or wait a year for
> them to
> expire!
> 
> 	In my view a Naming Service helps the network, devices and apps
> configure themselves.  It needs to be a stable service that is not
> changing
> too much.  They don't need to be accessed all of the time, for example
> local
> workstations can cache what the know (rules are needed of course).
> 
> 
	A naming service for domain names - to IP addresses is fine for
network - server configurations and servers are organised in domains.

	A directory approach is that real world entities such as ships,
bus ticket machines, mobile phones that are represented by a named
objects in a directory service will interact with real life entities
that are represented in the directory service that have certificate
responsibility. eg a country entry, an organisation entry, and
organisational unit, a device, a role, a person, a kiosk, etc.

	It is not true that all certficates will need to have a url
placed in them when they work in a business domain that is supported by
directory services.

	The difference in opinion is that:

	a) DNS can be tweaked for PKI servers and that certificates can
hold this information. In this case what protects DNS how does it do
distributed mutual authentication - and how on earth do we relate such
"connectivity" with which entity in the real world (as represented by
information) that these PKI servers relate to.
	Do the PKIX servers need a directory service anyway??????

	b) We can use a directory service as is - as designed and as
being deployed.

	In all this debate I have only seen the argument about how do we
"find a server" - and the answer is a URL in the certificate. Can anyone
tell me how the information sets that relate the certificate user and
the CAs that deal with it and the service domains their in.

	I can do all this very well with a directory approach to life.

	All I can do with a URL approach to life is connect to a client
with a cert to server. I suppose after this debate we will all end up
with:
	Directory Enabled PKIX servers.

	regards alan 

> > Tammy Green Carter
> > [email-masked]
> > 

To: Andrew Probert <[email-masked]>
Cc: [email-masked]
Subject: Re: Finding PKIX Servers!
Reply-To: [email-masked]
From: "Perry E. Metzger" <[email-masked]>
Date: 07 Feb 1999 20:41:59 -0500
Lines: 80
Sender: [email-masked]

Andrew Probert <[email-masked]> writes:
> > This sort of claim shows up all the time among people who haven't
> > actually analyzed the real needs of real businesses. The truth of the
> > matter is that no global PKI is either needed or desirable.
> > 
> 	[Andrew Probert]  Real businesses pay me real $$ to analyse and
> develop PKI systems, 

Thank you, we all have banking industry clients and
credentials. Arguing based on them isn't useful.

> > When people trade, they don't care about identities. They care about
> > things like getting paid. 
> 	[Andrew Probert]  .. and if they dont get paid they care about
> tracking back in an evidence sense to stick it to the identity.

No, actually. They want to get paid. Once they've been ripped off
they're screwed. The big cost in commerce is paying for fails. When
you have a fail, human time starts getting expended in big chunks, and 
it costs a lot per hour. If you are at the point where you've had a
fail to deliver -- if your system even creates them particularly often 
-- you're already dead.

>  Otherwise
> its written of as a bad debt against a scheme operator.  They also care
> about the validity of an order, the authority of the person to order etc,
> floor limits, per card limits, to constrain risk.

And none of that is revealed by a PKI. The only way to determine most
of it is with online systems.

In his talk "Electronic Commerce needs no PKI" (now given several
times), Win Treese noted that most of what the Global PKIs provide
isn't something the merchants need or want, and has nothing to do with 
the success or failure of electronic commerce deployments. I've heard
similar arguments made by a lot of other people -- enough that I no
longer think I'm crazy for saying this.

> > That means you need a working banking
> > infrastructure, not a PKI. Public key methods can help assure a
> > transacting entity that its bank will pay it if it presents an
> > electronic draft, or to help a transacting entity order the creation
> > of such a payment, but such protocols are necessarily bilateral.
> > 
> 	[Andrew Probert]  Yes I agree a working banking infrstructure is a
> pre-requisite for a public key based system like SET

SET is a dead albatross hanging around Visa's neck. It is not ever
going to be deployed for real. Why are you even bringing it up?

> > To put it another way: when you walk in to the book store to buy a
> > book, the store doesn't care a bit about who you are. They care about
> > whether they will be PAID, and knowing you have a valid cert tells
> > them nothing about that. 
> 	[Andrew Probert]  It tells them, by its IssuerName, who issued it to
> you.

And they don't care about that. They want to know if they are going to 
be paid, and whether First Sillybank or the National Bank of Gnats
issued the card isn't interesting to them. All they want to know is if 
the accepting bank will hand them money, period, and that depends
entirely on interactions that are way past the merchants level of the
transaction. Indeed, even a valid card can be totally overdrawn, so
mere validity is uninteresting.

> loop.  I dont see Certs issued by non-Banks being honoured by banks..
> > What they need is a signed statement from their
> > accepting bank saying they will be paid -- and that doesn't require a
> > Global PKI to set up. 
> 	[Andrew Probert]  Consider SET,

SET is dead.

> 	[Andrew Probert]  Banks dont need global PKI, as they will set up
> their own.  Others do, for lessor things.

Who? For what?

Perry

From: Andrew Probert <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Andrew Probert <[email-masked]>
Cc: [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 12:27:31 +1100 
Sender: [email-masked]

Comments inline

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Perry E. Metzger [SMTP:[email-masked]]
> Sent:	Monday, February 08, 1999 11:36 AM
> To:	Andrew Probert
> Cc:	[email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
> Andrew Probert <[email-masked]> writes:
> > My thoughts run to business requirements like world-wide EDI trading,
> > shipping around contracts and documents, which require an integrated
> global
> > infrastructure.
> 
> No it doesn't. In fact, a global infrastructure is totally unneeded
> for this.
> 
> This sort of claim shows up all the time among people who haven't
> actually analyzed the real needs of real businesses. The truth of the
> matter is that no global PKI is either needed or desirable.
> 
	[Andrew Probert]  Real businesses pay me real $$ to analyse and
develop PKI systems, I have personally been involved in establishing EFT and
banking infrastructre.  So please dont make assumptions about my reality!
Others I know also get paid to analyse and their reality appears the same as
mine.

> When people trade, they don't care about identities. They care about
> things like getting paid. 
	[Andrew Probert]  .. and if they dont get paid they care about
tracking back in an evidence sense to stick it to the identity.  Otherwise
its written of as a bad debt against a scheme operator.  They also care
about the validity of an order, the authority of the person to order etc,
floor limits, per card limits, to constrain risk.
> That means you need a working banking
> infrastructure, not a PKI. Public key methods can help assure a
> transacting entity that its bank will pay it if it presents an
> electronic draft, or to help a transacting entity order the creation
> of such a payment, but such protocols are necessarily bilateral.
> 
	[Andrew Probert]  Yes I agree a working banking infrstructure is a
pre-requisite for a public key based system like SET to actually work and
there's a lot for SET to replace.  EFTPOS device key management, host EFT
switches, a globally interconnected network of EFT switches, the Card
Numbering scheme of EFT that has a card prefix, so that transactions can be
routed to their home EFT switch in whichever country it was Issued.

	All of this to support "ONLINE AUTHORISATION"

> To put it another way: when you walk in to the book store to buy a
> book, the store doesn't care a bit about who you are. They care about
> whether they will be PAID, and knowing you have a valid cert tells
> them nothing about that. 
	[Andrew Probert]  It tells them, by its IssuerName, who issued it to
you.  By inference, you can assume that they signed a subscriber agreement
under the CA policy.  In the case of a bank issuing the cert, its a closed
loop.  I dont see Certs issued by non-Banks being honoured by banks..
> What they need is a signed statement from their
> accepting bank saying they will be paid -- and that doesn't require a
> Global PKI to set up. 
	[Andrew Probert]  Consider SET, it very much does require a global
infrastructure albeit, I agree the banks will do their own thing as regards
PKI.
> It might use a PKI set up by the bank or credit
> network for its own use, but it doesn't need a *GLOBAL* PKI.
> 
	[Andrew Probert]  Banks dont need global PKI, as they will set up
their own.  Others do, for lessor things.

> Perry

To: Andrew Probert <[email-masked]>
Cc: [email-masked]
Subject: Re: Finding PKIX Servers!
Reply-To: [email-masked]
From: "Perry E. Metzger" <[email-masked]>
Date: 07 Feb 1999 19:36:04 -0500
Lines: 30
Sender: [email-masked]

Andrew Probert <[email-masked]> writes:
> My thoughts run to business requirements like world-wide EDI trading,
> shipping around contracts and documents, which require an integrated global
> infrastructure.

No it doesn't. In fact, a global infrastructure is totally unneeded
for this.

This sort of claim shows up all the time among people who haven't
actually analyzed the real needs of real businesses. The truth of the
matter is that no global PKI is either needed or desirable.

When people trade, they don't care about identities. They care about
things like getting paid. That means you need a working banking
infrastructure, not a PKI. Public key methods can help assure a
transacting entity that its bank will pay it if it presents an
electronic draft, or to help a transacting entity order the creation
of such a payment, but such protocols are necessarily bilateral.

To put it another way: when you walk in to the book store to buy a
book, the store doesn't care a bit about who you are. They care about
whether they will be PAID, and knowing you have a valid cert tells
them nothing about that. What they need is a signed statement from their
accepting bank saying they will be paid -- and that doesn't require a
Global PKI to set up. It might use a PKI set up by the bank or credit
network for its own use, but it doesn't need a *GLOBAL* PKI.

Perry

From: Andrew Probert <[email-masked]>
To: [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 11:09:20 +1100 
Sender: [email-masked]

Comments inline...

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Tammy Carter [SMTP:[email-masked]]
> Sent:	Saturday, February 06, 1999 5:20 AM
> To:	[email-masked]; Bob Jueneman; [email-masked];
> [email-masked]; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> I don't understand.  Several of the people on this list seem to believe
> that the way to find a CA is via some kind of advertisement.  However,
> what I don't understand is why?  Bob's suggestion of using the certificate
> to contain information about where to find the CA seems to work AND it is
> more similar to the mechanism that we already have for finding revocation
> information.  
> 
	[Andrew Probert]  I dont propose advertisement.  A structured
approach is fine.  The proposed method for finding revocation works for some
of the simple scenarios, but ..

> Why do we want to come up with something different?  Is there something
> wrong with what we already have?  This debate must have been waged before,
> and must have been lost.  Has something changed in the world since then?
> 
	[Andrew Probert]  The Pasadena Ladies Club scenario doesn't work
under one scenario!   Is it acceptable to re-issue all certficates if one
changes revocation servers, bureaus etc?  

	It is acceptable to have revocation servers rely on DNS/URL
resolving name-> IP address.  What are the implications of vulnerability to
DNS?

	To go with the current scenario ...

	*  If I am a CA, am I better off coding
ocsp://123.123.123.123:pppp/parms in certs, as a hardcoded IP reference to
my revocation server with a hardcoded 'port', as a way of proofing my
customers against a denial of service attack on their nearest DNS server
(with a cheaper-net ISP whom I hardly trust)?  

	*  If I do this and then I need to I change my IP addressing scheme,
I've got to recall all certs and re-issue!

	*  What if I have the newest / next generation revocation server
that has just been lobbed in as Draft-xx, which solves lots of CRL problems
I discovered in the last month or two, but its a totally new protocol and I
want to turn it on.  Do I reissue certs for this, or wait a year for them to
expire!

	In my view a Naming Service helps the network, devices and apps
configure themselves.  It needs to be a stable service that is not changing
too much.  They don't need to be accessed all of the time, for example local
workstations can cache what the know (rules are needed of course).

> Tammy Green Carter
> [email-masked]
> 

From: Andrew Probert <[email-masked]>
To: [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 09:47:55 +1100 
Sender: [email-masked]

Nothing like some heat for a discussion...

We could park the X500 thing as "jumping-to-solutions" and go back to
requirements ...

My thoughts run to business requirements like world-wide EDI trading,
shipping around contracts and documents, which require an integrated global
infrastructure.  I see other commentators requiring disparate, fragmented
pockets of PKIX servers with very loose relationships.  Closed user group
PKI is relatively easy.  Global PKI needs a lot of operational /
administrative thought.

1.  I think there is broad issue "Finding PKIX" servers in a global
interoperable scenario, which needs to be addressed. I personally don't want
hand code lots of browsers and software.  Is the agreed way to find a PKIX
server going to be via URL/DNS reference as an active / informed decision.
Requirements and discussion please?

2.  I have responded to the Pasadena Ladies Club scenario, where coding a
explicit reference into a cert to a bureau may cause an operational issue
forcing re-issuance of all certificates, which hopefully people should admit
is an problem?  This is a clear case where one needs a Naming Service to
provide a level of indirection between what's hardcoded into Certs and what
services can be used to find certs and crls.

3.  Does PKIX need the equivalent of a Naming Service / indirection of some
sort?

Sundry Comments below..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

<SNIP>

> This discussion starts to sound as if it not about PKIX, or even
> directories. The real agenda appears to be resurrecting OSI, or at the
> very least attempting to promote the version of history in which OSI
> failed for purely political reasons.
> 
	[Andrew Probert]  Sorry this is not the OSI debate again.  This is
about using approaches that are being adopted by major industry players as
we speak.  You could take a look at the planets biggest router manufacture,
CISCO, to see they are building Directory Enabled Networking (DEN) which is
certficate enabled.  You could take a look at Microsoft to find Active
Directory as a core part of their architecture.  You could take a look at
Sun's JDNI to see the Java view.  This is part of the industry 2 - 5 year
view of what the majors are doing.
	<SNIP>

> You do not just need a port on any old directory service, it has to be 
> a global NAME service with naming consistency. Furthermore to be usefull 
> in the proposed application it has to tie to the numbering infrastructure 
> of the Internet.
> 
	[Andrew Probert]  Wrong, the IssuerDistinguishedName of X.509 is
there in the certificate to be used for what it is, a globally unique Name
with registration authorities supporting country by country issuing of
names.  Is it going to be used for what it was designed?

	With regard to tying to the Numbering System, there are multiples of
numbering systems, the Internet, ISDN, NETBIOS, Phone Messaging (SMS) etc.
Are these services going to be certificate enabled?

>  X.500 satisfies neither condition. It is a directory and NOT, repeat NOT
> a name sytem at this point. X.500 was originally intended to provide a
> name service but grew into something different.
> 
	[Andrew Probert]  It is still a name service, whether it gets
deployed as a system is up to the requirements..

> Suggesting widespread deployment of X.500/DSP ignores the fact that the
> lower level OSI protocols are an abject failPure at this point. The rate
> of deployment is actually negative at this point. The world does not
> require a directory replication protocol for replication of a name space.
> 
	[Andrew Probert]  Wrong.  
	Today, most products run on IP, whats the relevence of 'lower
levels' in this case?  

	DSP is not replication, it is online realtime routing of queries to
other online realtime servers.  

	Is PKIX going to invent a protocol for server-server communications
for OCSP servers etc etc. $$?

	DISP is replication.  

	The world *may* need replication of a name space to provide local
caching for higher performance and redundancy, if the business requirement
dictates it.

> DNS is widely deployed on a global scale, DST ain't. If it were 
> necessary to redesign DNS I would not consider DST as a substitute.
> There is no evidence that DST is more scalable than DNS and plenty
> of reason to believe it to be less scalable - DNS has the advantage
> of applying highly domain specific optimizations which a general
> purpose directory system cannot. Nor is the approach taken by OSI
> particularly different in structure so as to make me believe it to
> be capable of greater scalability.
> 
	[Andrew Probert]  DNS has very simple information, are its 'design
optimisations' good or bad for PKIX, needs to be discussed?	If the
requirements are discussed, then one can decide whether DNS is an
appropriate vehicle for extension.

	Particularly, if PKIX has requirements that require upgrading of the
planets DNS servers, this could be operationally destabiling and it would be
better to introduce a parallel service!

> The solution to finding PKIX servers is very simple. Write a profile
> which defines what information a 'PKIX server' must provide via a
> specific transport. Advertise a PKIX server providing information 
> corresponding to the xyz.net domain via an SRV record of the form
> __pkix._ldap._tcp.xyz.net.
> 
	[Andrew Probert]  Yep, I agree things like this are a good start to
answering the "Finding PKIX Server" requirement.  Is this simple solution
all we need?

> A directory service is not a name service. Failure to understand
> this was the principle reason for the technical failure of OSI. We
> should not make the same mistake.
> 
	[Andrew Probert]  Citing techical failure of OSI is an incorrect
generalisation and is unsupportable, but I'm actually not an OSI bigot and
I'm not going to clutter this discussion with it..  

	As a pragmatist, bootstraping this to 'a directory service is not a
name service' flies in the face of what CISCO, Microsoft, Sun and others
seem to building directory infstracture for?

> 		Phill

From: Alan Lloyd <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked], Tammy Carter <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Mon, 8 Feb 1999 09:10:36 +1100
Sender: [email-masked]

I am amazed at this- - this is so wrong.

> -----Original Message-----
> From:	Phillip M Hallam-Baker 
> Sent:	Saturday, February 06, 1999 4:42 AM
> To:	Alan Lloyd; 'Bob Jueneman'; [email-masked]; Tammy Carter;
> [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> This discussion starts to sound as if it not about PKIX, or even
> directories. The real agenda appears to be resurrecting OSI, or at the
> very least attempting to promote the version of history in which OSI
> failed for purely political reasons.
> 
	No its not. I wonder why major PKI companies are using directory
services - Please answer this if you want to respond. Because the
majority of out her that are applying directory services to big PKIs
would like a answer.
	Just keep the thought that businesses are using the internet and
providing services on the internet. And at these levels they dont want
"more dedicated servers" and "fragmented information management".

	I think most accept that OSI is a seven layer reference model
that most people use.
	See Cisco wall charts etc.

> This discussion really has nothing to do with the design of PKIX and
> is ultimately counter-productive since many lurkers following the 
> discussion will have recieved a very negative opinion concerning
> X.500 and interpreted this to mean that directories generally are out
> of favour and not as is the case certain (rather eccentric)
> applications
> thereof.
> 
	Well please for the lists sake tell us how you attach
certficates to business entities and identify certificate authorities as
information - in a common scaleable information environment.

> Any chance this discussion can be taken up on [email-masked]?
	Perhaps the reverse is true. Perhaps holding onto the old way
protocol/rdb approach to systems that has existed for 30 years when the
industry wants large scale information services might be a little flat
earth.

> > 	No all one needs is a "port" on a directory service 
> 
> You do not just need a port on any old directory service, it has to be
> 
> a global NAME service with naming consistency. 
	Oh dear. I have a phone - a mobile phone. It has a number, I
wander the world and use a "port" - in the abstract sense - on the
global mobile telephone system. 
	With a directory service - which they may be many of - run for
different service reasons, they manage and service a name space for that
service which is distributed. I have my entry in that directory service
by which it recognises me. And when I connect to that directory service
(via a "port" ) the distributed  authentication processes verify me. (as
per the phone service does) -

> Furthermore to be usefull 
> in the proposed application it has to tie to the numbering
> infrastructure 
> of the Internet.
	Oh dear - WE have our X.500 directory services providing
DNS/DHCP/RADIUS front ends (from a famous supplier) for ISPs  - simply
because the directories permit their service provisioning to scale -
heard that one before! (See DEN)

> X.500 satisfies neither condition. It is a directory and NOT, repeat
> NOT
> a name sytem at this point. X.500 was originally intended to provide a
> name service but grew into something different.
	See above.
	Well its was designed as a name based directory service - read
X.500 1988 and look at the standard schema
	Its best to read the standards before making such comments.

> Suggesting widespread deployment of X.500/DSP ignores the fact that
> the
> lower level OSI protocols are an abject failPure at this point. The
> rate
> of deployment is actually negative at this point. The world does not
> require a directory replication protocol for replication of a name
> space.
	I think OSI is a reference model in which protocols are
positioned. eg 802.x, HDLC, etc
	TCP - happens to be Transport Layer - IP is Networking Layer

> DNS is widely deployed on a global scale, DST ain't.
	Whats DST?
>  If it were 
> necessary to redesign DNS I would not consider DST as a substitute.
> There is no evidence that DST is more scalable than DNS and plenty
> of reason to believe it to be less scalable - DNS has the advantage
> of applying highly domain specific optimizations which a general
> purpose directory system cannot. Nor is the approach taken by OSI
> particularly different in structure so as to make me believe it to
> be capable of greater scalability.
> 
	There is a major difference between a name to IP service - and a
directory system that does mutual authentication, has information
doctrine to the extent it has - a  common information management model,
the replication and distribution, the access control regimes...and deals
with business level information systems etc, etc..

> The solution to finding PKIX servers is very simple. Write a profile
> which defines what information a 'PKIX server' must provide via a
> specific transport. Advertise a PKIX server providing information 
> corresponding to the xyz.net domain via an SRV record of the form
> __pkix._ldap._tcp.xyz.net.
> 
	Thats one way - and its a much lower level perspective of the
knowledge issue about large scale PKI systems. ie.  It does not add PKI
related information and their functional aspects to real life entities
(as represented in a business level directory service by information
objects)

> A directory service is not a name service. 
	Oh dear - a directory service relies on information being
organised by name - and interactions on such information is through the
use of system knowledge of that name space.

	A directory - a service that organises information by name so
that names can be related to information.

> Failure to understand
> this was the principle reason for the technical failure of OSI. We
> should not make the same mistake.
> 
	It is very obvious the biggest mistake ever made was considering
that X.509 formats would make a scaleable service without a directory
system. I never understood this view. If one reads X.500 on total and
the part X.509 which relies on the functionality and process of mutual
authentication through a distributed name based directory system - How
could one ever expect it (the format of 509) to work on its own.

	Thats like taking the wheel off a car and then expecting to
drive the wheel to work. :-)

> 		Phill

From: "Enrico G. Mancini" <[email-masked]>
Date: Sun, 7 Feb 1999 14:06:02 +0100
To: IETF-Announce:, ;
Subject: I-D ACTION:draft-ietf-pkix-qc-00.txt
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

--Part9902071406.J
Content-Type: Text/PLAIN; CHARSET="us-ascii"
Content-Disposition: attachment

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Internet X.509 Public Key Infrastructure 
                          Qualified Certificates
	Author(s)	: S. Santesson, W. Polk, P. Gloeckner
	Filename	: draft-ietf-pkix-qc-00.txt
	Pages		: 20
	Date		: 04-Feb-99
	
   This Internet-Draft forms a certificate profile for Qualified
   Certificates, based on RFC 2459, for use in the Internet. In this
   document the term Qualified Certificate is used to describe a
   certificate which is aimed to support digital signatures in a context
   which is considered functionally equivalent to the use of handwritten
   signatures.

   This is the first official PKIX WG draft; two unofficial drafts
   labeled <draft-ietf-santesson-qc-0x.txt> were previously distributed
   on the list for comments.

   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
   'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
   document are to be interpreted as described in RFC 2119.

   Please send comments on this document to the [email-masked] mail
   list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-qc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-qc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Part9902071406.J
Content-Type: Multipart/ALTERNATIVE; BOUNDARY="Part9902071406.K"

--Part9902071406.K
Content-Type: Message/EXTERNAL-BODY; SERVER="[email-masked]"; ACCESS-TYPE="mail-server"
Content-Disposition: attachment

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-qc-00.txt

--Part9902071406.K
Content-Type: Message/EXTERNAL-BODY; DIRECTORY="internet-drafts"; ACCESS-TYPE="anon-ftp"; SITE="ftp.ietf.org"; NAME="draft-ietf-pkix-qc-00.txt"
Content-Disposition: attachment; filename="draft-ietf-pkix-qc-00.txt"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Part9902071406.K--

--Part9902071406.J--

Date: Sat, 06 Feb 1999 16:05:44 +0300
From: Krylov Pavel <[email-masked]>
To: [email-masked]
Subject: Authority Key Id.
Sender: [email-masked]

Hi all!
I read about Authority Key Id. and found some strange things.
How I know, certificate is distinguishable from all others certificates
by couple { IssuerCA, SerialNumber }. But Authority Key Id. ( AKId ) 
contains authorityCertSerialNumber! Does it mean that I can separate CA 
certificate by couple {Issuer[of current end-user cert] + AltIssuerName,
SerialNumber(from AKId)} ? 

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

How I understand it's wrong. Example:

CA1 { SN1, Issuer1, Issuer1, .. }       CA2 {SN2, Issuer2, Issuer2, ..}
		|					|
		|					|
		|					|
CA3:		V					V
	{ SN0, Issuer1, Subject3, .. }  {SN0, Issuer2, Subject3, .. }
				|
				|
				|
end-user			V
cert:		{ SN123, Issuer3, Subject123, ..., AKId{[2] SN0}}

How can end-user software understand which certificate is needed?
or Is authorityCertSerialNumber support field?

And another questions:
	Certificate contains IssuerName and Alt.IssuerName. Well
	then, for what purposes does AKId contain authorityCertIssuer?
	Is it alias name for IssuerCA? or Does it match with 
	{ IssuerName, Alt.IssuerName }?

What did I misunderstand?
Thanks a lot.

___________________________________________
Pavel Krylov 	[email-masked]

Date: Fri, 05 Feb 1999 11:20:11 -0700
From: "Tammy Carter" <[email-masked]>
To: <[email-masked]>, "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Sender: [email-masked]

I don't understand.  Several of the people on this list seem to believe that the way to find a CA is via some kind of advertisement.  However, what I don't understand is why?  Bob's suggestion of using the certificate to contain information about where to find the CA seems to work AND it is more similar to the mechanism that we already have for finding revocation information.  

Why do we want to come up with something different?  Is there something wrong with what we already have?  This debate must have been waged before, and must have been lost.  Has something changed in the world since then?

Tammy Green Carter
[email-masked]

Date: Fri, 05 Feb 1999 11:08:09 -0700
From: "Tammy Carter" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

Steve,

>>>> Stephen Kent <[email-masked]> 2-4-99 4:26:10 PM >>>
>Tammy,
>
>>Generally speaking, information which is stored in a directory is
>>accessible only to those people who are granted explicit access rights.
>>And, by default, only the user would be given rights to his encrypted
>>private key stored on his own object.  Thus, the user would have to
>>specifically gave someone else rights to access his private key.
>
>This assumes that the directory access controls are not violated, e.g., via
>subversion of the underlying OS or as a result of a management error.
>Experinece suggests that such assumtpions are generally unwarranted.

Point taken.  There are additional threats other than physical access to the servers.

>>However, those administrators with direct access to the directory database
>>wherein my object resides could give themselves rights to my private key.
>>Or copy it for an off-line attack on the encryption.  Or even change it.
>>When my encrypted private key is stored in the directory, it is vulnerable
>>to anyone who can get to a server which holds a copy of my object.  As we
>>are fond of saying here - - Once someone has physical access to the
>>server, all bets are off.
>
>Which is a good reason to not take such chances.
>
>>BUT....  That's true about any information which is stored in a directory.
>>Not just about my private key.  From a company's perspective, there are
>>far worse things that someone can do with physical access to a server than
>>to pose as one of their employees.  So, a company would (hopefully) screen
>>people a bit before giving them the keys to the kingdom.
>
>The most sensitive data is unlikley to be stored in a directory, but is may
>be stored in various file or web servers, access to which can be effected
>once one has acquired the private keys of authorized users. So, which it is
>true that a company is concerned about the sensitivity of the data stored
>in a directory, I doubt that this data is the most sensitive data in the
>company.

Again, point taken.  I have been thinking about this from a more Novell-centric point of view.  NDS tries, sometimes more successfully than others, to unify the directory and the file system.  Many other directories, however, do _not_ contain file system information and the access controls for one have no relation to the access controls of the other.  The risks for storing private keys in those types of directories seem much higher.  In such scenarios, perhaps smart cards are the only answer.

>Again, one has to answer these questions in the context of a percieved
>threat.  Absent a threat model, one cannot evaluate alternatives
>meaningfully.  What worried me about what you described is the notion of
>encrypting these keys with keys that are accessible to other than the user.
>I suggest that there is a reasonable body of literature providing various
>ways of protecting personal keys stored outside of my computing environment
>without accepting the risks that seem to accrue from this approach.

I understand your worry and agree.  The classic method to use in protecting the private keys is a password.  In that way the security of the private key lies with the user and what kind of passwords are chosen.  (Well, it also lies with the company maintaining the directory in terms of how well they protect the database.  An attacker with access to the database could do off-line attacks on the encrypted private keys.)  In our environment, however, the benefits of password protection do not outweight the inconvience of making the user remember yet another password.  But, as our users become more savvy, it would certainly make a nice enhancement.

Tammy Green Carter
[email-masked] 

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Alan Lloyd" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, <[email-masked]>, "Tammy Carter" <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Fri, 5 Feb 1999 12:41:45 -0500
Importance: Normal
Sender: [email-masked]

This discussion starts to sound as if it not about PKIX, or even
directories. The real agenda appears to be resurrecting OSI, or at the
very least attempting to promote the version of history in which OSI
failed for purely political reasons.

This discussion really has nothing to do with the design of PKIX and
is ultimately counter-productive since many lurkers following the 
discussion will have recieved a very negative opinion concerning
X.500 and interpreted this to mean that directories generally are out
of favour and not as is the case certain (rather eccentric) applications
thereof.

Any chance this discussion can be taken up on [email-masked]?

> 	No all one needs is a "port" on a directory service 

You do not just need a port on any old directory service, it has to be 
a global NAME service with naming consistency. Furthermore to be usefull 
in the proposed application it has to tie to the numbering infrastructure 
of the Internet.

X.500 satisfies neither condition. It is a directory and NOT, repeat NOT
a name sytem at this point. X.500 was originally intended to provide a
name service but grew into something different.

Suggesting widespread deployment of X.500/DSP ignores the fact that the
lower level OSI protocols are an abject failPure at this point. The rate
of deployment is actually negative at this point. The world does not
require a directory replication protocol for replication of a name space.

DNS is widely deployed on a global scale, DST ain't. If it were 
necessary to redesign DNS I would not consider DST as a substitute.
There is no evidence that DST is more scalable than DNS and plenty
of reason to believe it to be less scalable - DNS has the advantage
of applying highly domain specific optimizations which a general
purpose directory system cannot. Nor is the approach taken by OSI
particularly different in structure so as to make me believe it to
be capable of greater scalability.

The solution to finding PKIX servers is very simple. Write a profile
which defines what information a 'PKIX server' must provide via a
specific transport. Advertise a PKIX server providing information 
corresponding to the xyz.net domain via an SRV record of the form
__pkix._ldap._tcp.xyz.net.

A directory service is not a name service. Failure to understand
this was the principle reason for the technical failure of OSI. We
should not make the same mistake.

		Phill

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-qc-00.txt
Date: Fri, 05 Feb 1999 10:24:44 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Internet X.509 Public Key Infrastructure 
                          Qualified Certificates
	Author(s)	: S. Santesson, W. Polk, P. Gloeckner
	Filename	: draft-ietf-pkix-qc-00.txt
	Pages		: 20
	Date		: 04-Feb-99
	
   This Internet-Draft forms a certificate profile for Qualified
   Certificates, based on RFC 2459, for use in the Internet. In this
   document the term Qualified Certificate is used to describe a
   certificate which is aimed to support digital signatures in a context
   which is considered functionally equivalent to the use of handwritten
   signatures.

   This is the first official PKIX WG draft; two unofficial drafts
   labeled <draft-ietf-santesson-qc-0x.txt> were previously distributed
   on the list for comments.

   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
   'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
   document are to be interpreted as described in RFC 2119.

   Please send comments on this document to the [email-masked] mail
   list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-qc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-qc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-qc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-qc-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 05 Feb 1999 14:33:47 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: Al Arsenault <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: POP section for next Roadmap draft
Sender: [email-masked]

Juergen,

Sorry for the delay. I have had difficulties to find some time available this week.

> Denis,
>
> I agree essentially with Al´s position. I would like to add some
> comments.
>
> For non-repudiation key usage the CA must ensure that the public key is
> UNIQUE.

I do not believe so. Even if this would be the case, all the CAs of the world would
not be bale to interconnect to verify this.

> Even if the signed data includes a cert identifier the threat
> described by Al remains unsolved.

You would have to be more precise.

> Substitution of certs is a minor
> problem (the cert identifier encapsulation has solved the problem as you
> wrote, i. e. "new" mechanism). The major problem is key uniqueness. Even
> the "new" mechanism needs POP.
>
> If CAs do not POP prior to certification then they probably allow that
> two end entities share the same signature key.

If they really share the same key, then POP can be made by each entity and will not
prevent the scenario to happen. If they don't then only one (or no one) has the
corresponding private key.

> This may be approriate in
> certain circumstances, but this is definitely not appropriate in
> non-repudiation framework. The other certificate applications may be
> restricted according to their usage (see Al´s key management example).
>
> I would like to use Al´s signature key example where Alice and Mal are
> involved. If I have understood correctly, a CA which does not POP may
> issue two certificates with different subject identifiers (e. g.
> distinguished names) and one identical public key. So, Alice may include
> Mal´s identifier and sign the transaction. In the following the dispute
> arises when Mal repudiated the transaction. Alice then repudiates the
> possession of private key as well. Who is responsible for the
> transaction? Mal?! What is about the case when there exist more than one
> Mal (i. e. more than two certificates with identical public key and
> different identities)?! What do you answer provided that Mal says,
> sorry, it had been a joke? Is your agreement with Mal legally approved
> for such cases?

If someone manages to get a certificate containing a public key for which someone
else has the corresponding private key, then that entity has to be aware of problems
that may occur. It is up to the entity to assume the possible consequences, but the
CA does not have to be responsible.

> Furthermore, if a person signs a document with its private key in a
> non-repudiation framework, then it has accepted the information content.
> When a CA signs the PRETENDED subject public key, then it has probably
> accepted false information. One basic function of a CA is key
> registration. But, if CAs does not verify POP, then the key is not
> well-registered.

No, the CA can testify that this user wanted that public key in his certificate.

> So, the CA does not warrant for information contained
> in the issued certificate. Why a relying party should trust such CAs? A
> new certificate extension "CA has done POP" is a very bad idea (see next
> para).
>
> I think that the mechanism called "new" without POP is essentially an
> attribute certification. The PRETENDED subject public key is then one of
> the certified attributes. The attribute certificate binds the PRETENDED
> subject public key to the end entity´s distinguished name and other
> attributes if appropriate. May be, I have overseen somewhat, but your
> solution is essentially a X.509 attribute certificate.

It can be used in the case where attributes are in the certificate, but this is not
the essential point. The signer has always to include a reference of its certificate
and to protect it under its signature.

> Summarizing, POP is a key registration matter. At least the
> non-repudiation framework REQUIRES POP.

No. POP is made at the protocol level (by signing the certificate identifier),
rather than the registration phase.

> POP SHOULD be done prior to
> certification (personally, I prefer MUST). Alternatively, a CA MAY
> ensure the uniqueness of the registered public keys.

There is no reason for this argument.

> If a CA receives a
> public key that has not been certified yet for another entity, then it
> MAY drop POP (for the moment?).

????

> Those CAs that do this MUST reject a
> registration request, that contains a public key always certified for a
> different entity. When this registration request includes a POP and its
> verification was succesful, the corresponding certificate MUST be
> revoked immediately.

I do not follow you.

> When entities use signature keys before they are certified by a CA or
> other inappropriate key usage is another outstanding (?) key management
> problem. Especially, in those cases where key pairs are generated by end
> entities themselves.
>
> Key sharing is not covered by the comments above. One may replace
> entities by groups of entities where separation within the same group is
> not desirable or is provided by additional certs, respectively. POP must
> then be done by ALL entities who share a certain key.

I do not share your various conclusions.

Regards,

Denis

> Juergen
>
> Denis Pinkas wrote:
> >
> > Al,
> >
> > This is nice to send that section, otherwise I would not have taken a look at
> > the road map :-(
> >
> > >  Folks,
> > >
> > > Sean and I are working on the next draft of the PKIX Roadmap.  One of the
> > > things that has to be done is filling in the Proof of Possession section
> > > (section 5.2 in draft -00).  Attached is a first cut at text for that
> > > section.  Any strong comments one way or the other on this?
> > >
> >
> > Oh ! yes. I have strong opinions on this topic.
> >
> > >      POP
> > >
> > > Proof of Possession, or POP, means that the CA is adequately convinced that
> > > the entity requesting a certificate containing a public key Y has access to
> > > the private key X corresponding to that public key.
> > >
> > > POP is important because it provides an appropriate level of assurance in
> > > the correct operation of the PKI as a whole.  There are those who dismiss
> > > POP as unimportant because the most direct threat it counters is the
> > > “self-inflicted denial of service”; that is, an entity voluntarily gets a
> > > certificate that cannot be used to sign or encrypt/decrypt information.
> >
> > Up to here the text is fine.
> >
> > There are three types of keys, each one being indicated with a different key
> > usage. Whether POP or is not required depends on the key usage. The three main
> > key usages for leaf certificates are: non repudiation, data encryption and ...
> > all others in particular authentication.
> >
> > The case for signing key below does not match with this separation and
> > therefor is not adequate. You have to separate authentication from non
> > repudiation. You also have to consider "old" mechanisms (which contain
> > "errors") which mandate POP and "new" (error free) mechnisms which do not
> > mandate POP.
> >
> > Because some people wanted to use PKIX in any context they wanted to mandate
> > POP. As soon as you use it with "new" mechanism POP is no more always needed
> > (see below).
> >
> > The example you provide below is an example with an "old" mechanism. The bad
> > side is that many people could infer from the text that POP is always needed
> > whereas this is not true.
> >
> > > However, as the following two examples demonstrate, the true threat
> > > countered by POP is less direct, but more important:
> > >
> > >      POP for signing keys:  it is important to provide POP for keys used to
> > >      sign material, in order to provide authentication and possibly
> > >      non-repudiation of transactions.  For example, suppose Alice
> > >      legitimately has private key X and its corresponding public key Y.
> > >      Alice has a certificate from Charlie, a CA, containing Y.  Alice uses X
> > >      to sign a transaction T.  Without POP, Mal could also get a certificate
> > >      from Charlie containing the same public key, Y.  Now, there are two
> > >      possible threats:  Mal could claim to have been the real signer of T;
> > >      or Alice can falsely deny signing T, claiming that it was instead Mal.
> > >      Since no one can reliably prove that Mal did or did not ever possess X,
> > >      neither of these claims can be refuted, and thus the service provided
> > >      by and the confidence in the PKI has been defeated.  (Of course, if Mal
> > >      really did possess X, Alice’s private key, then no POP mechanism in the
> > >      world will help, but that is a different problem.)
> > >
> >
> > The simple solution to the problem is to include an identifier of the
> > certificate in the signed data. In this way the substitution is no more
> > possible. What you have provided is an example of an "old" mechanism whereas
> > my example would be refered as a "new" mechanism.
> >
> > As far as authentication is concerned some "old" mechanisms cannot be changed
> > to include the certificate identifier. For non repudiation it is mandatory to
> > include it, not only because of the substitution with a certificate from
> > someone else but because the same signer may use different certificates all
> > containing the same public key but including different security attributes (in
> > an extension).
> >
> > >
> > >      POP for key management keys:  Similarly, POP for key management keys
> > >      (that is, keys used for either key agreement or key exchange) can help
> > >      to prevent undermining confidence in the PKI.  Suppose that Al is a new
> > >      instructor in the Computer Science Department of a local University.
> > >      Al has created a draft final exam for the Introduction to Networking
> > >      course he is teaching.  He wants to send a copy of the draft final to
> > >      Dorothy, the Department Head, for her review prior to giving the exam.
> > >      This exam will of course be encrypted, as several students have access
> > >      to the computer system.  However, a quick search of the certificate
> > >      repository turns up the fact that several students have certificates
> > >      containing the same public key management key as Dorothy.  At this
> > >      point, if no POP has been done by the CA, Al has no way of knowing
> > >      whether all of the students have simply created these certificates
> > >      without knowing the corresponding private key (and thus it is safe to
> > >      send the encrypted exam to Dorothy), or whether the students have
> > >      somehow acquired Dorothy’s private key (and thus it is certainly not
> > >      safe to send the exam).  Thus, the service to be provided by the PKI -
> > >      allowing users to communicate with one another, with confidence in who
> > >      can read their communications - has been totally defeated. If the CA is
> > >      providing POP, then either no students will have such certificates, or
> > >      Al can know with certainty that the students do indeed know Dorothy’s
> > >      private key, and act accordingly.
> > >
> >
> > I am not convinced by this example. Alice Dorothy will be able to decrypt the
> > document. If the key was indeed compromised, Dorothy would have reported it
> > (and any way POP would not have helped, since all others were indeed knowing
> > the key ansd would have get their certificate by exercising POP !).
> >
> > > CMP requires that POP be provided for all keys, either through on-line or
> > > out-of-band means.
> >
> > This may be necessary in some cases, however it is not only always necessary.
> > A conservative measure is to mandate it but I do not think this is
> > appropriate. For authentication if the mechanism is designed very fast and no
> > protection is taken, then POP is necessary. This is true for both signing keys
> > and (I guess) encryption keys. When a message is encrypted so that only the
> > intended recipient may decipher it, POP is not needed.
> >
> > For non repudiation, since some protection is always needed at the protocol
> > level, POP is NOT needed.
> >
> > You may have (re-)opened a new long thread on that topic. Anyway thanks for
> > trying to clarify this issue.
> >
> > If I had the time I would have propose a new text. However, I thought it was
> > better to provide explanations first at that stage.
> > You may "canibalize" my rational and re-use it in a new text if you wish.
> >
> > Denis
> >
> > > There are any number of ways to provide POP, and the choice of which to use
> > > is a local matter.  Additionally, a certificate requester can provide POP to
> > > either a CA or to an RA, if the RA can adequately assure the CA that POP has
> > > been performed.  Some of the acceptable ways to provide POP include:
> > >
> > > POP by Out-of-band means:
> > >
> > >      For keys generated by the CA or an RA (e.g., on a token such as a smart
> > >      card or PCMCIA card), possession of the token can provide adequate
> > >      proof of possession of the private key.
> > >
> > >      For user-generated keys, another approach can be used in environments
> > >      where “key recovery” requirements force the requester to provide a copy
> > >      of the private key to the CA or an RA.  In this case, the CA will not
> > >      issue the requested certificate until such time as the requester has
> > >      provided the private key.  This approach is in general not recommended,
> > >      as it is extremely risky (e.g., the system designers need to figure out
> > >      a way to protect the private keys from compromise while they are being
> > >      sent to the CA/RA/other authority, and how to protect them there), but
> > >      it can be used.
> > >
> > >
> > > POP by On-line means:
> > >
> > >      For signature keys that are generated by an end-entity, the requester
> > >      of a certificate can be required to sign some piece of data (typically,
> > >      the certificate request itself) using the private key.  The CA will
> > >      then use the requested public key to verify the signature.  If the
> > >      signature verification works, the CA can safely conclude that the
> > >      requester had access to the private key.  If the signature verification
> > >      process fails, the CA can conclude that the requester did not have
> > >      access to the correct private key, and reject the request.
> > >
> > >      For key management keys that are generated by the requester, the CA can
> > >      send use the requested public key, along with the CA’s own private key,
> > >      to encrypt some piece of data, and send it to the requester to be
> > >      decrypted.  For example, the CA can generate some random challenge, and
> > >      require some action to be taken after decryption (e.g., “decrypt this
> > >      encrypted random number and send it back to me”).  If the requester
> > >      does not take the requested action, the CA concludes that the requester
> > >      did not possess the private key, and the certificate is not issued.
> > >
> > >      Another method of providing POP for key management keys is for the CA
> > >      to generate the requested certificate, and then send it to the
> > >      requester in encrypted form.  If the requester does not have access to
> > >      the appropriate private key, the requester cannot decrypt the
> > >      certificate, and thus cannot use it. After some period of time in which
> > >      the certificate is not used, the CA will revoke the certificate.  (This
> > >      only works if the certificate is not made available to any untrusted
> > >      entities until after the requester has successfully decrypted it.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Al Arsenault
> > >
> > > -- these are my opinions only. They do not necessarily reflect the
> > > opinions of my employer, or of any other organization with which I have a
> > > relationship.

Reply-To: "Shantanu Bhattacharya" <[email-masked]>
From: "Shantanu Bhattacharya" <[email-masked]>
To: <[email-masked]>
Date: Fri, 5 Feb 1999 14:49:41 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00C7_01BE5116.C2C87500
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe

------=_NextPart_000_00C7_01BE5116.C2C87500
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>subscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_00C7_01BE5116.C2C87500--

From: Alan Lloyd <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Andrew Probert <[email-masked]>
Cc: "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: FW: Attribute used to store cached certificate chains?
Date: Fri, 5 Feb 1999 14:54:23 +1100
Sender: [email-masked]

Comments in line

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Friday, February 05, 1999 4:57 AM
> To:	Andrew Probert
> Cc:	'Alan Lloyd'; 'Bob Jueneman'; [email-masked]; [email-masked];
> [email-masked]
> Subject:	RE: FW: Attribute used to store cached certificate
> chains?
> 
> andrew,
> 
> >I think a re-statement and perhaps some may think oversimplification
> of the
> >case is as follows: -
> >
> >CRLs are a batch method for publishing CRLs and we are agreed that an
> online
> >realtime mechanism is required.
> >A client navigating to a single OCSP server looks ok.
> >When there are myriad of OCSP servers, the job becomes far more
> complex.
> >A rationalisation of this is to have a single OCSP server that via
> backend
> >protocols talks to other OCSP servers on the users behalf.
> 
> I can put the name of one OCSP server into a cert and have many
> instances
> of that server available, for reliability.  
	But this means that the OCSP servers need to share the same data
and information sets ie replication is needed > In addition OCSP servers
may wish to do contextual/policy verification - based on locality/value
transaction originator.
	So I think there is a bit more to it than saying a URL to
multiple OCSP servers is OK. Before one says that we need to understand
contexts, policies and information management issues.

> We do this with web servers
> quite well today, 
	These are much simpler that cert validation in a business
transaction context.

> so this is not an unsolvable problem.  Also, having lots
> of OCSP servers is not intrinsically a problem; the problem you cite
> seems
> to arise only when a given cert might be checked by many independent
> servers.  I've not seen compelling arguments suggesting why such an
> arrangement is needed.
> 
	I have a few views about this.

	regards alan
> Steve

From: Alan Lloyd <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Alan Lloyd <[email-masked]>
Cc: [email-masked]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Fri, 5 Feb 1999 14:22:19 +1100
Sender: [email-masked]

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Friday, February 05, 1999 10:14 AM
> To:	Alan Lloyd
> Cc:	[email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> 
>  <deleted text from my point #1>
> 
> >	I got confused with your logic in this  debate  - are you
> >agreeing with me.
> 
> Not at all, and I don't think the argument was unclear.
> 
> >	If you want to talk threat to large scale systems I will. And
> >yes all threats to systems are generally operational ones (cutting
> >cables, power, sand in the fuel line etc.)
> 
> First, a threat is defined as a motivated, capable adversary" so the
> use of
> the term "threat" here is inappprpriate.  
	Groan...

> Second, we have simple
> counterexamples to your assertion, e.g., the massive, distributed
> switch
> failure suffered by AT&T due to a propogated software error.  Benign
> failures for such systems may often be of the "backhoe induced fading"
> variety, but malicious attacks need not follow the same profile.
	No doubt there are millions of examples ...

> >	In military we have a term - a big system is a big target. Eg.
> >the Internet, the Telephone network... However, that does not stop
> them
> >being built. So we tend to follow through threat analysis with risk
> >assessment, risk avoidance and risk acceptance. After all, even
> living
> >is a risk :-).
> 
> Yes, but some of us are better at risk avoidance than others :-).
> However,
> smart designers try to avoid creating unnecessary risks in systems
> through
> over concentration.
	As per the subject line - smart designers of eg transport
systems actually buy the cars, the ships and planes - they invet the
transport system , they dont keep inventing core technologies when they
are already there. eg If one wants to find some thing and a directory
service can provide that - one should not handconfigure every
certificate on the planet with server config info....

> >	To debate signed data as being the preferred paradigm and saying
> >putting that in a secure or insecure large scale repository ( a
> >directory service)creates an operational risk - (which is obvious) so
> >dont build one... seems a pointless statement. For the
> cryptographically
> >protected information to have any UTILITY AT ALL in a large scale
> >system,   it has to be provided by something in a way that can be
> found
> >by those distributed users who wish to use it.
> 
> Now it's my turn to question the logic of your statements. Please
> stick to
> responding to specific points, not issuing general, fluffly
> pronouncements.
	But I like fluffy things :-)

> >	Also note  and please do note that a directory is a distributed
> >information function - that provides greater utility than
> conventional
> >databases. One of these can be used in a Top secret env, many can be
> >used privately on a restricted network or thousands can be used on
> low
> >value, high volume transaction , global service systems. The
> >trust/cost/risk/integrity and threat issues of these  are all
> >operational/project/deployment issues.. and have very little to do
> with
> >with the details of a signed cert or cRL (although they do factor in
> the
> >debate).
> >	ie do I use Type 1 algorithms to sign certs but leave the power
> >switch for the CA visible on the road side.
> 
> Oh please, no more "directories as panacea" rhetoric.
	Well it seem I seem to make these announcements because the
debate is still that we need to find things  - so therefore we must
configure everything with knowledge and use all sorts of protocols -
However,  all this effort can be saved by using a directory service as
per its design of 10 years ago.

> <deleted text of my point #2>
> 
> >	See conmments above. Again the logic confuses me. I will always
> >agree that one can build a small system without an infrastructure.
> :-)
> >In fact a small system is not an infrastructure :-))) ... One can put
> a
> >dozen OCSP servers around a CA - not a problem.
> >	However if one want to run a business level system with
> >tranactions and users that are verified for business products/ access
> >with profiles  for global use- what is the information model,
> who/what
> >administers it, how is it distributed and deployed, what is the
> >busines's product, customer and inter-oganisation acquisition
> strategy
> >and what are the information policies and procedures that deal with
> >that....These are the system issues..
> >
> >	Where does this "information" stuff live - in a commercially
> >optimised way....
> >
> >	Big systems are infrastructure, by definition. And threats are
> >always on them. This does not mean that because of theoretical
> ideology
> >we will always build small ones. PKI systems and directories means
> that
> >infrastructure, large scale PKI systems can be built ( may be not for
> >everything) but there is a big market for them - because they are big
> >systems - and as everyone knows, the engineering processes in small
> >systems eg LDAP is a lot different to big ones (distributed directory
> >services)
> 
> No, big systems are not necessarily infrastructures. "Infrastructures"
> are
> systems that serve other systems in an underlying, supportive fashion.
	Groan

> A big system built for a given application, which is an end unto
> itself, is
> not an infrastructure.  
	Telephone systems ?? The Intenet

> But we are taking about PKIs, so I don't mean to
> dwell on the erroneous defintion above.  However,  I again find that
> your
> responses seem orthogonal to my comments, i.e., they do not refute my
> criticisms, but rather make more high level statements in support of
> your
> position.  This is a waste of my time, and that of the mailing list
> members.
	I dont think its a waste of time. I think this list has to get
the thing its responsible for ie. the design of PKIs -and that design
into a commercial and operationally accepted state.
	My views are quite simple - protocols and servers do not a
system make. Globalising information systems are a requirement in todays
world. Infrastructure services of the telephone system. the intenet and
PKI function will underpin this. I have put up drafts re validation via
directories - no comment.
	I hear CRLs and where things are, knowlege, distribution and
business policies re information systems are the issues. AND the only
way do deal with this is more syntax - which means the PKI configuration
army - high costs to users. NOT ACCEPTABLE 
	This is the same debate I had with the LDAP list re the LDAP
configuration army and replicating everything to everywhere.. Now that
everyone realises that LDAP servers on their own dont do much and are
expensive to run  - distribution as per X.500 seems to be accepted and
announced as a basic feature ...by the worlds biggest IT companies .

	If the scope of the work on this list is to keep adding syntax
to data objects that requires masses of human configuration then go for
it. Operational costs need to be considered.

	If the scope of the work is get to grips with large scale
information systems that use PKI - why not progress it.

> >> OCSP servers operated by CAs, vs. outsourcing OCSP services for a
> CA
> >> to a
> >> TTP, don't concentrate vulnerabilities, they distribute them.  So,
> >> depending on the model one envisions, OCSP may be fine froma
> security
> >> standpoint, or it can be made into another disaster waiting to
> happen.
> >>
> >	Operational and system design issues... Can debate this for
> >ever, if all we have to argue with is a protocol spec and a signed
> data
> >item.
> 
> if we were debating this would be true, but you're ducking my points,
> so
> it's hardly a debate :-).
> 
	I missed the point because there was not one. The text above
says ther are a number of scenarios in applying OCSP severs - agree
	and depnding how this done - and the weather, and sadam hussein,
the el nino effect or monica - that may be a disaster or not.

> <deleted text of my point #4>
> 
> >	Agree - standards are good - I have been involved with standards
> >for ISO/ITU for 20 years, the military for 8, transport and traffic
> >management for 4 and the IETF for about 8. However please note that
> a
> >set of ASN.1 data definitions is not a system architecture.
> 
> We agree on what is and is not an architecture, but that's about it.
> We
> can compare records re standards participation, if you wish.  I didn't
> do
> much in the ISO/ITU arena, but I've been an active IETF paritcipant
> since
> its inception, served on the IAB for a decade, chaired two WGs in the
> 90s,
> and authored a handfull of standards tracks RFCs over the last decade.
> 
	Salutations :-)

> >	A standard eg. X.500 is 20% of a product which is 20% of the
> >effort in a deployable system.
> >
> >	Let me get these points over.
> >	1. X.509 is part of X.500 - why. X.500 - the directory service
> >supports the distributed authentication process and domain level
> access
> >controls which are needed in a distributed business environment.
> 
> Yes, X.509 was created to support string authentication for X.500, but
> X.509 lives outside of X.500.  Many v3 extensions were added to
> compensate
> for the fact that certs and CRLs will not always be retrieved from
> directories and because reliance on directory access controls, vs.
> signed
> data structures, is a dangerous design approach.  For example, we now
> mark
> CRLs to indicate which ones are for CAs vs. users, rather that relying
> on
> the indications provided by the directory attributes in which they
> were
> stored.
> 
	And I totally disagree with this - my other emails say why. As a
shared secret - its all to do with the NAMES in a certificate AND the
fact that a cert is an attribute of an AUX OC of a structural OC whose
rules applied to an entry in a directory service that gives the game
away....

	I know there are some views are that directories dont exist but
X.509 is OK as a certificate format. eg Why did LDAP take directories
and  focus it down to "a protocol"?

	But reality is setting in isnt it....
	Many suppliers are applying  directory systems to PKIs and OCSP
servers and there are those around this planet who are directory
enabling big applications - and PABXs etc - for the same reasons - ie
information services approach, scaleability and an integrated user
authentication and access control paradigm.

	snip
> Sorry, but this sounds like more fluff to me.
	Fluffy things are good :-) So are boats.

> >	4. If I wanted to pitch the product -  I would not be talking
> >large scale system issues, development approaches and standards.
> 
> Why not?  Systems are composed from products.
	I am tempted but - every one knows we have the best :-)

> >	Please define what you mean by scale and approaches to scale. If
> >one is in the PKI and information services business and writing
> >standards for PKI - which must have a named - globally named
> information
> >components what is the database/protocol that you use that does
> "scale"
> 
> One can design scaleable solutions in various ways.  One may emphasize
> highly distributed, largely independent components with minimal
> interdependence.  One also may emphasize a tightly integrated, highly
> interdependent design approach.  You seem to be proposing the later, I
> am
> advocating the former.
	This is a bit fluffy for me - perhaps I might give these fluffy
things up.
	OR - perhaps I am proposing using an engineering, information
service methodology that you can do both of the above with. After all a
directory service is a function. eg we do support mutual server - server
authentication and signed ops (for some projects)

> >	why does the phone system have a directory service?
> 
> "A directory service?"  We don't have one, we have many.  What's the
> one
> number I call to get a phone number for any subscriber anywhere in the
> world?
	its 0103 :-) 

> >	why are all the PKI vendors on this planet embracing
> >directories?
> 
> Joint marketing opportunities produce increased revenues with lower
> costs,
> irrespective of the merits of the jointly marketed products/services
> :-).
> On a more serious note, users want solutions, and PKI solutions often
> require a directory, though not usually a globaly accessible one, nor
> one
> in which we create unnecessary vulnerabilities.
	agree - magic.

	Perhaps we (on this list can define the issue we are dealing re
naming and addressing, knowledge, etc and see what the alternative
scenarios are re directory services and hand crafted URLs.

	Then we can get down to the points eh.

	regards alan

> Steve

From: Alan Lloyd <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], Tammy Carter <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Fri, 5 Feb 1999 13:27:48 +1100
Sender: [email-masked]

some comments

> -----Original Message-----
> From:	Bob Jueneman 
> Sent:	Friday, February 05, 1999 11:07 AM
> To:	[email-masked]; Tammy Carter; [email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> Andrew,
> 
> [snip]
> > 
> 	[Andrew Probert]  Yep.. I agree that an extension could be used
> because the current extension is a Uniform Resource Locator, which
> constrains the reference to a WWW style protocol http://, ftp://, (and
> even
> ldap://).  This current extension presupposes / forces certificate
> validation paths into the infrastructure of URN/DNS/IP/ARP resolution
> and
> protocols.
> 
> 	Alternatively, when I already have the IssuerDistinguishedName,
> if
> there was actually a PKIX naming resolution protocol in place I can
> simply
> look this up to find the servers.   
	No all one needs is a "port" on a directory service  and use the
name to find the issuer - which should I know the comms addresses or
URLs of the issuer. I do not know the wire identifiers or the switch
numbers of the telephone system - I use a phone number for the target
recipient....
	In directories ...  I would use the name to get to the target
object - an entity which is an organisation, an organisational unit, a
device, a role or a person that performs the CA FUNCTION.

	I think of CAs as a function of a real world entity represented
in a directory as an object that INCLUDEs the properties of a CA.

	It seems that some think of CAs a servers with URLs

	The difference is: directories provide an information services
paradigm to this requirement

	directory less approaches provide a protocols and URLs
technology approach - scaleability, application, operations and
management overheads do not seem to be addressed - 
	whereas the directory approach deals with this..

	snip

> 	I suggest that X.500/DSP is stable and mature for online relay
> of
> queries.  X.500/DISP addresses some replication / caching issues.  The
> protocol is already certficate / crypto aware.  It can be accessed by
> front-end protocols of LDAP, DAP and Web/LDAP gateways.
> 
> [RRJ]  Ok, I think we are getting somewhere.
> 
> But...
> 
> Suppose the relying party is the legendary little old lady in Dubuque.
> 
> All she wants to do is be sure that amazon.com is really who they say
> they 
> are.  Let's imagine that she has an LDAP client available through her
> generic 
> browser -- what does she do?
> 
> She is knowledgeable enough to check the certificate for Amazon before
> 
> placing an order, and finds that there is one, but being a little
> suspicious, 
> decides to check on who issued it, and clicks on "Issuer".  Yup, there
> it is,
>      US
>      "RSA Data Security, Inc."
>      Secure Server Certification Authority
> 
> Great! Now her LDAP server knows exactly where to go (assuming that
> this was 
> the next certificate in the chain, and not the root.)  Go to the US,
> and search for 
> RSA Data Security, Inc. in the US's X.500 directory!  Maybe, just
> maybe, it will tell
> you what the DNS name, port number, etc., are that LDAP would have to
> use to 
> do anything.
> 
> Does she have to be preconfigured with the LDAP server address of her
> ISP or portal?
> What if the Issuer is not a well-known public CA, but the Pasadena
> Ladies Garden
> Club,  which hands out certificates to the members once a year, and
> then shuts down
> the server.
> 
> All the members of the Garden Club know that they use an external
> repository to maintain
> their CRL list, but how does the LOLFD know that?  Or even AOL?
> 
	This is a very heart waming story  - but am totally convinced
that little old ladies wont do anything where they have to understand
the stuff that gets discussed on this list.
	Its best if they bash on something with their pension book and
it all happens -  And we know it  will just happen better with a
directory service there.

	eg. I gave my mum my book on OSI and X.500 for xmas some years
go - she got to the part that dealt with DOP and DSA entry updates
across DSA boundaries and multiple superior references and then gave up
... QED :-)))

> The more I think about it, the more I like the idea of including a URL
> for the issuer's
> directory in the certificate itself.
	I dont. Simply because its unnecessary.

	X.509 is part of X.500 - ie the names in a cert should be
entries in the directory system that supports the certficate service.
The only reason you need URLs is the fact you are not using a directory
service. And we all know we need directories for the internet and
telephone and PKI systems to scale and be well managed.

	regards alan
> Bob

Date: Thu, 4 Feb 1999 18:14:25 -0500
To: Alan Lloyd <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Cc: [email-masked]
Sender: [email-masked]

Alan,

 <deleted text from my point #1>

>	I got confused with your logic in this  debate  - are you
>agreeing with me.

Not at all, and I don't think the argument was unclear.

>	If you want to talk threat to large scale systems I will. And
>yes all threats to systems are generally operational ones (cutting
>cables, power, sand in the fuel line etc.)

First, a threat is defined as a motivated, capable adversary" so the use of
the term "threat" here is inappprpriate.  Second, we have simple
counterexamples to your assertion, e.g., the massive, distributed switch
failure suffered by AT&T due to a propogated software error.  Benign
failures for such systems may often be of the "backhoe induced fading"
variety, but malicious attacks need not follow the same profile.

>	In military we have a term - a big system is a big target. Eg.
>the Internet, the Telephone network... However, that does not stop them
>being built. So we tend to follow through threat analysis with risk
>assessment, risk avoidance and risk acceptance. After all, even  living
>is a risk :-).

Yes, but some of us are better at risk avoidance than others :-). However,
smart designers try to avoid creating unnecessary risks in systems through
over concentration.

>	To debate signed data as being the preferred paradigm and saying
>putting that in a secure or insecure large scale repository ( a
>directory service)creates an operational risk - (which is obvious) so
>dont build one... seems a pointless statement. For the cryptographically
>protected information to have any UTILITY AT ALL in a large scale
>system,   it has to be provided by something in a way that can be found
>by those distributed users who wish to use it.

Now it's my turn to question the logic of your statements. Please stick to
responding to specific points, not issuing general, fluffly pronouncements.

>	Also note  and please do note that a directory is a distributed
>information function - that provides greater utility than conventional
>databases. One of these can be used in a Top secret env, many can be
>used privately on a restricted network or thousands can be used on low
>value, high volume transaction , global service systems. The
>trust/cost/risk/integrity and threat issues of these  are all
>operational/project/deployment issues.. and have very little to do with
>with the details of a signed cert or cRL (although they do factor in the
>debate).
>	ie do I use Type 1 algorithms to sign certs but leave the power
>switch for the CA visible on the road side.

Oh please, no more "directories as panacea" rhetoric.

<deleted text of my point #2>

>	See conmments above. Again the logic confuses me. I will always
>agree that one can build a small system without an infrastructure. :-)
>In fact a small system is not an infrastructure :-))) ... One can put a
>dozen OCSP servers around a CA - not a problem.
>	However if one want to run a business level system with
>tranactions and users that are verified for business products/ access
>with profiles  for global use- what is the information model, who/what
>administers it, how is it distributed and deployed, what is the
>busines's product, customer and inter-oganisation acquisition strategy
>and what are the information policies and procedures that deal with
>that....These are the system issues..
>
>	Where does this "information" stuff live - in a commercially
>optimised way....
>
>	Big systems are infrastructure, by definition. And threats are
>always on them. This does not mean that because of theoretical ideology
>we will always build small ones. PKI systems and directories means that
>infrastructure, large scale PKI systems can be built ( may be not for
>everything) but there is a big market for them - because they are big
>systems - and as everyone knows, the engineering processes in small
>systems eg LDAP is a lot different to big ones (distributed directory
>services)

No, big systems are not necessarily infrastructures. "Infrastructures" are
systems that serve other systems in an underlying, supportive fashion.  A
big system built for a given application, which is an end unto itself, is
not an infrastructure.  But we are taking about PKIs, so I don't mean to
dwell on the erroneous defintion above.  However,  I again find that your
responses seem orthogonal to my comments, i.e., they do not refute my
criticisms, but rather make more high level statements in support of your
position.  This is a waste of my time, and that of the mailing list members.

>> OCSP servers operated by CAs, vs. outsourcing OCSP services for a CA
>> to a
>> TTP, don't concentrate vulnerabilities, they distribute them.  So,
>> depending on the model one envisions, OCSP may be fine froma  security
>> standpoint, or it can be made into another disaster waiting to happen.
>>
>	Operational and system design issues... Can debate this for
>ever, if all we have to argue with is a protocol spec and a signed data
>item.

if we were debating this would be true, but you're ducking my points, so
it's hardly a debate :-).

<deleted text of my point #4>

>	Agree - standards are good - I have been involved with standards
>for ISO/ITU for 20 years, the military for 8, transport and traffic
>management for 4 and the IETF for about 8. However please note that  a
>set of ASN.1 data definitions is not a system architecture.

We agree on what is and is not an architecture, but that's about it.  We
can compare records re standards participation, if you wish.  I didn't do
much in the ISO/ITU arena, but I've been an active IETF paritcipant since
its inception, served on the IAB for a decade, chaired two WGs in the 90s,
and authored a handfull of standards tracks RFCs over the last decade.

>	A standard eg. X.500 is 20% of a product which is 20% of the
>effort in a deployable system.
>
>	Let me get these points over.
>	1. X.509 is part of X.500 - why. X.500 - the directory service
>supports the distributed authentication process and domain level access
>controls which are needed in a distributed business environment.

Yes, X.509 was created to support string authentication for X.500, but
X.509 lives outside of X.500.  Many v3 extensions were added to compensate
for the fact that certs and CRLs will not always be retrieved from
directories and because reliance on directory access controls, vs. signed
data structures, is a dangerous design approach.  For example, we now mark
CRLs to indicate which ones are for CAs vs. users, rather that relying on
the indications provided by the directory attributes in which they were
stored.

>	2. A directory service when applied to systems provides an User
>and Information Services approach to system design by definition because
>thats what a directory holds...  the User/Subsciber information base as
>well as the data models and objects for the products/services being
>used.

and the relevfane of this to our discussion would be ....

>	3. When one designs around a protocol and a database, one is
>designing a communication and data system. When one uses a directory
>service approach one is designing a distributed information SERVICE
>which is full scaleable, has built in protection capabilities, a common
>information model, a common information management model and a common
>security paradigm.

One certainly cannot assume uniform security from a distributed directory
service of a large scale, even if the paradigm is uniform.  But the rigor
of implementation and management significantly affects the quality of the
security afforded by the service, so commonality of the model is not
sufficient.

>	When applying a directory service to a system design one needs
>to take a totally different approach to that design to that of using
>databases and protocols. Because a directory service  is more than that.
>IT system design approaches HAVE evolved to meet the business and
>information management requirements of the global user and customer. It
>is wrong to compare this approach with a protocol/server/database
>approach.

Sorry, but this sounds like more fluff to me.

>	4. If I wanted to pitch the product -  I would not be talking
>large scale system issues, development approaches and standards.

Why not?  Systems are composed from products.

>	5. The Internet and its technologies is being integrated with
>voice systems and being applied to commercial use. The customers dictate
>that a system solution must be applied on this. Inventing more protocols
>has its place - but there is a lot more work going on around the
>Internet than that.

Since I work for a firm that is offering such integrated services I am well
aware of these issues, but again this seems irrelevant to the meat of the
discussion.

<deleted test from my point #5>

>	Please define what you mean by scale and approaches to scale. If
>one is in the PKI and information services business and writing
>standards for PKI - which must have a named - globally named information
>components what is the database/protocol that you use that does "scale"

One can design scaleable solutions in various ways.  One may emphasize
highly distributed, largely independent components with minimal
interdependence.  One also may emphasize a tightly integrated, highly
interdependent design approach.  You seem to be proposing the later, I am
advocating the former.

>	why does the phone system have a directory service?

"A directory service?"  We don't have one, we have many.  What's the one
number I call to get a phone number for any subscriber anywhere in the
world?

>	why are all the PKI vendors on this planet embracing
>directories?

Joint marketing opportunities produce increased revenues with lower costs,
irrespective of the merits of the jointly marketed products/services :-).
On a more serious note, users want solutions, and PKI solutions often
require a directory, though not usually a globaly accessible one, nor one
in which we create unnecessary vulnerabilities.

>
>	what is the debate here.
>	Is it small systems can be designed in way that makes them small
>	and that some systems can use a protocol/database approach - but
>weve done that for 20 years and these do work but have scaling issues
>	and that when one builds a secure information service that needs
>to scale globally - it will be an infrastructure and use directories and
>that the approaches to this are different to that of traditional
>methods.

Nice rhetoric, but you persist in not addressing specific criticisms
directly, so why bother?

Steve

Date: Thu, 4 Feb 1999 20:04:02 -0500
To: Andrew Probert <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Cc: [email-masked]
Sender: [email-masked]

Andrew,

Just a couple of comments on parts of your response to Bob:

>	If you allow active content to be downloaded, you could store
>encrypted keys in directory and download to the user, where they use their
>password to decrypt it and use it.  If you have sufficent seperation of
>duties from applet download / admin and the directory, it offers the
>alternative of not having keys accessible to operators..

I'm not sure I understand this proposal, and how it provides more secure
private key storage in a directory.  It would seem to rely on successful
enforcement of access controls within the directiry, but if we had lots of
confidence in them, we might not feel the need to consider other solutions.
Also, any approach that begins with "download active content" worries me.

>	The Internet only works because the DNS system is there, all DNSes
>know about their superiors up to the top *.NET, *.COM, *.ORG etc and
>InterNIC runs them.  (The CRL / OSCP is relying on a URL for a Name to map
>to a DNS for IP Address resolution.)

This isn't quite true, is it?  There is a distributed root for the DNS, and
the TLDs you mentioned, plus all the country TLDs, are under that.  The
Internet is not authoritative for all of those TLDs, nor for the DNS root.

>	If the Internet cannot work with pre-registered DNSes and entries,
>then why do we expect global interoperable PKI to work without
>pre-registration!

I presume you mean " ... without pre-registered ..." right/

>	It is fundamental to the working of PKI that this point is addressed
>as infrastructure i.e. registration of CA directories etc.!!
>
>	There are not going to be an unlimited number of PKIs, in fact there
>are not too many now, so the the registration structure should be put in
>place now, akin to DNS.  Where are our "authoritative servers" in the
>architecture that perform PKI equivalents to DNS name -> address resolution
>that have crypto and certificate capability?

There may be lots of PKIs, depending on which PKI models one assumes will
prevail.  However, many of them may be closed PKIs, and thus may not impose
significant, global directory demands.

Steve

Date: Thu, 4 Feb 1999 18:26:10 -0500
To: "Tammy Carter" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Cc: <[email-masked]>, "PKIX " <[email-masked]>
Sender: [email-masked]

Tammy,

>Generally speaking, information which is stored in a directory is
>accessible only to those people who are granted explicit access rights.
>And, by default, only the user would be given rights to his encrypted
>private key stored on his own object.  Thus, the user would have to
>specifically gave someone else rights to access his private key.

This assumes that the directory access controls are not violated, e.g., via
subversion of the underlying OS or as a result of a management error.
Experinece suggests that such assumtpions are generally unwarranted.

>However, those administrators with direct access to the directory database
>wherein my object resides could give themselves rights to my private key.
>Or copy it for an off-line attack on the encryption.  Or even change it.
>When my encrypted private key is stored in the directory, it is vulnerable
>to anyone who can get to a server which holds a copy of my object.  As we
>are fond of saying here - - Once someone has physical access to the
>server, all bets are off.

Which is a good reason to not take such chances.

>BUT....  That's true about any information which is stored in a directory.
>Not just about my private key.  From a company's perspective, there are
>far worse things that someone can do with physical access to a server than
>to pose as one of their employees.  So, a company would (hopefully) screen
>people a bit before giving them the keys to the kingdom.

The most sensitive data is unlikley to be stored in a directory, but is may
be stored in various file or web servers, access to which can be effected
once one has acquired the private keys of authorized users. So, which it is
true that a company is concerned about the sensitivity of the data stored
in a directory, I doubt that this data is the most sensitive data in the
company.

>It certainly seems reasonable for me to store the encrypted private key
>that I use for business purposes in the directory that my company
>maintains.  But, would I store the encrypted private key that I use for my
>on-line banking there?  I think that I'd have to weigh the pros and cons.
>On one hand, if I store it in the directory, I can use it even if I don't
>have my smart card and I never have to worry about losing it.  On the
>negative side, some administrators could, potentially, pose as me.  If I
>stored it in a smart card, I have control over it.  But, how well do I
>guard my wallet against theft?  How often do I lose it?  Anyone who
>finds/steals my smart card could break the PIN number and pose as me.

Good points, which get back to the usual question: what is the threat?  If
you are more concerned about muggers that hackers, then a directory might
be the better solution, but I still would want to encrypt the private key
there in a fahsion that does not make it accessible to system
administrators.

>The choice seems to be about how much I trust myself as opposed to the
>company whose directory I'm using.  There's no right answer here.  Both
>have their vulnerabilities.  Both have their shortcomings.  It all seems
>to boil down to:  Who do you trust?  and   What kind of availability do
>you need?

Again, one has to answer these questions in the context of a percieved
threat.  Absent a threat model, one cannot evaluate alternatives
meaningfully.  What worried me about what you described is the notion of
encrypting these keys with keys that are accessible to other than the user.
I suggest that there is a reasonable body of literature providing various
ways of protecting personal keys stored outside of my computing environment
without accepting the risks that seem to accrue from this approach.

Steve

Date: Thu, 4 Feb 1999 12:56:37 -0500
To: Andrew Probert <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: FW: Attribute used to store cached certificate chains?
Cc: "'Alan Lloyd'" <[email-masked]>, "'Bob Jueneman'" 	 <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

andrew,

>I think a re-statement and perhaps some may think oversimplification of the
>case is as follows: -
>
>CRLs are a batch method for publishing CRLs and we are agreed that an online
>realtime mechanism is required.
>A client navigating to a single OCSP server looks ok.
>When there are myriad of OCSP servers, the job becomes far more complex.
>A rationalisation of this is to have a single OCSP server that via backend
>protocols talks to other OCSP servers on the users behalf.

I can put the name of one OCSP server into a cert and have many instances
of that server available, for reliability.  We do this with web servers
quite well today, so this is not an unsolvable problem.  Also, having lots
of OCSP servers is not intrinsically a problem; the problem you cite seems
to arise only when a given cert might be checked by many independent
servers.  I've not seen compelling arguments suggesting why such an
arrangement is needed.

Steve

From: "Ambarish Malpani" <[email-masked]>
To: "'Andrew Probert'" <[email-masked]>, <[email-masked]>
Subject: RE: Finding PKIX Servers!
Date: Thu, 4 Feb 1999 18:08:59 -0800
Importance: Normal
Sender: [email-masked]

Hi Andrew,
    I think we should revoke the root certificate of the Pasadena
Ladies Club for wanting to move their oursourced CRL
management from vali-somebody. Wouldn't you agree :-)

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					     650.567.5457
Vali-Somebody, Inc.			     [email-masked]
1215 Terra Bella Ave.		           http://www.vali-somebody.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Andrew Probert
> Sent: Thursday, February 04, 1999 5:09 PM
> To: 'Bob Jueneman'; [email-masked]
> Subject: RE: Finding PKIX Servers!
> 
> 
> I love operational scenarios, they really help get to the crux of the
> matter!
> 
> I am comfortable with the Pasadena Ladies Club issuing certs 
> once a year.
> Lets suppose they they outsource CRL management to "www.vali-somebody"
> Lets suppose they hardcode the "www.vali-somebody" in the 
> certs extension.
> Then they want to change CRL outsourcers, WITHOUT REISSUING 
> THEIR CERTS!
> 
> The alternative approach is, if the IssuerDistinguishedName 
> of Pasadena
> Ladies Club is used to query
> the infrastructure, it will return them a service object 
> identifying the CRL
> service provider as
> "www.vali-somebody.com", supporting protocols xyz.  It may 
> have an alternate
> reference as "LDAP://better.mousetrap.com.au/crl" as the 
> Australian cache /
> provider.
> 
> Some extra comments inline..
> 
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  +61 3 9690 8877
> Fax +61 3 9690 8171
> 
> 
> > She is knowledgeable enough to check the certificate for 
> Amazon before 
> > placing an order, and finds that there is one, but being a little
> > suspicious, 
> > decides to check on who issued it, and clicks on "Issuer".  
> Yup, there it
> > is,
> >      US
> >      "RSA Data Security, Inc."
> >      Secure Server Certification Authority
> > 
> > Great! Now her LDAP server knows exactly where to go 
> (assuming that this
> > was 
> > the next certificate in the chain, and not the root.)  Go 
> to the US, and
> > search for 
> > RSA Data Security, Inc. in the US's X.500 directory!  
> Maybe, just maybe,
> > it will tell
> > you what the DNS name, port number, etc., are that LDAP 
> would have to use
> > to 
> > do anything.
> > 
> 	[Andrew Probert]  More precisely, the available service 
> providers
> and protocols, IP addresses, ISDN addresses, suported 
> protocols etc.  We can
> start to formulate objects for these service definitions.
> 
> > Does she have to be preconfigured with the LDAP server 
> address of her ISP
> > or portal?
> > 
> 	[Andrew Probert]  Absolutely!  It is configured with 
> the address of
> the portal that she trusts.
> 
> 	By analogy, if you check your IP configuration, you 
> will find that
> it is mandatory to have your Primary and optionally Secondary DNS
> pre-configured as the pre-requisite to interoperate with the Internet
> infrastrucuture.  The ISP may either run their own DNS server, locally
> caching DNS info, or provide you with the IP address of a superior DNS
> server.
> 
> 	If you are a corporate user, you admin people will 
> point you at the
> corporate DNS.
> 
> 	Connection to the PKI infrastructure, to give you global lookup
> capability can follow this analogy
> 
> > What if the Issuer is not a well-known public CA, but the 
> Pasadena Ladies
> > Garden
> > Club,  which hands out certificates to the members once a 
> year, and then
> > shuts down
> > the server.
> > 
> > All the members of the Garden Club know that they use an external
> > repository to maintain
> > their CRL list, but how does the LOLFD know that?  Or even AOL?
> > 
> 	[Andrew Probert]  Agreed, nobody can know it unless 
> they are given
> that "knowledge reference".  
> 
> > The more I think about it, the more I like the idea of 
> including a URL for
> > the issuer's
> > directory in the certificate itself.
> > 
> 	[Andrew Probert]  As per discussion above, we could 
> hardcode this
> into certificates, but it forces us to rely on FQDN naming 
> (Fully Qualified
> Domain Names) to resolve the service, plus this hardcodes to a single
> service provider / trademarks "www.better-moustrap.com"
> 
> > Bob
> 

From: Andrew Probert <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Subject: RE: Finding PKIX Servers!
Date: Fri, 5 Feb 1999 12:09:21 +1100 
Sender: [email-masked]

I love operational scenarios, they really help get to the crux of the
matter!

I am comfortable with the Pasadena Ladies Club issuing certs once a year.
Lets suppose they they outsource CRL management to "www.vali-somebody"
Lets suppose they hardcode the "www.vali-somebody" in the certs extension.
Then they want to change CRL outsourcers, WITHOUT REISSUING THEIR CERTS!

The alternative approach is, if the IssuerDistinguishedName of Pasadena
Ladies Club is used to query
the infrastructure, it will return them a service object identifying the CRL
service provider as
"www.vali-somebody.com", supporting protocols xyz.  It may have an alternate
reference as "LDAP://better.mousetrap.com.au/crl" as the Australian cache /
provider.

Some extra comments inline..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> She is knowledgeable enough to check the certificate for Amazon before 
> placing an order, and finds that there is one, but being a little
> suspicious, 
> decides to check on who issued it, and clicks on "Issuer".  Yup, there it
> is,
>      US
>      "RSA Data Security, Inc."
>      Secure Server Certification Authority
> 
> Great! Now her LDAP server knows exactly where to go (assuming that this
> was 
> the next certificate in the chain, and not the root.)  Go to the US, and
> search for 
> RSA Data Security, Inc. in the US's X.500 directory!  Maybe, just maybe,
> it will tell
> you what the DNS name, port number, etc., are that LDAP would have to use
> to 
> do anything.
> 
	[Andrew Probert]  More precisely, the available service providers
and protocols, IP addresses, ISDN addresses, suported protocols etc.  We can
start to formulate objects for these service definitions.

> Does she have to be preconfigured with the LDAP server address of her ISP
> or portal?
> 
	[Andrew Probert]  Absolutely!  It is configured with the address of
the portal that she trusts.

	By analogy, if you check your IP configuration, you will find that
it is mandatory to have your Primary and optionally Secondary DNS
pre-configured as the pre-requisite to interoperate with the Internet
infrastrucuture.  The ISP may either run their own DNS server, locally
caching DNS info, or provide you with the IP address of a superior DNS
server.

	If you are a corporate user, you admin people will point you at the
corporate DNS.

	Connection to the PKI infrastructure, to give you global lookup
capability can follow this analogy

> What if the Issuer is not a well-known public CA, but the Pasadena Ladies
> Garden
> Club,  which hands out certificates to the members once a year, and then
> shuts down
> the server.
> 
> All the members of the Garden Club know that they use an external
> repository to maintain
> their CRL list, but how does the LOLFD know that?  Or even AOL?
> 
	[Andrew Probert]  Agreed, nobody can know it unless they are given
that "knowledge reference".  

> The more I think about it, the more I like the idea of including a URL for
> the issuer's
> directory in the certificate itself.
> 
	[Andrew Probert]  As per discussion above, we could hardcode this
into certificates, but it forces us to rely on FQDN naming (Fully Qualified
Domain Names) to resolve the service, plus this hardcodes to a single
service provider / trademarks "www.better-moustrap.com"

> Bob

Date: Thu, 04 Feb 1999 16:24:32 -0800
To: Alan Lloyd <[email-masked]>, Andrew Probert <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

>> The only way you can _ensure_ "sufficient separation" of these duties
>> is
>> with an "air gap" and guards with guns.  One cannot rely upon "company
>> policy" that these duties remain separate and inviolable.
>>   
>	logic error detected here :-)
>	But having implemented air gaps and putting guards with guns
>around them must have been directed by a company policy.

OK, point taken :)

I guess they would have to be MY guards and guns (and they won't go for that)
so I would settle for having these global resources provide highly reliable
access to (potentially) "named opaque blobs".  Then no breach of internal
separations is a problem.  As long as the parties-at-risk are the only ones
who can make use of a blob, then there should be no objection to centralized
directory services.  I suppose it was Bob's comments about where he might
or might not keep his (unencrypted) secret key that set me off.

(Reducing to DefCon level 5)

___tony___

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 925-422-3881             LLLLLLLL

Date: Thu, 04 Feb 1999 17:06:36 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, "Tammy Carter" <[email-masked]>, <[email-masked]>
Subject: Re: Finding PKIX Servers!
Sender: [email-masked]

Andrew,

[snip]
> 
	[Andrew Probert]  Yep.. I agree that an extension could be used
because the current extension is a Uniform Resource Locator, which
constrains the reference to a WWW style protocol http://, ftp://, (and even
ldap://).  This current extension presupposes / forces certificate
validation paths into the infrastructure of URN/DNS/IP/ARP resolution and
protocols.

	Alternatively, when I already have the IssuerDistinguishedName, if
there was actually a PKIX naming resolution protocol in place I can simply
look this up to find the servers.   The result of my lookup should be an
information object telling me the supported protocol(s) and services of that
CA.  

	I suggest that X.500/DSP is stable and mature for online relay of
queries.  X.500/DISP addresses some replication / caching issues.  The
protocol is already certficate / crypto aware.  It can be accessed by
front-end protocols of LDAP, DAP and Web/LDAP gateways.

[RRJ]  Ok, I think we are getting somewhere.

But...

Suppose the relying party is the legendary little old lady in Dubuque.  
All she wants to do is be sure that amazon.com is really who they say they 
are.  Let's imagine that she has an LDAP client available through her generic 
browser -- what does she do?

She is knowledgeable enough to check the certificate for Amazon before 
placing an order, and finds that there is one, but being a little suspicious, 
decides to check on who issued it, and clicks on "Issuer".  Yup, there it is,
     US
     "RSA Data Security, Inc."
     Secure Server Certification Authority

Great! Now her LDAP server knows exactly where to go (assuming that this was 
the next certificate in the chain, and not the root.)  Go to the US, and search for 
RSA Data Security, Inc. in the US's X.500 directory!  Maybe, just maybe, it will tell
you what the DNS name, port number, etc., are that LDAP would have to use to 
do anything.

Does she have to be preconfigured with the LDAP server address of her ISP or portal?
What if the Issuer is not a well-known public CA, but the Pasadena Ladies Garden
Club,  which hands out certificates to the members once a year, and then shuts down
the server.

All the members of the Garden Club know that they use an external repository to maintain
their CRL list, but how does the LOLFD know that?  Or even AOL?

The more I think about it, the more I like the idea of including a URL for the issuer's
directory in the certificate itself.

Bob

From: Alan Lloyd <[email-masked]>
To: "'Tony Bartoletti'" <[email-masked]>, Andrew Probert <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Attribute used to store cached certificate chains?
Date: Fri, 5 Feb 1999 10:43:14 +1100
Sender: [email-masked]

Comments in line -

> -----Original Message-----
> From:	Tony Bartoletti 
> Sent:	Thursday, February 04, 1999 2:24 PM
> To:	Andrew Probert; 'Bob Jueneman'; [email-masked]; [email-masked];
> [email-masked]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> At 12:58 PM 2/4/99 +1100, Andrew Probert wrote:
> >Sundry comments.. 
> >
> >Andew Probert
> >Rotek Consulting   http://www.rotek.com.au
> >a Division of Secure Network Solutions
> >Tel  +61 3 9690 8877
> >Fax +61 3 9690 8171
> >
> >
> >
> >> -----Original Message-----
> >> From:	Bob Jueneman [SMTP:[email-masked]]
> >> Sent:	Thursday, February 04, 1999 9:27 AM
> >> To:	[email-masked]; [email-masked]; [email-masked]
> >> Subject:	RE: Attribute used to store cached certificate chains?
> >> 
> >> This discussion has kicked off several subthreads, and I'd 
> >> like to comment on a couple of them.
> >> 
> >	[Andrew Probert]  <snip> 
> >
> >	If you allow active content to be downloaded, you could store
> >encrypted keys in directory and download to the user, where they use
> their
> >password to decrypt it and use it.  If you have sufficent seperation
> of
> >duties from applet download / admin and the directory, it offers the
> >alternative of not having keys accessible to operators..
> 
> The only way you can _ensure_ "sufficient separation" of these duties
> is
> with an "air gap" and guards with guns.  One cannot rely upon "company
> policy" that these duties remain separate and inviolable.
>   
	logic error detected here :-)
	But having implemented air gaps and putting guards with guns
around them must have been directed by a company policy.

> [snip]
> 
> >	The Internet only works because the DNS system is there, all
> DNSes
> >know about their superiors up to the top *.NET, *.COM, *.ORG etc and
> >InterNIC runs them.  (The CRL / OSCP is relying on a URL for a Name
> to map
> >to a DNS for IP Address resolution.)
> >
> >	If the Internet cannot work with pre-registered DNSes and
> entries,
> >then why do we expect global interoperable PKI to work without
> >pre-registration!
> 
> This analogy is often used, but I wonder how appropriate this is.
> The internet DNS has the job of routing traffic.  The "global PKI"
> is not in the business (centrally) of routing traffic.
> 
	DNS provides resolution of domain space to IP addresses  so that
the Internet traffic can be routed (by routers)
	PKI functionality (global or otherwise) if based on directory
infrastructures will route transactions based on object names and system
knowledge of those names and name spaces. Transactions in this case will
be get a cert or crl or other PKI related information object .

	regards alan
> ___tony___
> 
> Tony Bartoletti                                             LL
> SPI-NET GURU                                             LL LL
> Computer Security Technology Center                   LL LL LL
> Lawrence Livermore National Lab                       LL LL LL
> PO Box 808, L - 303                                   LL LL LLLLLLLL
> Livermore, CA 94551-9900                              LL LLLLLLLL
> email: [email-masked]   phone: 925-422-3881             LLLLLLLL

From: Alan Lloyd <[email-masked]>
To: "'Tony Bartoletti'" <[email-masked]>, Tammy Carter <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Attribute used to store cached certificate chains?
Date: Fri, 5 Feb 1999 10:24:26 +1100
Sender: [email-masked]

The good thing about infrastructures is that they evolve over time. by
contribution, by investment and by usage - and if they are good they get
protected by law, defence agencies, or service providors or by
commercial policy.

Debating if a set of DSAs with protocols and X.509 objects is good or
bad as an infrastucture seems to be a waste of time.

And again  if half of an organisation does not use an infrastructure -
then some thing somewhere that is highly related to Humans - such as
business policy, human team spriit and engineering excellence has gone
wrong.

Over the last few hours I used the phone, roads, water, gas and internet
infrastructures - along with billions of others:-) 

regards alan

> -----Original Message-----
> From:	Tony Bartoletti 
> Sent:	Thursday, February 04, 1999 2:07 PM
> To:	Tammy Carter; [email-masked]; [email-masked]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> At 02:00 PM 2/3/99 -0700, Tammy Carter wrote:
> >Steve,
> 
> [snip]
> 
> >The choice seems to be about how much I trust myself as opposed to
> the company whose directory I'm using.  There's no right answer here.
> Both have their vulnerabilities.  Both have their shortcomings.  It
> all seems to boil down to:  Who do you trust?  and   What kind of
> availability do you need?
> 
> And is it wise to design into infrastructure a "favored" paradigm,
> when it is
> guaranteed to disaffect that half of the community who want to do it
> the other way?
> 
> ____tony____
> 
> Tony Bartoletti                                             LL
> SPI-NET GURU                                             LL LL
> Computer Security Technology Center                   LL LL LL
> Lawrence Livermore National Lab                       LL LL LL
> PO Box 808, L - 303                                   LL LL LLLLLLLL
> Livermore, CA 94551-9900                              LL LLLLLLLL
> email: [email-masked]   phone: 925-422-3881             LLLLLLLL

From: Alan Lloyd <[email-masked]>
To: "'Tammy Carter'" <[email-masked]>, PKIX  <[email-masked]>, Alan Lloyd <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Date: Fri, 5 Feb 1999 09:56:29 +1100
Sender: [email-masked]

Most systems now have the ability to go from local files, -> address
books ---> LDAP servers - eg SUN, Msoft, Lotus - so the interfaces are
being implemented.
I can use the X.500 on my laptop to store a company org, a set of
documents and some demo stuff with movie clips in.
I could also put in a local DIB for "cert paths I like to use"....

Directories (and Boats) are wonderful eh! :-)

regards alan

> -----Original Message-----
> From:	Tammy Carter 
> Sent:	Thursday, February 04, 1999 8:22 AM
> To:	PKIX ; [email-masked]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> Alan,
> 
> You bring up an interesting idea.  Perhaps, instead of caching the
> certificate chain on the user's object, the user should be selectively
> caching directory objects which could be periodically refreshed.  The
> question is:  If such a mini-directory were provided on a client,
> would applications take advantage of it?  Would my email package be
> able to go and look there for certificates rather than turning to a
> personal address book?
> 
> Perhaps, but the "personal address book" or some kind of certificate
> repository would still be necessary in some cases.  People who use CAs
> which are external to their tree (e.g., VeriSign, or even CA's in a
> different tree) would still need to cache the certificate(s) necessary
> to make up a certificate chain for inclusion in an S/MIME message
> since these certificates may not always be easy to get to.
> 
> Interesting notion to download portions of the directory to the
> client....  Rather than doing LDAP off of your client, you could do it
> to access the locally cached directory.  Interesting.....
> 
> Tammy Green Carter
> 
> 
> >>> Alan Lloyd <[email-masked]> 1-31-99 4:20:45 PM
> >>>
> 
> <snip>
> 
> I think the two biggest areas that need to be applied into the theory
> of
> PKI is 
> a) There is a business/trust/cost model which will be operationally
> driven - that the theory of PKI will have to fit into. And
> b) In many, many cases, that this will be applied to a distributed
> directory service.
> 
> I think the notion that all certs, CRLs and all user information will
> fit in one server or Database which is accessed by LDAP or OCSP on its
> own is the same as designing a big central mainframe system -
> something
> a few of us did 25 years ago! :-)
> 
> 
> So in answer to your question - caching. I have an X.500 directory on
> my
> notebook which can be a) Part of the companies DIB for which I am
> responsible for - a locally maintained - distributed component. AND a
> replicated part of the companies DIT which I extract for my own
> purposes
> in order to do my job. This is centrally managed. In all this keep all
> the info necessary to support my moble env.
> 
> The issues to me are stated above. Its the knowledge of potential
> recipients, what domains they work in and what policies and mechanisms
> they use for validating me. Such info and control has to be external
> to
> my environment and in a commonl information  infrastructure - a
> directory.
> 
> 
> Hope this helps with the debate
> regards alan
> 
> 
> > -----Original Message-----
> > From:	Tammy Carter 
> > Sent:	Friday, January 29, 1999 11:09 AM
> > To:	< ; [email-masked]; [email-masked] 
> > Subject:	RE: Attribute used to store cached certificate chains?
> > 
> > Hi, Alan,
> > 
> > Thanks for clarifying.  It _is_ incorrect to say that an entire
> > directory is off-line.
> > (Well, unless all the server's holding replicas have all gone down
> at 
> > exactly the same moment.)  
> > 
> > What I was referring to was more the inability of the user to read
> the
> > set of
> > objects from which a chain can be constructed.  This inability could
> > be caused by network outages (planned or unexpected), a bad
> > replication scheme, or even the inability of the client to
> communicate
> > with the necessary servers using the right protocols.
> > 
> > For example, picture a company's tree that spans the world.  Servers
> 
> > are on every continent.  I have a certificate, stored on my user
> > object.  
> > I travel to China for a month of consulting in our branch office.
> My 
> > administrator, thinking ahead, puts a replica of the partition
> > containing
> > my user object on a server in China so that a copy of my object is
> > being maintained locally.  Now, I want to send email and I need to
> > send a certificate chain with my S/MIME message.  My CA has an
> > object in the tree, but only Utah servers hold replicas of it's 
> > partition.  Unfortunately, due to network problems, I can't get
> > to my CA's object.  
> > 
> > It would seem reasonable to store a cached copy of the user's
> > certificate chain on their object rather than forcing the user to
> > store it on the client's file system, or on a floppy disk.  This
> > allows a "free seating policy" so that users can go to any
> > client and perform their job functions without having to carry
> > around floppy disks.
> > 
> > My initial question was:  has anyone thought of caching this
> > information in the directory yet?  If so, what attributes are being
> > used?
> > 
> > 
> > Tammy Green Carter
> > [email-masked] 
> > 
> > 
> > >>> Alan Lloyd <[email-masked]> 1-28-99 3:03:33 PM
> > >>>
> > Some comments
> > 
> > This debate seems to say that a directory tree is unavailable and
> > therefore local caching is used. It would strike me that a major
> part
> > of
> > the system design of an organisation's information system. eg HR,
> > database or PABX or RADIUS directory,  that replica's are placed at
> > certain points to avoid service failures. Although there are major
> > functional distinctions between a database, a file system, a
> directory
> > service, etc. The system design and operational deployment of all of
> > these things makes sure that service levels are maintained. Saying
> > that
> > "a directory" is off line is like saying a database is off line or
> the
> > file server is off line. I would expect that a User who is mobile to
> > contain on their local directory/file system all the things that
> > support
> > that environment eg address books, mail boxes and a bunch of keys
> and
> > certs..which can be replica entries of the CAs system.

From: Andrew Probert <[email-masked]>
To: "'Tammy Carter'" <[email-masked]>, [email-masked], [email-masked], Bob Jueneman <[email-masked]>, Andrew Probert <[email-masked]>
Subject: Finding PKIX Servers!
Date: Fri, 5 Feb 1999 09:44:32 +1100 
Sender: [email-masked]

Comments  inline...
I have renamed this thread subject above to reflect subject the matter.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171
	[Andrew Probert]  <SNIP> 
> Here I would beg to differ.  There are several vendors (Entrust, Netscape,
> Microsoft, and Novell to name a few) which sell create-your-own-PKI
> software.  Using this software, any company can establish it's own
> top-level CA and set up their very own PKI.  Perhaps there aren't very
> many "roots" which are recognized by the world or listed in the major
> browsers, but I would hypothesize that there are several burgeoning PKIs
> which are known only within particular communities.  
> 
	[Andrew Probert]  .. and its quite OK for companies to run internal
DNS servers with proprietary / closed user groups, this is normal.  But when
one wants to play in the global network of Internet one adopts the Naming
rules and Registration Authorities etc that tie it all together, so the DNS
servers can find each other and exchange the commonly agreed information
objects (albiet there are only about 3 attributes in MX records).

	To me, the operational success of the Internet has been based upon
DNS (as a form of directory) and for example allowed SMTP mail to gain its
runaway success against stronger protocols like X.400, because
pre-registration of a company to the infrastructure allowed their mail
servers to be easily found, with minimal configuration by the sender's
company in a somewhat more promiscuous manner.

	By analogy, PKIX needs to be aware of these registration models and
emulate them .. to gain runaway success ..

> It is certainly an option to have a "PKI root CA registry."  But, do we
> really want to?  Is there a better way?  When an extension was added to a
> certificate to hold a location at which revocation information could be
> found, the registry option must have been considered and rejected.  Why
> was is rejected?  Perhaps Bob is right and a similar extension should be
> added for the location of the issuer's certificate.
> 
	[Andrew Probert]  Yep.. I agree that an extension could be used
because the current extension is a Uniform Resource Locator, which
constrains the reference to a WWW style protocol http://, ftp://, (and even
ldap://).  This current extension presupposes / forces certificate
validation paths into the infrastructure of URN/DNS/IP/ARP resolution and
protocols.

	Alternatively, when I already have the IssuerDistinguishedName, if
there was actually a PKIX naming resolution protocol in place I can simply
look this up to find the servers.   The result of my lookup should be an
information object telling me the supported protocol(s) and services of that
CA.  

	I suggest that X.500/DSP is stable and mature for online relay of
queries.  X.500/DISP addresses some replication / caching issues.  The
protocol is already certficate / crypto aware.  It can be accessed by
front-end protocols of LDAP, DAP and Web/LDAP gateways.
> <snip>
> 
> >> Unfortunately, the performance hit in this case would be even worse
> than
> >> in the 
> >> local directory. 
> >> 
> >	[Andrew Probert] Performance hits are relative.  If I have a
> >directory with a 30 millisecond response time to a single read, out of a
> >directory with > million entries, is this slow or fast enough?  
> >
> >	We need to provide some operational criteria about retrieval rates,
> >volumes etc required for Global PKI, then apply technology, partitioning,
> >cacheing strategies to suit the requirement.
> 
> Criteria would be a great thing to see.  But, I'm not sure that it helps
> when you consider some of the worst-case-scanrios.  My biggest concern is
> not a 30 millisecond retrieval time.  Instead, it is that the client may
> not be able to get to a server (or to the right server) for hours or even
> days due to network outages, protocol incompatibilities, downed WAN links,
> etc.
> 
	[Andrew Probert]  Certainly true, thats why true infrastructure has
service and availability levels and banks run branches on facilities other
than the Internet.  If the network is down, good old CRLs work well as they
can be cached, implicitly OCSP and other real-time lookups require a
real-time network.

> <snip>
> 
> >	[Andrew Probert]  I think it will be located in many / multiple
> >places.  So may as well start by defining its structure, then where to
> put
> >it etc is the second issue.  An ASN.1 structure, maybe PKCS#7?  What else
> do
> >we need to know about it?
> 
> As Francois Rousseau reminded me, an ASN.1 structure does exist.  It is
> called CertificateChain.  However, as I said in a previous email, I
> haven't heard of anyone using it yet.  Perhaps it has fallen out of favor?
> 
> 
> Tammy Green Carter
> [email-masked] 

From: "Sikac,John,CNA Insurance" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Entrust
Date: Thu, 4 Feb 1999 13:21:58 -0600 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE507A.C7F29A70
Content-Type: text/plain

Does anyone have any experience with Entrust and their PKI solution?

JS

------_=_NextPart_001_01BE507A.C7F29A70
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>Entrust</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#000000" SIZE=2 FACE="Arial">Does anyone have any experience with Entrust and their PKI solution?</FONT>
</P>

<P><FONT COLOR="#000000" SIZE=2 FACE="Arial">JS</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE507A.C7F29A70--

From: "Sikac,John,CNA Insurance" <[email-masked]>
To: [email-masked]
Subject: Entrust
Date: Thu, 4 Feb 1999 13:19:45 -0600 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE507A.43D94FE0
Content-Type: text/plain

Does anyone have experience with Entrust and their PKI technology?

John

------_=_NextPart_001_01BE507A.43D94FE0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>Entrust</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Does anyone have experience with Entrust and their PKI technology?</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">John</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE507A.43D94FE0--

Date: Thu, 04 Feb 1999 12:57:42 -0700
From: "Tammy Carter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Bob Jueneman" <[email-masked]>, <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

Comments below.....

>>>> Andrew Probert <[email-masked]> 2-3-99 6:58:59 PM >>>
>Sundry comments.. 
>
>Andew Probert
>Rotek Consulting   http://www.rotek.com.au 
>a Division of Secure Network Solutions
>Tel  +61 3 9690 8877
>Fax +61 3 9690 8171
>
>
>
>> -----Original Message-----
>> From:	Bob Jueneman [SMTP:[email-masked]] 
>> Sent:	Thursday, February 04, 1999 9:27 AM
>> To:	[email-masked]; [email-masked]; [email-masked] 
>> Subject:	RE: Attribute used to store cached certificate chains?
>> 
>> This discussion has kicked off several subthreads, and I'd 
>> like to comment on a couple of them.
>> 
>	[Andrew Probert]  <snip> 
>
>	If you allow active content to be downloaded, you could store
>encrypted keys in directory and download to the user, where they use their
>password to decrypt it and use it.  If you have sufficent seperation of
>duties from applet download / admin and the directory, it offers the
>alternative of not having keys accessible to operators..

Unfortunately, even in this situation, the keys are still vulnerable to off-line encryption-breaking attacks by the operators.  However, as per my previous emails, I believe that, for some keys, the risk is acceptable.  

(Bob's personal signature key would obviously not be one of those keys.  :)

<snipping Bob's comments>

>	[Andrew Probert]  Excellent points...  
>
>	The Internet only works because the DNS system is there, all DNSes
>know about their superiors up to the top *.NET, *.COM, *.ORG etc and
>InterNIC runs them.  (The CRL / OSCP is relying on a URL for a Name to map
>to a DNS for IP Address resolution.)
>
>	If the Internet cannot work with pre-registered DNSes and entries,
>then why do we expect global interoperable PKI to work without
>pre-registration!
>
>	It is fundamental to the working of PKI that this point is addressed
>as infrastructure i.e. registration of CA directories etc.!!  
>
>	There are not going to be an unlimited number of PKIs, in fact there
>are not too many now, so the the registration structure should be put in
>place now, akin to DNS.  Where are our "authoritative servers" in the
>architecture that perform PKI equivalents to DNS name -> address resolution
>that have crypto and certificate capability?

Here I would beg to differ.  There are several vendors (Entrust, Netscape, Microsoft, and Novell to name a few) which sell create-your-own-PKI software.  Using this software, any company can establish it's own top-level CA and set up their very own PKI.  Perhaps there aren't very many "roots" which are recognized by the world or listed in the major browsers, but I would hypothesize that there are several burgeoning PKIs which are known only within particular communities.  

It is certainly an option to have a "PKI root CA registry."  But, do we really want to?  Is there a better way?  When an extension was added to a certificate to hold a location at which revocation information could be found, the registry option must have been considered and rejected.  Why was is rejected?  Perhaps Bob is right and a similar extension should be added for the location of the issuer's certificate.

<snip>

>> Unfortunately, the performance hit in this case would be even worse than
>> in the 
>> local directory. 
>> 
>	[Andrew Probert] Performance hits are relative.  If I have a
>directory with a 30 millisecond response time to a single read, out of a
>directory with > million entries, is this slow or fast enough?  
>
>	We need to provide some operational criteria about retrieval rates,
>volumes etc required for Global PKI, then apply technology, partitioning,
>cacheing strategies to suit the requirement.

Criteria would be a great thing to see.  But, I'm not sure that it helps when you consider some of the worst-case-scanrios.  My biggest concern is not a 30 millisecond retrieval time.  Instead, it is that the client may not be able to get to a server (or to the right server) for hours or even days due to network outages, protocol incompatibilities, downed WAN links, etc.

<snip>

>	[Andrew Probert]  I think it will be located in many / multiple
>places.  So may as well start by defining its structure, then where to put
>it etc is the second issue.  An ASN.1 structure, maybe PKCS#7?  What else do
>we need to know about it?

As Francois Rousseau reminded me, an ASN.1 structure does exist.  It is called CertificateChain.  However, as I said in a previous email, I haven't heard of anyone using it yet.  Perhaps it has fallen out of favor?

Tammy Green Carter
[email-masked] 

Date: Thu, 04 Feb 1999 11:53:03 -0800
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, "Tammy Carter" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

At 10:24 AM 2/4/99 -0700, Bob Jueneman wrote:
>I'm not sure I understand your comment, Tony.
>Certainly we're not suggesting that any particular paradigm
>be mandated, or even favored, merely allowed to be supported.

I understood this, I think.  As you say, we are only suggesting that
a particular paradigm be "allowed to be supported."  The somewhat heated
exchange on this thread indicates a variance on allowance that goes
beyond a mere debate about optimizations.  As Tammy Carter point out,
it is about who you will trust.  Unfortunately, decisions which impact
performance to one paradigm or another can have multiplicative consequences
down the line.

Perhaps you read my comment as contrary to Tammy's observation.  I intended
to be supportive.  I suppose it could have been taken either way.

___tony___

>Remember that this discussion started off by asking the question of where
>certificate chains should be stored in a directory. How is that going to 
>disaffect some subset of users?
>
>Obviously we could go off and do whatever we need to do in
>a proprietary manner, but that wouldn't be very helpful with respect 
>to achieving interoperability of PKI and directories, would it?
>
>Surely you're not suggesting that one faction of the standards community 
>should _prevent_ another group from doing whatever they need to do?
>
>Bob
>
>
>>>> Tony Bartoletti <[email-masked]> 02/03/99 08:06PM >>>
>At 02:00 PM 2/3/99 -0700, Tammy Carter wrote:
>>Steve,
>
>[snip]
>
>>The choice seems to be about how much I trust myself as opposed to the company whose directory I'm using.  There's no right answer here.  Both have their vulnerabilities.  Both have their shortcomings.  It all seems to boil down to:  Who do you trust?  and   What kind of availability do you need?
>
>And is it wise to design into infrastructure a "favored" paradigm, when it is
>guaranteed to disaffect that half of the community who want to do it the other way?
>
>____tony____
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 925-422-3881             LLLLLLLL
>
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 925-422-3881             LLLLLLLL

Date: Thu, 04 Feb 1999 11:41:18 -0800
To: <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

At 11:52 AM 2/4/99 -0500, Paul Koning wrote:
>>>>>> "Tony" == Tony Bartoletti <[email-masked]> writes:
>
> >> If the Internet cannot work with pre-registered DNSes and entries,
> >> then why do we expect global interoperable PKI to work without
> >> pre-registration!
>
> Tony> This analogy is often used, but I wonder how appropriate this
> Tony> is.  The internet DNS has the job of routing traffic.  The
> Tony> "global PKI" is not in the business (centrally) of routing
> Tony> traffic.
>
>I must be missing something.  DNS doesn't do routing.  It maps names
>to identifiers (so-called IP "addresses").  Nothing in DNS has any
>connection to routing -- that's the job of OSPF, BGP, and sundry
>others.
>
>	paul

OK.  I meant it directly supports the routing of traffic, and its function
should be leveraged more than be co-opted.  I am of two-minds on this, for
there is value in NOT relying upon the "one naming authority in the sky"
for all identity resolution as well.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 925-422-3881             LLLLLLLL

Date: Thu, 04 Feb 1999 12:19:00 -0700
From: "Tammy Carter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

Francois,

I did look at CertificationPath.  I had a couple of concerns about using it, though.  

1.  No other X.500 attributes have this syntax.  This, in and of itself, is not bad.  However, it does give me pause to wonder if there is a "better" syntax?

2.  I am unsure how to use CertificatePair correctly in this context.  After all, it hasn't been that long ago that the PKIX community realized that there were two separate understandings of how CertificatePair was to be used in the attribute crossCertificatePair.  So I wasn't sure that I wanted to open the can of worms and blaze the trail.

Has anyone else seen this data type used before?  If so, in what situations?

Tammy Green Carter
[email-masked]

>>> Francois Rousseau <[email-masked]> 2-4-99 7:00:05 AM >>>
Tammy,

Have you considered for this using the ASN.1 data type "CertificationPath",
which is defined at the end of Clause 8 of X.509 (97) as follows:

CertificationPath		::=	SEQUENCE {
	userCertificate		Certificate,
	theCACertificates		SEQUENCE OF CertificatePair OPTIONAL }

CertificatePair		::=	SEQUENCE {
	forward		[0]	Certificate OPTIONAL,
	reverse		[1]	Certificate OPTIONAL
			-- at least one of the pair shall be present -- }

Francois Rousseau
AEPOS Technologies

Bob Jueneman wrote:
[snip]
> So it appears that we need to be able to store an entire chain of
certificates in
> one place, presumably associated with the user's object. So what kind of
attribute
> should be used, and where should it be located?
>
> Bob
>

From: "Ambarish Malpani" <[email-masked]>
To: "'Binken, Rens'" <[email-masked]>, <[email-masked]>
Subject: RE: What's the relation between CRT and OCSP ?
Date: Thu, 4 Feb 1999 09:41:57 -0800
Importance: Normal
Sender: [email-masked]

Hi Rens,
    OCSP and CRT are two different protocols to check the status
of a certificate. OCSP is proceeding on the standards track
and (hopefully) will become a standard soon.

CRTs are another mechanism to provide status information on
certificates. It was invented by us (at ValiCert) and we have
some patent applications regarding it. They can either use a
query in a custom format, or an OCSP query.

There are performance and scalabity differences between the
two protocols, which I would be happy to explain if you are
interested (I am not sure the PKIX mailing list would be the
right place to do so).

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Binken, Rens
> Sent: Thursday, February 04, 1999 8:11 AM
> To: [email-masked]
> Subject: What's the relation between CRT and OCSP ?
> 
> 
> LS,
> 
> I've been reading about Certificate revocation trees (CRT) and Online
> Certificate Status Protocol (OCSP). I can see that both 
> mechnism help to get
> more timely revocation information. My questions are : What's 
> the relation
> between CRTs and OCSP ? 
> Do you need the OCSP protocol to check CRTs ? Or are these two totally
> different mechnism for checking validity ?
> 
> Regards,
> 
> L.S. Binken
> 
> kpmg TTP-Services
> Burgemeester Rijnderslaan 20, 1185 MC Amstelveen
> P.O. Box 74555, 1070 DC Amsterdam, the Netherlands
> tel:	+31-20-656 83 83
> fax:	+31-20-656 83 88
> e-mail: [email-masked] 
> X400:c=NL;a=CONCERT;p=KPMG;s=Binken;g=Rens;
> Visit our solutioncentre:	http://www.solutioncentre.nl/
> 
> 
> **********************************************************************
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to 
> whom they   
> are addressed. If you have received this email in error please notify 
> the system manager.
> 
> This footnote also confirms that this email message has been swept by 
> MIMEsweeper for the presence of computer viruses.
> 
> www.mimesweeper.com
> **********************************************************************
> 

Date: Thu, 04 Feb 1999 10:24:20 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Tammy Carter" <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

I'm not sure I understand your comment, Tony.
Certainly we're not suggesting that any particular paradigm
be mandated, or even favored, merely allowed to be supported.

Remember that this discussion started off by asking the question of where
certificate chains should be stored in a directory. How is that going to 
disaffect some subset of users?

Obviously we could go off and do whatever we need to do in
a proprietary manner, but that wouldn't be very helpful with respect 
to achieving interoperability of PKI and directories, would it?

Surely you're not suggesting that one faction of the standards community 
should _prevent_ another group from doing whatever they need to do?

Bob

>>> Tony Bartoletti <[email-masked]> 02/03/99 08:06PM >>>
At 02:00 PM 2/3/99 -0700, Tammy Carter wrote:
>Steve,

[snip]

>The choice seems to be about how much I trust myself as opposed to the company whose directory I'm using.  There's no right answer here.  Both have their vulnerabilities.  Both have their shortcomings.  It all seems to boil down to:  Who do you trust?  and   What kind of availability do you need?

And is it wise to design into infrastructure a "favored" paradigm, when it is
guaranteed to disaffect that half of the community who want to do it the other way?

____tony____

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 925-422-3881             LLLLLLLL

From: "Binken, Rens" <[email-masked]>
To: [email-masked]
Subject: What's the relation between CRT and OCSP ?
Date: Thu, 4 Feb 1999 17:11:11 +0100 
Sender: [email-masked]

LS,

I've been reading about Certificate revocation trees (CRT) and Online
Certificate Status Protocol (OCSP). I can see that both mechnism help to get
more timely revocation information. My questions are : What's the relation
between CRTs and OCSP ? 
Do you need the OCSP protocol to check CRTs ? Or are these two totally
different mechnism for checking validity ?

Regards,

L.S. Binken

kpmg TTP-Services
Burgemeester Rijnderslaan 20, 1185 MC Amstelveen
P.O. Box 74555, 1070 DC Amsterdam, the Netherlands
tel:	+31-20-656 83 83
fax:	+31-20-656 83 88
e-mail: [email-masked] 
X400:c=NL;a=CONCERT;p=KPMG;s=Binken;g=Rens;
Visit our solutioncentre:	http://www.solutioncentre.nl/

**********************************************************************
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

From: Andrew Probert <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Attribute used to store cached certificate chains?
Date: Thu, 4 Feb 1999 16:24:21 +1100 
Sender: [email-masked]

> Beg to differ on this ..
> 
> <snip>
> 
> >	If the Internet cannot work with pre-registered DNSes and entries,
> >then why do we expect global interoperable PKI to work without
> >pre-registration!
> 
> This analogy is often used, but I wonder how appropriate this is.
> The internet DNS has the job of routing traffic.  The "global PKI"
> is not in the business (centrally) of routing traffic.
> 
> [Andrew Probert]  DNS is in the business of providing a registry where we
> can register FQDNs (Fully Qualified Domain Names) againsts their matching
> IP addresses xxx.xxx.xxx.xxx.  
> 
> The job of routing is performed in a meshed manner by the network hardware
> using the resolved IP addresses.
> 
> The key feature is that it allows us to give devices and applications
> logical names and a level of indirection from the infrastructure.
> 
> DNSes only route DNS queries i.e. if your local DNS cannot resolve a FQDN
> to an IP address from its local database or cache, it will query its
> superior DNS eventually returning the IP address in question.  From then
> on the DNSes do not particpate in the subsequent point to point
> communication / protocols.
> 
> The reason it works is that there are Naming Rules and Registration Rules
> applied to this namespace.
> 
> I believe the analogy is strong for the needs for Naming Rules and
> Registration Rules to be applied to the PKIX architecture .. with a naming
> lookup service?
> 
> If people want to run closed user group networks, today they have private
> DNS and private namespaces.  If they want to run in the global
> interoperable world they must abide by 'rules'.  Why should PKI not follow
> this model?
> 
> 
> ___tony___
> 
> Tony Bartoletti                                             LL
> SPI-NET GURU                                             LL LL
> Computer Security Technology Center                   LL LL LL
> Lawrence Livermore National Lab                       LL LL LL
> PO Box 808, L - 303                                   LL LL LLLLLLLL
> Livermore, CA 94551-9900                              LL LLLLLLLL
> email: [email-masked]   phone: 925-422-3881             LLLLLLLL
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  +61 3 9690 8877
> Fax +61 3 9690 8171
> 

From: Andrew Probert <[email-masked]>
To: Andrew Probert <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Attribute used to store cached certificate chains?
Date: Thu, 4 Feb 1999 15:15:48 +1100 
Sender: [email-masked]

Sorry typo in previous email ..

> 	If the Internet cannot work [Andrew Probert]   *without*
> pre-registered DNSes and entries,
> then why do we expect global interoperable PKI to work without
> pre-registration!
> 
> 

Date: Wed, 03 Feb 1999 19:24:06 -0800
To: Andrew Probert <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

At 12:58 PM 2/4/99 +1100, Andrew Probert wrote:
>Sundry comments.. 
>
>Andew Probert
>Rotek Consulting   http://www.rotek.com.au
>a Division of Secure Network Solutions
>Tel  +61 3 9690 8877
>Fax +61 3 9690 8171
>
>
>
>> -----Original Message-----
>> From:	Bob Jueneman [SMTP:[email-masked]]
>> Sent:	Thursday, February 04, 1999 9:27 AM
>> To:	[email-masked]; [email-masked]; [email-masked]
>> Subject:	RE: Attribute used to store cached certificate chains?
>> 
>> This discussion has kicked off several subthreads, and I'd 
>> like to comment on a couple of them.
>> 
>	[Andrew Probert]  <snip> 
>
>	If you allow active content to be downloaded, you could store
>encrypted keys in directory and download to the user, where they use their
>password to decrypt it and use it.  If you have sufficent seperation of
>duties from applet download / admin and the directory, it offers the
>alternative of not having keys accessible to operators..

The only way you can _ensure_ "sufficient separation" of these duties is
with an "air gap" and guards with guns.  One cannot rely upon "company
policy" that these duties remain separate and inviolable.

[snip]

>	The Internet only works because the DNS system is there, all DNSes
>know about their superiors up to the top *.NET, *.COM, *.ORG etc and
>InterNIC runs them.  (The CRL / OSCP is relying on a URL for a Name to map
>to a DNS for IP Address resolution.)
>
>	If the Internet cannot work with pre-registered DNSes and entries,
>then why do we expect global interoperable PKI to work without
>pre-registration!

This analogy is often used, but I wonder how appropriate this is.
The internet DNS has the job of routing traffic.  The "global PKI"
is not in the business (centrally) of routing traffic.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 925-422-3881             LLLLLLLL

Date: Wed, 03 Feb 1999 19:06:54 -0800
To: "Tammy Carter" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

At 02:00 PM 2/3/99 -0700, Tammy Carter wrote:
>Steve,

[snip]

>The choice seems to be about how much I trust myself as opposed to the company whose directory I'm using.  There's no right answer here.  Both have their vulnerabilities.  Both have their shortcomings.  It all seems to boil down to:  Who do you trust?  and   What kind of availability do you need?

And is it wise to design into infrastructure a "favored" paradigm, when it is
guaranteed to disaffect that half of the community who want to do it the other way?

____tony____

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 925-422-3881             LLLLLLLL

From: Andrew Probert <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Attribute used to store cached certificate chains?
Date: Thu, 4 Feb 1999 12:58:59 +1100 
Sender: [email-masked]

Sundry comments.. 

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Thursday, February 04, 1999 9:27 AM
> To:	[email-masked]; [email-masked]; [email-masked]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> This discussion has kicked off several subthreads, and I'd 
> like to comment on a couple of them.
> 
	[Andrew Probert]  <snip> 

	If you allow active content to be downloaded, you could store
encrypted keys in directory and download to the user, where they use their
password to decrypt it and use it.  If you have sufficent seperation of
duties from applet download / admin and the directory, it offers the
alternative of not having keys accessible to operators..

> In addition, there is another problem that is not quite so obvious, and
> that concerns
> directories that are not necessarily fully interconnected.
> 
> Ideally, every X.500 directory in the world would know about every other
> one, and 
> they would all be interconnected and share precisely the same schema for
> DNs, etc.
> 
> But that isn't going to happen any time soon, if at all.
> 
> Another solution if the directories were interconnected would be to either
> chain or refer to 
> the other directory, but that might not be feasible if one directory
> doesn't know the
> details of where the other directory is located, its DNS name and port
> number, etc.
> (Isn't it interesting that we have define referral mechanisms to tell the
> relying party
> where to find the CRL or OCSP provider, but not the Issuer's directory?)  
> 
	[Andrew Probert]  Excellent points...  

	The Internet only works because the DNS system is there, all DNSes
know about their superiors up to the top *.NET, *.COM, *.ORG etc and
InterNIC runs them.  (The CRL / OSCP is relying on a URL for a Name to map
to a DNS for IP Address resolution.)

	If the Internet cannot work with pre-registered DNSes and entries,
then why do we expect global interoperable PKI to work without
pre-registration!

	It is fundamental to the working of PKI that this point is addressed
as infrastructure i.e. registration of CA directories etc.!!  

	There are not going to be an unlimited number of PKIs, in fact there
are not too many now, so the the registration structure should be put in
place now, akin to DNS.  Where are our "authoritative servers" in the
architecture that perform PKI equivalents to DNS name -> address resolution
that have crypto and certificate capability?

	It does not seem too much trouble for an organisation to run a Level
1 DSA as a registry of DSAs and in fact the names and network addresses of
OCSP servers, ICAP Servers (draft-sakurai-pkix-icap-01.txt) and in fact all
of the plethora of PKIX server and protocols that seem to be coming!

> Unfortunately, the performance hit in this case would be even worse than
> in the 
> local directory. 
> 
	[Andrew Probert] Performance hits are relative.  If I have a
directory with a 30 millisecond response time to a single read, out of a
directory with > million entries, is this slow or fast enough?  

	We need to provide some operational criteria about retrieval rates,
volumes etc required for Global PKI, then apply technology, partitioning,
cacheing strategies to suit the requirement.

> So it appears that we need to be able to store an entire chain of
> certificates in one place,
> presumably associated with the user's object. So what kind of attribute
> should be used, and where should it be located?
> 
	[Andrew Probert]  I think it will be located in many / multiple
places.  So may as well start by defining its structure, then where to put
it etc is the second issue.  An ASN.1 structure, maybe PKCS#7?  What else do
we need to know about it?

> Bob
> 
> 
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [email-masked]
> 1-801-861-7387
> 
> >>> "Tammy Carter" <[email-masked]> 02/03/99 02:00PM >>>
> Steve,
> 
> Generally speaking, information which is stored in a directory is
> accessible only to those people who are granted explicit access rights.
> And, by default, only the user would be given rights to his encrypted
> private key stored on his own object.  Thus, the user would have to
> specifically gave someone else rights to access his private key.  
> 
> However, those administrators with direct access to the directory database
> wherein my object resides could give themselves rights to my private key.
> Or copy it for an off-line attack on the encryption.  Or even change it.
> When my encrypted private key is stored in the directory, it is vulnerable
> to anyone who can get to a server which holds a copy of my object.  As we
> are fond of saying here - - Once someone has physical access to the
> server, all bets are off.  
> 
> BUT....  That's true about any information which is stored in a directory.
> Not just about my private key.  From a company's perspective, there are
> far worse things that someone can do with physical access to a server than
> to pose as one of their employees.  So, a company would (hopefully) screen
> people a bit before giving them the keys to the kingdom.
> 
> It certainly seems reasonable for me to store the encrypted private key
> that I use for business purposes in the directory that my company
> maintains.  But, would I store the encrypted private key that I use for my
> on-line banking there?  I think that I'd have to weigh the pros and cons.
> On one hand, if I store it in the directory, I can use it even if I don't
> have my smart card and I never have to worry about losing it.  On the
> negative side, some administrators could, potentially, pose as me.  If I
> stored it in a smart card, I have control over it.  But, how well do I
> guard my wallet against theft?  How often do I lose it?  Anyone who
> finds/steals my smart card could break the PIN number and pose as me.  
> 
> The choice seems to be about how much I trust myself as opposed to the
> company whose directory I'm using.  There's no right answer here.  Both
> have their vulnerabilities.  Both have their shortcomings.  It all seems
> to boil down to:  Who do you trust?  and   What kind of availability do
> you need?
> 
> Tammy Green Carter
> 
> 
> >>> Stephen Kent <[email-masked]> 2-1-99 3:14:41 PM >>>
> Tammy,
> 
> >You asked about storing the private key.  Currently, Novell's PKI
> solution
> >encrypts the private key and stores it in the user's object.  The private
> >key is encrypted with a partition specific key such that each server
> >holding a replica of the partition in which the user's object resides can
> >decrypt the private key.  We use ACLs provided by the directory (NDS in
> >our case), to keep unauthorized people from reading the private key.  For
> >those users who don't trust the directory or their administrators, we are
> >working on a solution which will store the private key on a smart card.
> >When smart cards come along, the obvious place to store the chain is on
> >the smart card, eliminating these issues altogether.
> 
> I'm surprized by the description above, if I understand it.  Why is the
> private key for a user accessible to anyone but the user?  Letting
> directories have access to that key seems like a very a serious security
> problem.  Even when smart cards are more widely used, their storage is
> limited, so you may find it appropriate to keep private keys and certs, as
> well as cert chains, in a directory object, on a per user basis, so that
> this info ca  be downloaded and the appropriate private keys moved into
> the
> user's smart card, as needed.
> 
> Steve

Date: Wed, 03 Feb 1999 15:26:58 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

This discussion has kicked off several subthreads, and I'd 
like to comment on a couple of them.

With respect to the private keys, regardless of where the key 
is generated, there are several places where it could be stored --
on a smart card (perhaps where it was generated), on a floppy disk 
or password protected file on the user's workstation, or on some 
server, notably a directory server.

Each of these storage locations has advantages and disadvantages,
depending on the security of the systems involved and the use of the key.

In the case of the smart card, if I lose it or leave it at home I can't get my
work done, and in order to assure the continuity of the business if something
happens to me, a copy of my encryption keys are almost surely going to 
have to be stored elsewhere as well.  In addition, if I use multiple 
machines, e.g. my desktop workstation, my laptop, and my home machine, 
I may need to have multiple smart cards if I use more than one at a time.

In the case of the floppy disk or the password-encrypted file on a hard disk, 
the same concerns apply.

But if I put the private key in my company's directory (note that I am not assuming 
some untrusted, unrelated third party directory provider such as an ISP or telco),
and assuming I go though an encrypted and authenticated logon process that 
at least uses my password to securely authenticate me to the directory, then the 
company that owns the data and owns the server and probably needs a 
backup copy of my key has access to it.  So what -- they have the key to my 
office and my desk as well. At least this allows me to use any computer that I trust 
adequately, anywhere in the facility or even remotely, to decrypt or even sign my data.

If the server uses a secure hardware crypto facility, then the keys can be protected 
just about as well as can be, given the fact that I am probably using them in
the clear within my untrusted workstation in any case.  Even if the server uses 
software crypto, the master key storage key is presumably obfuscated as well as it
can be without requiring another secret key, and is stored in a file to which ordinary user programs don't have access.

Now, would I trust my personal private encryption key to my company directory, the 
one I use to encrypt my love letters to my mistress, or anything else I don't want 
anyone else o know about? Absolutely not!  But I also wouldn't compose such a 
document on my company owned workstation, especially since the system 
administrator can and often does download new copies of the software onto 
my machine without my permission or even knowledge.

Likewise, would I trust my system administrator with a copy of my private
digital signature key, even if that key was only supposed to be used 
for company business?  Again, no way. Someone might forge my signature to
some hate mail sent to the CEO, or change the beneficiary for my life insurance,
or even withdraw funds from my 401K, so that would be intolerable.

For that reason, although a system administrator for Novell's NDS directory
may be able to change the rights to my user object so that he could 
access my key, in the case of a digital signature key the act of allowing 
access to someone else also destroys the old key, so that nonrepudiation 
is maintained.  

With respect to Tammy's question about how best to store a certificate chain 
in the directory, there was an implicit assumption that should probably be 
made explicit -- directory performance issues would tend to strongly discourage 
repeatedly walking the certificate hierarchy to retrieve each certificate in the chain, 
especially if the chain is more than one or two certificates in length.

In addition, there is another problem that is not quite so obvious, and that concerns
directories that are not necessarily fully interconnected.

Ideally, every X.500 directory in the world would know about every other one, and 
they would all be interconnected and share precisely the same schema for DNs, etc.

But that isn't going to happen any time soon, if at all.

So it isn't necessarily the case that the subscriber and the relying party share a 
common directory, or even that the subscriber and the CA that issued the certificate 
share a common directory.  One of the CAs in the certificate chain might not even 
_have_ a directory.

So what is the poor subscriber or relying party to do?

Well, one solution would be to import all of the certificates in the chain, and to stash 
them in the user's directory under the DN in each certificate, and if necessary create a new subtree in the DIT to accommodate that entry.  Unfortunately, some directory 
administrators may be somewhat unsympathetic to that problem, especially if it means 
changing the directory schema, etc.

Another solution if the directories were interconnected would be to either chain or refer to 
the other directory, but that might not be feasible if one directory doesn't know the
details of where the other directory is located, its DNS name and port number, etc.
(Isn't it interesting that we have define referral mechanisms to tell the relying party
where to find the CRL or OCSP provider, but not the Issuer's directory?)  

Unfortunately, the performance hit in this case would be even worse than in the 
local directory. 

So it appears that we need to be able to store an entire chain of certificates in one place,
presumably associated with the user's object. So what kind of attribute should be used, and where should it be located?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> "Tammy Carter" <[email-masked]> 02/03/99 02:00PM >>>
Steve,

Generally speaking, information which is stored in a directory is accessible only to those people who are granted explicit access rights.  And, by default, only the user would be given rights to his encrypted private key stored on his own object.  Thus, the user would have to specifically gave someone else rights to access his private key.  

However, those administrators with direct access to the directory database wherein my object resides could give themselves rights to my private key.  Or copy it for an off-line attack on the encryption.  Or even change it.  When my encrypted private key is stored in the directory, it is vulnerable to anyone who can get to a server which holds a copy of my object.  As we are fond of saying here - - Once someone has physical access to the server, all bets are off.  

BUT....  That's true about any information which is stored in a directory.  Not just about my private key.  From a company's perspective, there are far worse things that someone can do with physical access to a server than to pose as one of their employees.  So, a company would (hopefully) screen people a bit before giving them the keys to the kingdom.

It certainly seems reasonable for me to store the encrypted private key that I use for business purposes in the directory that my company maintains.  But, would I store the encrypted private key that I use for my on-line banking there?  I think that I'd have to weigh the pros and cons.  On one hand, if I store it in the directory, I can use it even if I don't have my smart card and I never have to worry about losing it.  On the negative side, some administrators could, potentially, pose as me.  If I stored it in a smart card, I have control over it.  But, how well do I guard my wallet against theft?  How often do I lose it?  Anyone who finds/steals my smart card could break the PIN number and pose as me.  

The choice seems to be about how much I trust myself as opposed to the company whose directory I'm using.  There's no right answer here.  Both have their vulnerabilities.  Both have their shortcomings.  It all seems to boil down to:  Who do you trust?  and   What kind of availability do you need?

Tammy Green Carter

>>> Stephen Kent <[email-masked]> 2-1-99 3:14:41 PM >>>
Tammy,

>You asked about storing the private key.  Currently, Novell's PKI solution
>encrypts the private key and stores it in the user's object.  The private
>key is encrypted with a partition specific key such that each server
>holding a replica of the partition in which the user's object resides can
>decrypt the private key.  We use ACLs provided by the directory (NDS in
>our case), to keep unauthorized people from reading the private key.  For
>those users who don't trust the directory or their administrators, we are
>working on a solution which will store the private key on a smart card.
>When smart cards come along, the obvious place to store the chain is on
>the smart card, eliminating these issues altogether.

I'm surprized by the description above, if I understand it.  Why is the
private key for a user accessible to anyone but the user?  Letting
directories have access to that key seems like a very a serious security
problem.  Even when smart cards are more widely used, their storage is
limited, so you may find it appropriate to keep private keys and certs, as
well as cert chains, in a directory object, on a per user basis, so that
this info ca  be downloaded and the appropriate private keys moved into the
user's smart card, as needed.

Steve

Date: Wed, 03 Feb 1999 14:22:00 -0700
From: "Tammy Carter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

Alan,

You bring up an interesting idea.  Perhaps, instead of caching the certificate chain on the user's object, the user should be selectively caching directory objects which could be periodically refreshed.  The question is:  If such a mini-directory were provided on a client, would applications take advantage of it?  Would my email package be able to go and look there for certificates rather than turning to a personal address book?

Perhaps, but the "personal address book" or some kind of certificate repository would still be necessary in some cases.  People who use CAs which are external to their tree (e.g., VeriSign, or even CA's in a different tree) would still need to cache the certificate(s) necessary to make up a certificate chain for inclusion in an S/MIME message since these certificates may not always be easy to get to.

Interesting notion to download portions of the directory to the client....  Rather than doing LDAP off of your client, you could do it to access the locally cached directory.  Interesting.....

Tammy Green Carter

>>> Alan Lloyd <[email-masked]> 1-31-99 4:20:45 PM >>>

<snip>

I think the two biggest areas that need to be applied into the theory of
PKI is 
a) There is a business/trust/cost model which will be operationally
driven - that the theory of PKI will have to fit into. And
b) In many, many cases, that this will be applied to a distributed
directory service.

I think the notion that all certs, CRLs and all user information will
fit in one server or Database which is accessed by LDAP or OCSP on its
own is the same as designing a big central mainframe system - something
a few of us did 25 years ago! :-)

So in answer to your question - caching. I have an X.500 directory on my
notebook which can be a) Part of the companies DIB for which I am
responsible for - a locally maintained - distributed component. AND a
replicated part of the companies DIT which I extract for my own purposes
in order to do my job. This is centrally managed. In all this keep all
the info necessary to support my moble env.

The issues to me are stated above. Its the knowledge of potential
recipients, what domains they work in and what policies and mechanisms
they use for validating me. Such info and control has to be external to
my environment and in a commonl information  infrastructure - a
directory.

Hope this helps with the debate
regards alan

> -----Original Message-----
> From:	Tammy Carter 
> Sent:	Friday, January 29, 1999 11:09 AM
> To:	< ; [email-masked]; [email-masked] 
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> Hi, Alan,
> 
> Thanks for clarifying.  It _is_ incorrect to say that an entire
> directory is off-line.
> (Well, unless all the server's holding replicas have all gone down at 
> exactly the same moment.)  
> 
> What I was referring to was more the inability of the user to read the
> set of
> objects from which a chain can be constructed.  This inability could
> be caused by network outages (planned or unexpected), a bad
> replication scheme, or even the inability of the client to communicate
> with the necessary servers using the right protocols.
> 
> For example, picture a company's tree that spans the world.  Servers 
> are on every continent.  I have a certificate, stored on my user
> object.  
> I travel to China for a month of consulting in our branch office.  My 
> administrator, thinking ahead, puts a replica of the partition
> containing
> my user object on a server in China so that a copy of my object is
> being maintained locally.  Now, I want to send email and I need to
> send a certificate chain with my S/MIME message.  My CA has an
> object in the tree, but only Utah servers hold replicas of it's 
> partition.  Unfortunately, due to network problems, I can't get
> to my CA's object.  
> 
> It would seem reasonable to store a cached copy of the user's
> certificate chain on their object rather than forcing the user to
> store it on the client's file system, or on a floppy disk.  This
> allows a "free seating policy" so that users can go to any
> client and perform their job functions without having to carry
> around floppy disks.
> 
> My initial question was:  has anyone thought of caching this
> information in the directory yet?  If so, what attributes are being
> used?
> 
> 
> Tammy Green Carter
> [email-masked] 
> 
> 
> >>> Alan Lloyd <[email-masked]> 1-28-99 3:03:33 PM
> >>>
> Some comments
> 
> This debate seems to say that a directory tree is unavailable and
> therefore local caching is used. It would strike me that a major part
> of
> the system design of an organisation's information system. eg HR,
> database or PABX or RADIUS directory,  that replica's are placed at
> certain points to avoid service failures. Although there are major
> functional distinctions between a database, a file system, a directory
> service, etc. The system design and operational deployment of all of
> these things makes sure that service levels are maintained. Saying
> that
> "a directory" is off line is like saying a database is off line or the
> file server is off line. I would expect that a User who is mobile to
> contain on their local directory/file system all the things that
> support
> that environment eg address books, mail boxes and a bunch of keys and
> certs..which can be replica entries of the CAs system.

Date: Wed, 03 Feb 1999 14:00:39 -0700
From: "Tammy Carter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Attribute used to store cached certificate chains?
Sender: [email-masked]

Steve,

Generally speaking, information which is stored in a directory is accessible only to those people who are granted explicit access rights.  And, by default, only the user would be given rights to his encrypted private key stored on his own object.  Thus, the user would have to specifically gave someone else rights to access his private key.  

However, those administrators with direct access to the directory database wherein my object resides could give themselves rights to my private key.  Or copy it for an off-line attack on the encryption.  Or even change it.  When my encrypted private key is stored in the directory, it is vulnerable to anyone who can get to a server which holds a copy of my object.  As we are fond of saying here - - Once someone has physical access to the server, all bets are off.  

BUT....  That's true about any information which is stored in a directory.  Not just about my private key.  From a company's perspective, there are far worse things that someone can do with physical access to a server than to pose as one of their employees.  So, a company would (hopefully) screen people a bit before giving them the keys to the kingdom.

It certainly seems reasonable for me to store the encrypted private key that I use for business purposes in the directory that my company maintains.  But, would I store the encrypted private key that I use for my on-line banking there?  I think that I'd have to weigh the pros and cons.  On one hand, if I store it in the directory, I can use it even if I don't have my smart card and I never have to worry about losing it.  On the negative side, some administrators could, potentially, pose as me.  If I stored it in a smart card, I have control over it.  But, how well do I guard my wallet against theft?  How often do I lose it?  Anyone who finds/steals my smart card could break the PIN number and pose as me.  

The choice seems to be about how much I trust myself as opposed to the company whose directory I'm using.  There's no right answer here.  Both have their vulnerabilities.  Both have their shortcomings.  It all seems to boil down to:  Who do you trust?  and   What kind of availability do you need?

Tammy Green Carter

>>> Stephen Kent <[email-masked]> 2-1-99 3:14:41 PM >>>
Tammy,

>You asked about storing the private key.  Currently, Novell's PKI solution
>encrypts the private key and stores it in the user's object.  The private
>key is encrypted with a partition specific key such that each server
>holding a replica of the partition in which the user's object resides can
>decrypt the private key.  We use ACLs provided by the directory (NDS in
>our case), to keep unauthorized people from reading the private key.  For
>those users who don't trust the directory or their administrators, we are
>working on a solution which will store the private key on a smart card.
>When smart cards come along, the obvious place to store the chain is on
>the smart card, eliminating these issues altogether.

I'm surprized by the description above, if I understand it.  Why is the
private key for a user accessible to anyone but the user?  Letting
directories have access to that key seems like a very a serious security
problem.  Even when smart cards are more widely used, their storage is
limited, so you may find it appropriate to keep private keys and certs, as
well as cert chains, in a directory object, on a per user basis, so that
this info ca  be downloaded and the appropriate private keys moved into the
user's smart card, as needed.

Steve

From: [email-masked]
Date: Wed, 3 Feb 1999 10:44:32 -0500
Subject: Call for Papers: Fourth ACM Workshop on Role-based Access Control
Sender: [email-masked]

CALL FOR PAPERS
Fourth ACM WORKSHOP ON ROLE-BASED ACCESS CONTROL
Date: Oct. 28-29, 1999
Place: George Mason University
url: www.list.gmu.edu/rbac

Sponsored By: ACM Sigsac
Hosted By: George Mason University

The essence of Role-Based Access Control (RBAC) is that permissions
are assigned to roles rather than to individual users.  Users acquire
these permissions by virtue of being authorized to act in these roles.
The driving motivation for RBAC is to simplify security policy
administration while facilitating the definition of flexible,
customized policies.  Basic RBAC models have been successfully applied
since the mainframe era, but emerging systems, which have greater
numbers of users, roles, and systems, challenge the expressive power
of these traditional models.

Workshop Scope:

The ACM workshops on RBAC bring together researchers, developers, and
practitioners to discuss the application of RBAC to both traditional
and emerging systems and the development of new access control
paradigms for future applications.  The workshop invites participation from
the database, network, distributed systems, operating systems, security and
application communities.  Contributions reporting experiences with the
implementation and use of RBAC systems are strongly encouraged.
Attendance is limited to 40 participants to foster a workshop atmosphere.

Topics of interest include, but are not restricted to:

- Modeling and specification of RBAC systems
- Administration of RBAC systems
- RBAC in database security
- Specification and enforcement of security policy
- Delegation and inheritance of access rights in RBAC systems
- Task-based access control and RBAC in collaborative environments
- Application Areas e.g., health-care, WWW
- Support for RBAC in traditional access control systems
- RBAC and organizational control principles
- Experiences with RBAC-based systems; case studies
- Enabling technologies: Java, LDAP, intra-net environments
- Implementation, integration and scalability of RBAC
- End-user tools to support RBAC administration and engineering

Submissions:

Users, developers and researchers are invited to submit seven copies
of their papers (in English and limited to 6000 words) to the Program
Chair at the coordinates given below before the due date.  Submissions can
be either hard copy or electronic (postscript preferred). Papers must be
original and should not be under consideration for publication
elsewhere.  Copyrights for accepted papers must be transferable to ACM
(except for Government work).  Papers will be published by ACM in a
proceedings to be distributed at the workshop and mailed to all SIGSAC
members.  Outstanding papers will be considered for publication in ACM's
new Transactions on Information and Systems Security (TISSEC).

Proposals for panels and group discussions should be sent, preferably
by email, to the Panels Chair at [email-masked].

Paper Submissions should be sent to:
Sylvia Osborn, Program Committee Chair,
Dept. of Computer Science,
The University of Western Ontario,
MC355,
London, Ontario, Canada, N6A 5B7
email: [email-masked]

SCHEDULE:
Papers and Panel Proposals Due: May 15, 1999
Notification of acceptance and advance program: June 30, 1999
Deadline for final version of papers: July 31, 1999
Workshop: October 28-29, 1999

CONFERENCE STEERING COMMITTEE:
Ed Coyne, Science Applications International Corporation
David Ferraiolo, National Institute of Standards and Technology
Trent Jaeger, IBM T.J. Watson Research Center
Sylvia Osborn, The University of Western Ontario
Ravi Sandhu, George Mason University
Charles Youman, Blue Cross Blue Shield

General Conference Chair: Charles Youman, Blue Cross Blue Shield
Local Arrangements: Srinivas Ganta, CygnaCom Solutions Inc.
Program Committee Chair: Sylvia Osborn, The University of Western Ontario
Panels Chair: David Ferraiolo, National Institute of Standards and
Technology
Proceedings Chair: Vijay Atluri, Rutgers University
Publicity Chair: Trent Jaeger, IBM T.J. Watson Research Center

PROGRAM COMMITTEE:

Vijay Atluri, Rutgers University
Dave Ferraiolo, National Institute of Standards and Technology
Luigi Giuri,  Fondazione Ugo Bordoni
Trent Jaeger, IBM T.J. Watson Research Center
Carl Landwehr, U.S. Naval Research Laboratory
Emil Lupu, Imperial College
Ravi Sandhu, George Mason University
Richard Simon
Roshan Thomas, TIS Labs at Network Associates
Dan Thomsen, Secure Computing Corp.
Dan Wallach, Rice University

REGISTRATION:
Information on registration and accommodations will be provided.
There will be a registration fee for all participants to cover meeting
costs.

From: Andrew Probert <[email-masked]>
To: "'Alan Lloyd'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: FW: Attribute used to store cached certificate chains?
Date: Wed, 3 Feb 1999 17:21:39 +1100 
Sender: [email-masked]

I think a re-statement and perhaps some may think oversimplification of the
case is as follows: -

CRLs are a batch method for publishing CRLs and we are agreed that an online
realtime mechanism is required.
A client navigating to a single OCSP server looks ok.
When there are myriad of OCSP servers, the job becomes far more complex.
A rationalisation of this is to have a single OCSP server that via backend
protocols talks to other OCSP servers on the users behalf.

It is at this point that the engineering complexity explodes with the Y.A.P.
principle i.e. lets invent yet another protocol, with attendant problems of
information and knowledge engineering.

The point of the X.500 protocols i.e. DSP, is that they have already got in
place the heavy engineering to route queries between the back-end servers (a
feature that even the ubiqutious Web servers do not have).  There are all
sorts of interesting feature like hop counters to ensure queries don't loop
around the world.  There are multi-cast features to ask all servers,
concurrently, do they have the items of interest.  The protocol is
extensible with regard to objects and their attributes and even to
supporting proprietary services.  There is strong authentication between end
users and the servers and servers to servers.

If the end point is to have an infrastructure for PKI that can route queries
between trusted servers, then in my opinion this can be achieved at a lower
development cost by extending a protocol and services that already exist,
using product implementations that already exist and have all of the
operational niceties like diagnositics and operational management built-in
(which is the next engineering issue after you get the protocols actually
working).

A *real* issue is percieved cost of development and not-invented-here
syndrome as a vendor can create a new protocol from scratch, at a perceived
lower entry cost rather than going up the learning curve on a richly
featured (downside complexity)
standard.

The alternative is that you see things like the LDAP API simplification,
followed by many iterations of versions to get it back to where the DAP
standard started years ago, with many $$$ of development burnt in the
process.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Alan Lloyd [SMTP:[email-masked]]
> Sent:	Wednesday, February 03, 1999 12:28 PM
> To:	'Bob Jueneman'; [email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: FW: Attribute used to store cached certificate chains?
> 
> A comment
> 
> > -----Original Message-----
> > From:	Bob Jueneman 
> > Sent:	Wednesday, February 03, 1999 7:31 AM
> > To:	[email-masked]; [email-masked]
> > Cc:	[email-masked]
> > Subject:	Re: FW: Attribute used to store cached certificate
> > chains?
> > 
> 	snip
> 
> > In my view, the distinguishing characteristic that differentiates a
> > directory from
> > a repository is that a directory reflects a snapshot of a world-view
> > at a
> > more or less current instance in time, whereas a repository attempts
> > to
> > maintain a reliable historical record.
> > 
> 	A directory service - is a distributed information system which
> has an information doctrine. In terms of its characterisation by X.500 -
> it is object oriented, has an authentication and access control regime,
> has a common schema and information management model and offers both
> distribution and replication facilities in order to satisfy ownership
> and administration as well information service levels. A directory is a
> protected object oriented distributed name based transaction system
> which operates on knowledge.
> 	A repository may in its comercial implementation have some of
> the above features. However, I don see to many standards for
> "repositories". So they tend to be related to central storage /DB type
> systems.
> 	A directory service can be used as an archive. In fact the
> archive component can in fact be part of the DIB.
> 
> 	regards alan

From: Alan Lloyd <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: FW: Attribute used to store cached certificate chains?
Date: Wed, 3 Feb 1999 12:27:35 +1100
Sender: [email-masked]

A comment

> -----Original Message-----
> From:	Bob Jueneman 
> Sent:	Wednesday, February 03, 1999 7:31 AM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	Re: FW: Attribute used to store cached certificate
> chains?
> 
	snip

> In my view, the distinguishing characteristic that differentiates a
> directory from
> a repository is that a directory reflects a snapshot of a world-view
> at a
> more or less current instance in time, whereas a repository attempts
> to
> maintain a reliable historical record.
> 
	A directory service - is a distributed information system which
has an information doctrine. In terms of its characterisation by X.500 -
it is object oriented, has an authentication and access control regime,
has a common schema and information management model and offers both
distribution and replication facilities in order to satisfy ownership
and administration as well information service levels. A directory is a
protected object oriented distributed name based transaction system
which operates on knowledge.
	A repository may in its comercial implementation have some of
the above features. However, I don see to many standards for
"repositories". So they tend to be related to central storage /DB type
systems.
	A directory service can be used as an archive. In fact the
archive component can in fact be part of the DIB.

	regards alan

From: Alan Lloyd <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Alan Lloyd <[email-masked]>
Cc: [email-masked]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Wed, 3 Feb 1999 10:21:22 +1100
Sender: [email-masked]

Comments in line.

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Wednesday, February 03, 1999 2:53 AM
> To:	Alan Lloyd
> Cc:	[email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> 
> Let metry to condense our debate to spare the rest of the list from
> reading
> lost of text:
> 
> 1. You state that "in addition to signing data, we can also place
> >"some" trust on the distributed authentication and access controls of
> >the directory system. Particularly when the user or certficate reader
> >has been requested to do strong authentication on the directory
> service
> >itself to read the CA entry. We do deal with trusted directory
> systems
> >you know."
> 
> You also say "And in the case where this extra strengh is needed we
> can do
> >strong auth and signed ops on the directory service.. with DAP - you
> >know the protocol thats half the size of LDAP with twicw as many
> feature
> >including trusted signed operations."
> 
> This line of argument seem to ignore the fact that the vast majority
> of
> successful, detected attacks against computers of any sort are
> effected
> through exploitation of design, implementation, or management
> vulnerabilities that are NOT prevented through the use of cryptography
> for
> communication security, including signed directory operations.  This
> characteristic has been true for the last 20+ years and is well
> documented
> through analysis of CERT advisories.  A vast set of directory
> resources
> provides an obvious target and if one were to adopt the approaches you
> promote, which place ever greater reliance on these resources, the
> value of
> these targets grows enormously.  That is why signing data that is
> stored in
> any repository, and not relying on secure management of a set of
> repositories, is a preferred security paradigm.
> 
	I got confused with your logic in this  debate  - are you
agreeing with me. 

	If you want to talk threat to large scale systems I will. And
yes all threats to systems are generally operational ones (cutting
cables, power, sand in the fuel line etc.)
	In military we have a term - a big system is a big target. Eg.
the Internet, the Telephone network... However, that does not stop them
being built. So we tend to follow through threat analysis with risk
assessment, risk avoidance and risk acceptance. After all, even  living
is a risk :-).

	To debate signed data as being the preferred paradigm and saying
putting that in a secure or insecure large scale repository ( a
directory service)creates an operational risk - (which is obvious) so
dont build one... seems a pointless statement. For the cryptographically
protected information to have any UTILITY AT ALL in a large scale
system,   it has to be provided by something in a way that can be found
by those distributed users who wish to use it.

	Also note  and please do note that a directory is a distributed
information function - that provides greater utility than conventional
databases. One of these can be used in a Top secret env, many can be
used privately on a restricted network or thousands can be used on low
value, high volume transaction , global service systems. The
trust/cost/risk/integrity and threat issues of these  are all
operational/project/deployment issues.. and have very little to do with
with the details of a signed cert or cRL (although they do factor in the
debate).
	ie do I use Type 1 algorithms to sign certs but leave the power
switch for the CA visible on the road side.
	 
> 2. Later, in response to my observation that the phone system is not a
> great analogy for the global, distributed directory system you
> envision you
> say "We need to talk re the two paradigms. Many people find the phone
> system/directory system paradigm very useful. As for infrastructures.
> They
> tend to be in fact very big systems>- by definition. If OCSP wants to
> be
> big - it will become an>infrastructure - but if it wants to be big it
> will
> have to be supported by a big distributed information base... some
> thing
> like a directory
> service. Otherwise its hand carved..."  This response seems to ignore
> all
> of the details of my argument of why the phone system is a poor
> analogy,
> and the vast evidence of the fragility of this and analogous
> infrastructures.  I refer you to the recent "Trust in Cyberspace"
> report by
> the (U.S.) National Academy of Sciences, which makes similar point.
> Of
> course, as a member of the committee that wrote the report, I may be
> prejudiced :-). Also, your comment about the growth of OCSP seems to
> focus
> on ONE way of using it, namely having a network of TTPs act as oracles
> for
> queries about certificate status or validity.  This is not the only
> model
> for OCSP, and it is not the one that prompted the development of OCSP.
> If
> CAs operate OCSP responders for the certs that they issue, there is no
> need
> to create the sort of highly vulnerable infrastructure you seem to
> propose.
> 
	See conmments above. Again the logic confuses me. I will always
agree that one can build a small system without an infrastructure. :-)
In fact a small system is not an infrastructure :-))) ... One can put a
dozen OCSP servers around a CA - not a problem. 
	However if one want to run a business level system with
tranactions and users that are verified for business products/ access
with profiles  for global use- what is the information model, who/what
administers it, how is it distributed and deployed, what is the
busines's product, customer and inter-oganisation acquisition strategy
and what are the information policies and procedures that deal with
that....These are the system issues..

	Where does this "information" stuff live - in a commercially
optimised way....

	Big systems are infrastructure, by definition. And threats are
always on them. This does not mean that because of theoretical ideology
we will always build small ones. PKI systems and directories means that
infrastructure, large scale PKI systems can be built ( may be not for
everything) but there is a big market for them - because they are big
systems - and as everyone knows, the engineering processes in small
systems eg LDAP is a lot different to big ones (distributed directory
services)

> OCSP servers operated by CAs, vs. outsourcing OCSP services for a CA
> to a
> TTP, don't concentrate vulnerabilities, they distribute them.  So,
> depending on the model one envisions, OCSP may be fine froma  security
> standpoint, or it can be made into another disaster waiting to happen.
> 
	Operational and system design issues... Can debate this for
ever, if all we have to argue with is a protocol spec and a signed data
item.

> 3. In our discussion about the nature of OCSP support, you state "How
> many
> OCSP servers will be needed for 100m users. What is the information
> system
> that supports this?"  Again, this seems to confuse your model for OCSP
> use
> vs. other approaches, as noted above.  We both agree that distributed
> directories are a good and necessary part of most PKIs; the issue is
> whether we should use them in a fashion that creates new
> vulnerabilities.
	See above. 

> 4. I stated that "What it seems to boil down to is an assertion by
> you that directories will be ubiquitous, very fast, ultra reliable,
> and sufficiently secure so that we should abandon the crypto-integrity
> model upon which X.509 is based." You responded "Thats it. Got it in
> one.'
> well, it is nice to be clear on this point. However, you have not
> provided
> a set of coherent, comprehensive arguments to presuade me to believe
> that
> your assertion. Insetad, the argument seems to be that of course it
> will
> happen becauise it must happen to enable the future and because the
> use of
> such serves is being actively "promoted."  This does not sound like an
> architecture to me; it sounds like a marketing pitch from a seller of
> directory technology and/or services.  This is the PKIX WG mailing
> list.
> We try to develop standards for PKI technology that based on sound
> architectural principles, period.
> 
	Agree - standards are good - I have been involved with standards
for ISO/ITU for 20 years, the military for 8, transport and traffic
management for 4 and the IETF for about 8. However please note that  a
set of ASN.1 data definitions is not a system architecture.
	A standard eg. X.500 is 20% of a product which is 20% of the
effort in a deployable system.

	Let me get these points over.
	1. X.509 is part of X.500 - why. X.500 - the directory service
supports the distributed authentication process and domain level access
controls which are needed in a distributed business environment.

	2. A directory service when applied to systems provides an User
and Information Services approach to system design by definition because
thats what a directory holds...  the User/Subsciber information base as
well as the data models and objects for the products/services being
used.

	3. When one designs around a protocol and a database, one is
designing a communication and data system. When one uses a directory
service approach one is designing a distributed information SERVICE
which is full scaleable, has built in protection capabilities, a common
information model, a common information management model and a common
security paradigm.
	When applying a directory service to a system design one needs
to take a totally different approach to that design to that of using
databases and protocols. Because a directory service  is more than that.
IT system design approaches HAVE evolved to meet the business and
information management requirements of the global user and customer. It
is wrong to compare this approach with a protocol/server/database
approach.

	4. If I wanted to pitch the product -  I would not be talking
large scale system issues, development approaches and standards.

	5. The Internet and its technologies is being integrated with
voice systems and being applied to commercial use. The customers dictate
that a system solution must be applied on this. Inventing more protocols
has its place - but there is a lot more work going on around the
Internet than that.

> 5. Finally, in response to my complaint that your proposals would
> degrade
> the security of PKIs, you respond "No infact we are enhancing the PKI
> with
> the reality of deployed directory systems. A PKI without a business
> purpose
> and information and service deployment scaleability will be an orphan
> technology."  This does not respond to my point.  It deflects the
> question
> by asserting, again without substantiation, that yours is the
> ONLY/BEST
> approach to achieving scaleability, and it makes the highly
> questionable
> claim re the reality of deployed directory systems.  We don't conduct
> debates on this list based on assertions about the inevitability of a
> partciular solution; we debate proposals based on their merits.
> 
	Please define what you mean by scale and approaches to scale. If
one is in the PKI and information services business and writing
standards for PKI - which must have a named - globally named information
components what is the database/protocol that you use that does "scale"
- 

	why does the phone system have a directory service?
	why are all the PKI vendors on this planet embracing
directories?

	what is the debate here. 
	Is it small systems can be designed in way that makes them small
	and that some systems can use a protocol/database approach - but
weve done that for 20 years and these do work but have scaling issues
	and that when one builds a secure information service that needs
to scale globally - it will be an infrastructure and use directories and
that the approaches to this are different to that of traditional
methods.

	regards alan

> Steve

Date: Tue, 02 Feb 1999 13:53:01 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: FW: Attribute used to store cached certificate chains?
Sender: [email-masked]

I like Peter's contribution as well as Steve's, although it is 
interesting to see how people's perspective may change as 
they change employers (or vice versa).

My earlier comments regarding the desirability of associating
nonrepudiation evidence with the document itself, at least for
the sake of simplicity, should not be interpreted as casting
aspersions on either repositories or validation services, which
presumably have their place in the business world.  

When was talking about the "relying party," I should not have 
implied that that function necessarily rested exclusively with
the individual who decided to accept the transaction at the time,
for that individual might have left the company or decided to 
repudiate his own actions when push came to shove.
For important, company-related transactions, the company as 
relying party should take whatever steps are necessary to 
preserve the necessary information from destruction or alteration.

Of course, it sometimes happens that an individual who takes 
some action is later accused (at least in his eyes) of either 
doing or not doing something.  In that case, the individual is 
potentially yet another relying party, and in that case it might 
behoove him to keep his own set of records, in case the 
company decides to purge its files of some inconvenient fact.

If the company is viewed as the exclusive "owner" of the data,
and if the nonrepudiation information is under their exclusive
control (whether subcontracted out or not), the employee might
not have any recourse or evidence unless he kept his own copy
of all of the necessary information.

For examples of this kind of ugliness, look at almost any notorious
whistle-blowing case, and the increasing tendency of corporate 
counsel to urge a complete and ruthless purge of all e-mail more 
than a few months old.

Bob

>>> "Peter Williams" <[email-masked]> 02/02/99 11:14AM >>>
A contribution to the issue:-

There is a difference between system design
for caching trust information to achieve performance
improvement or control trust-policy enforcement, and
storage of transactional data after the fact of
signature verification and certificate-chain validation.

Responsibility for maintenance of transactional
data is the current thread topic.  In the enterprise context, does
it fall to the individual or the company? For whom is the reliability of
access to the data critical, asks the risk management professional?

In the private key escrow (renamed key management)
debate, we learn from govts that no individual can be trusted
by the corporation to control the private key in
the ultimate interests of the company. Third-party escrow
is a required feature of the corporate environment,
therefore. The users system must be denuded of
potential capability to compromise such a corporate
requirement,  in consequence.

Using a similar logical argument, if a *companies* validation
of a signed transaction is performed by an individual, surely
the company cannot trust the individual to maintain
the accurate logs/data/context on the historical
information, should that data be required as proof-basis/evidence
in the future.  Therefore, a company-maintained
repository of transaction reconstruction/audit data
is required, just as centralized, mandatory key recovery is
required to ensure business continuation capability.

This argument strongly suggests that *enterprise-based*
verification/transaction-reconstruction services will be required.

I would, however, disagree that it is necessarily the enterprise CA which
performs such a mandatory repository function, however. Many
companies could outsource this function today to such providers
as Surety. Though reliability-critical, such "safe storage" (with
optional notarization) is not especially security critical in the sense
of the specific technical risks which the enterprise CA manages when
issuing valid certificates.

Peter.
    -----Original Message-----
    From: Stephen Kent <[email-masked]>
    To: WHenry <[email-masked]>
    Cc: [email-masked]' <[email-masked]>; [email-masked]' 
<[email-masked]>
    Date: Tuesday, February 02, 1999 10:23 AM
    Subject: Re: FW: Attribute used to store cached certificate chains?

    Bill,

    >Maintaining a copy of a user's certificate chain has implications for
digitally signed archives, as well.
    >
    > In the case of an archived (and signed) document, should the document
itself retain a copy of the certificate >chain to aid in validation? Or will
PKI's/Directories support future path validation for archived documents?
    >
    > Thoughts/comments?

    I've always been of the school that calls for a relying party to take
responsibility for acquiring and retaining the certs and CRLs, and
timestamping them, to support a future repudiation problem. After all, only
a relying party knows how long to keep this data, and this model parallels
what we do in the physical world (outside of the Latin Notaire context).
But, some folks object to this notion and want CAs or others to provide
these services for them, so there is no single right answer here.

    Steve

Date: Tue, 02 Feb 1999 13:30:33 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: FW: Attribute used to store cached certificate chains?
Sender: [email-masked]

I agree with Steve on this.  The simple, obvious, reliable, (but perhaps
inelegant) solution to non-repudiation of an archived document is 
for any and all interested parties to take the responsibility themselves
for archiving the certificate chain and CRLs, etc., along with the 
document itself.

This approach is almost idiot-proof.  Alternative schemes, such
as trying to save storage space by collecting the certificates (and CRLs,
which are time-dependent and hence likely to be unique per document), 
and associating a use count and/or "document-owner", are likely to
fail if someone deletes other documents that refer to the same certificates 
and the use count gets messed up somehow.

In my view, the distinguishing characteristic that differentiates a directory from
a repository is that a directory reflects a snapshot of a world-view at a
more or less current instance in time, whereas a repository attempts to
maintain a reliable historical record.

The Y2K problem has reemphasized a lesson that a gifted instructor at IBM's 
System Research Institute taught me more than 30 years ago -- that memory 
is the _least_ costly component of a system, when you count the true cost of 
trying to optimize the memory utilization.  If that observation was true in 1966,
it is most certainly true now.  (If the horse she was riding in Central Park hadn't
thrown her and broken her neck, maybe a few more people would have paid
attention, and we wouldn't be facing the problems we are today.)

A relying party may choose to try to save disk space by optimizing the 
necessary nonrepudiation information, or by contracting out such 
functions, but if they don't have it when they need it, they'll know
who to blame.

Bob

>>> Stephen Kent <[email-masked]> 02/01/99 03:54PM >>>
Bill,

>Maintaining a copy of a user's certificate chain has implications for
>digitally signed archives, as well.
>
> In the case of an archived (and signed) document, should the document
>itself retain a copy of the certificate >chain to aid in validation? Or
>will PKI's/Directories support future path validation for archived
>documents?
>
> Thoughts/comments?

I've always been of the school that calls for a relying party to take
responsibility for acquiring and retaining the certs and CRLs, and
timestamping them, to support a future repudiation problem.  After all,
only a relying party knows how long to keep this data, and this model
parallels what we do in the physical world (outside of the Latin Notaire
context).  But, some folks object to this notion and want CAs or others to
provide these services for them, so there is no single right answer here.

Steve

From: "Peter Williams" <[email-masked]>
To: "WHenry" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: FW: Attribute used to store cached certificate chains?
Date: Tue, 2 Feb 1999 12:14:33 -0600
Sender: [email-masked]

A contribution to the issue:-

There is a difference between system design
for caching trust information to achieve performance
improvement or control trust-policy enforcement, and
storage of transactional data after the fact of
signature verification and certificate-chain validation.

Responsibility for maintenance of transactional
data is the current thread topic.  In the enterprise context, does
it fall to the individual or the company? For whom is the reliability of
access to the data critical, asks the risk management professional?

In the private key escrow (renamed key management)
debate, we learn from govts that no individual can be trusted
by the corporation to control the private key in
the ultimate interests of the company. Third-party escrow
is a required feature of the corporate environment,
therefore. The users system must be denuded of
potential capability to compromise such a corporate
requirement,  in consequence.

Using a similar logical argument, if a *companies* validation
of a signed transaction is performed by an individual, surely
the company cannot trust the individual to maintain
the accurate logs/data/context on the historical
information, should that data be required as proof-basis/evidence
in the future.  Therefore, a company-maintained
repository of transaction reconstruction/audit data
is required, just as centralized, mandatory key recovery is
required to ensure business continuation capability.

This argument strongly suggests that *enterprise-based*
verification/transaction-reconstruction services will be required.

I would, however, disagree that it is necessarily the enterprise CA which
performs such a mandatory repository function, however. Many
companies could outsource this function today to such providers
as Surety. Though reliability-critical, such "safe storage" (with
optional notarization) is not especially security critical in the sense
of the specific technical risks which the enterprise CA manages when
issuing valid certificates.

Peter.
    -----Original Message-----
    From: Stephen Kent <[email-masked]>
    To: WHenry <[email-masked]>
    Cc: [email-masked]' <[email-masked]>; [email-masked]'
<[email-masked]>
    Date: Tuesday, February 02, 1999 10:23 AM
    Subject: Re: FW: Attribute used to store cached certificate chains?

    Bill,

    >Maintaining a copy of a user's certificate chain has implications for
digitally signed archives, as well.
    >
    > In the case of an archived (and signed) document, should the document
itself retain a copy of the certificate >chain to aid in validation? Or will
PKI's/Directories support future path validation for archived documents?
    >
    > Thoughts/comments?

    I've always been of the school that calls for a relying party to take
responsibility for acquiring and retaining the certs and CRLs, and
timestamping them, to support a future repudiation problem. After all, only
a relying party knows how long to keep this data, and this model parallels
what we do in the physical world (outside of the Latin Notaire context).
But, some folks object to this notion and want CAs or others to provide
these services for them, so there is no single right answer here.

    Steve

Date: Tue, 2 Feb 1999 10:53:08 -0500
To: Alan Lloyd <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Cc: [email-masked]
Sender: [email-masked]

Alan,

Let metry to condense our debate to spare the rest of the list from reading
lost of text:

1. You state that "in addition to signing data, we can also place
>"some" trust on the distributed authentication and access controls of
>the directory system. Particularly when the user or certficate reader
>has been requested to do strong authentication on the directory service
>itself to read the CA entry. We do deal with trusted directory systems
>you know."

You also say "And in the case where this extra strengh is needed we can do
>strong auth and signed ops on the directory service.. with DAP - you
>know the protocol thats half the size of LDAP with twicw as many feature
>including trusted signed operations."

This line of argument seem to ignore the fact that the vast majority of
successful, detected attacks against computers of any sort are effected
through exploitation of design, implementation, or management
vulnerabilities that are NOT prevented through the use of cryptography for
communication security, including signed directory operations.  This
characteristic has been true for the last 20+ years and is well documented
through analysis of CERT advisories.  A vast set of directory resources
provides an obvious target and if one were to adopt the approaches you
promote, which place ever greater reliance on these resources, the value of
these targets grows enormously.  That is why signing data that is stored in
any repository, and not relying on secure management of a set of
repositories, is a preferred security paradigm.

2. Later, in response to my observation that the phone system is not a
great analogy for the global, distributed directory system you envision you
say "We need to talk re the two paradigms. Many people find the phone
system/directory system paradigm very useful. As for infrastructures. They
tend to be in fact very big systems>- by definition. If OCSP wants to be
big - it will become an>infrastructure - but if it wants to be big it will
have to be supported by a big distributed information base... some thing
like a directory
service. Otherwise its hand carved..."  This response seems to ignore all
of the details of my argument of why the phone system is a poor analogy,
and the vast evidence of the fragility of this and analogous
infrastructures.  I refer you to the recent "Trust in Cyberspace" report by
the (U.S.) National Academy of Sciences, which makes similar point.  Of
course, as a member of the committee that wrote the report, I may be
prejudiced :-). Also, your comment about the growth of OCSP seems to focus
on ONE way of using it, namely having a network of TTPs act as oracles for
queries about certificate status or validity.  This is not the only model
for OCSP, and it is not the one that prompted the development of OCSP.  If
CAs operate OCSP responders for the certs that they issue, there is no need
to create the sort of highly vulnerable infrastructure you seem to propose.
OCSP servers operated by CAs, vs. outsourcing OCSP services for a CA to a
TTP, don't concentrate vulnerabilities, they distribute them.  So,
depending on the model one envisions, OCSP may be fine froma  security
standpoint, or it can be made into another disaster waiting to happen.

3. In our discussion about the nature of OCSP support, you state "How many
OCSP servers will be needed for 100m users. What is the information system
that supports this?"  Again, this seems to confuse your model for OCSP use
vs. other approaches, as noted above.  We both agree that distributed
directories are a good and necessary part of most PKIs; the issue is
whether we should use them in a fashion that creates new vulnerabilities.

4. I stated that "What it seems to boil down to is an assertion by
you that directories will be ubiquitous, very fast, ultra reliable,
and sufficiently secure so that we should abandon the crypto-integrity
model upon which X.509 is based." You responded "Thats it. Got it in one.'
well, it is nice to be clear on this point. However, you have not provided
a set of coherent, comprehensive arguments to presuade me to believe that
your assertion. Insetad, the argument seems to be that of course it will
happen becauise it must happen to enable the future and because the use of
such serves is being actively "promoted."  This does not sound like an
architecture to me; it sounds like a marketing pitch from a seller of
directory technology and/or services.  This is the PKIX WG mailing list.
We try to develop standards for PKI technology that based on sound
architectural principles, period.

5. Finally, in response to my complaint that your proposals would degrade
the security of PKIs, you respond "No infact we are enhancing the PKI with
the reality of deployed directory systems. A PKI without a business purpose
and information and service deployment scaleability will be an orphan
technology."  This does not respond to my point.  It deflects the question
by asserting, again without substantiation, that yours is the ONLY/BEST
approach to achieving scaleability, and it makes the highly questionable
claim re the reality of deployed directory systems.  We don't conduct
debates on this list based on assertions about the inevitability of a
partciular solution; we debate proposals based on their merits.

Steve

Date: Mon, 1 Feb 1999 17:54:47 -0500
To: WHenry <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: FW: Attribute used to store cached certificate chains?
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

--============_-1294149970==_ma============
Content-Type: text/plain; charset="us-ascii"

Bill,

>Maintaining a copy of a user's certificate chain has implications for
>digitally signed archives, as well.
>
> In the case of an archived (and signed) document, should the document
>itself retain a copy of the certificate >chain to aid in validation? Or
>will PKI's/Directories support future path validation for archived
>documents?
>
> Thoughts/comments?

I've always been of the school that calls for a relying party to take
responsibility for acquiring and retaining the certs and CRLs, and
timestamping them, to support a future repudiation problem.  After all,
only a relying party knows how long to keep this data, and this model
parallels what we do in the physical world (outside of the Latin Notaire
context).  But, some folks object to this notion and want CAs or others to
provide these services for them, so there is no single right answer here.

Steve
--============_-1294149970==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bill,

<fontfamily><param>Arial</param><color><param>0000,0000,FFFF</param>>Maintai=
ning
a copy of a user's certificate chain has implications for digitally
signed archives, as well.

</color></fontfamily>>

<fontfamily><param>Arial</param><color><param>0000,0000,FFFF</param>> In
the case of an archived (and signed) document, should the document
itself retain a copy of the certificate >chain to aid in validation? Or
will PKI's/Directories support future path validation for archived
documents?

</color></fontfamily>>

<fontfamily><param>Arial</param><color><param>0000,0000,FFFF</param>> Though=
ts/comments?

</color></fontfamily>I've always been of the school that calls for a
relying party to take responsibility for acquiring and retaining the
certs and CRLs, and timestamping them, to support a future repudiation
problem.  After all, only a relying party knows how long to keep this
data, and this model parallels what we do in the physical world
(outside of the Latin Notaire context).  But, some folks object to this
notion and want CAs or others to provide these services for them, so
there is no single right answer here.

Steve

--============_-1294149970==_ma============--

To: IETF-Announce: ;
From: [email-masked]
cc: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-sakurai-pkix-icap-01.txt
Date: Tue, 02 Feb 1999 10:52:47 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Web-based Integrated CA services Protocol, ICAP
	Author(s)	: M. Sakurai, H. Kikuchi, H. Hattori, Y. Sameshima, H. Kumagai
	Filename	: draft-sakurai-pkix-icap-01.txt
	Pages		: 41
	Date		: 01-Feb-99
	
   This document provides a sub set of specifications how to issue,
   publish X.509 certificates and certificate revocation lists (CRLs).
   It also provides the certificate validation service by online.  In
   the proposed specifications, the World Wide Web (WWW) is used for
   secure distributing certificates across a firewall in both human and
   machine readable syntax. These specifications define not only the
   protocols between the PKI clients and a single CA, but also the
   protocols between the CAs.  With the CA-CA communications, the PKI
   clients can retrieve any certificates and CRLs without specifying the
   location of the appropriate CA, by only asking to the neighbor CA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sakurai-pkix-icap-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sakurai-pkix-icap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sakurai-pkix-icap-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-sakurai-pkix-icap-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-sakurai-pkix-icap-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Peter Williams" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Bietf-pkix" <[email-masked]>
Subject: Re: Terminology question:  "root CA"
Date: Mon, 1 Feb 1999 15:04:51 -0600
Sender: [email-masked]

Much of the recent conversation concerning the "roadmap" to
PKIX documents seems to be directed not at merely
elucidating what is already specified in less formal
language, but  defining particular ways of thinking about PKI; 
or,  respecifying matters which some parties might
think PKIX-1 consensual agreements did insufficiently well.

Perhaps we should re-resolve that PKIX documents
designed to serve as application-independent
and (Internet) environment-independent frameworks 
should remain that way. One or more policy documents
can take a different tack, to suit communities with
particular  needs for controlling the behaviour of 
subscribers and relying parties alike, as we agreed
in Orlando. The roadmap document is NOT such a policy
document, as far as I can tell, however. Neither  is it 
"generic policy",   or "good practice" or "standard operating 
procedure", or any other form of authoritative guidance
instrument.  It just changes the language form - to assist folk
navigate over the range of existing specified materials.
 
Generally, the notions of fixing management domain constructs, 
mandatory uniform naming architectures, or required delivery
of services for conforming status as  PKIX TTP, all seem as
alien  to the goals of this IETF forum as they did last year
when I last said the same thing (several thousand, unread 
messages ago).

Peter.

-----Original Message-----
From: Stephen Kent <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Bietf-pkix <[email-masked]>
Date: Monday, February 01, 1999 3:45 PM
Subject: Re: Terminology question: "root CA"

>David,
>
>I have to agree with Warwick. Rootedness is in the eye of the beholder,
>well, OK, in the cert verfication mechanism of the relying party.  One
>man's root may be another man's (or woman's) cross-certified CA. We ought
>not let the browser PKI models overshadow more general PKI models.
>
>Steve

Date: Mon, 01 Feb 1999 14:56:17 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: SecureConnect 2
Sender: [email-masked]

Greetings again. A few of the companies attending SecureConnect 2 have
noted to me that I didn't send mail to the PKIX or S/MIME WG mailing lists.
I guess my non-spam traits got the better of me.

SecureConnect 2 is the interoperability event for S/MIME clients and CAs,
to be held February 23-24. Folks out in The Real World have been finding
that many (but not all) of the interoperability issues in deployed S/MIME
clients are in the certificate handling. Thus, it would be good to get all
of today's S/MIME client vendors and CA vendors together to do more
in-depth testing.

More information on SecureConnect 2 can be found at
<http://www.imc.org/imc-secureconnect/>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 1 Feb 1999 15:58:20 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Terminology question:  "root CA"
Cc: Bietf-pkix <[email-masked]>
Sender: [email-masked]

David,

I have to agree with Warwick. Rootedness is in the eye of the beholder,
well, OK, in the cert verfication mechanism of the relying party.  One
man's root may be another man's (or woman's) cross-certified CA. We ought
not let the browser PKI models overshadow more general PKI models.

Steve

Date: Mon, 01 Feb 1999 15:29:40 -0500
To: [email-masked]
From: Al Arsenault <[email-masked]>
Subject: Revised:  POP section for Roadmap
Sender: [email-masked]

--=====================_1391583843==_.ALT
Content-Type: text/plain; charset="us-ascii"

Okay, based on comments from several people, attached is a revision of the
proposed POP section for the next Roadmap draft.  While Denis had some very
good inputs, I mostly agree with Juergen, and think that the "new mechanisms"
that Denis talked about don't solve all of the problems caused by not doing
POP.  I did modify the "signing keys" section to describe - in words to be put
in the text, or maybe in a footnote, whichever works better - the "new
mechanisms" Denis mentioned, and state that they help to solve part of the
problem.  However, I don't think they solve the whole problem.

Additionally, I separated out use of signing keys in non-repudiation services
vs. authentication services, because I think that the need for POP is lesser in
the latter.

Re:  the key-management example:  I've been told by a couple of reviewers that
this is kind of weak (Dorothy would probably already notice that her key had
been compromised if it had been, and so the fact that she hasn't reported a
problem means it's safe,...), but it's the best I can think of at this point.  

I've also tried to reword a couple of things that were seen as pejorative by
some reviewers. 

At any rate, here's the revision:
1.1     POP 
Proof of Possession, or POP, means that the CA is adequately convinced that the
entity requesting a certificate containing a public key Y has access to the
private key X corresponding to that public key.  

POP is important because it provides an appropriate level of assurance in the
correct operation of the PKI as a whole.  At its lowest level, POP counters the
“self-inflicted denial of service”; that is, an entity voluntarily getting a
certificate that cannot be used to sign or encrypt/decrypt information. 
However, as the following two examples demonstrate, POP also counters less
direct, but more severe, threats:
POP for signing keys: it is important to provide POP for keys used to sign
material, in order to provide non-repudiation of transactions.  For example,
suppose Alice legitimately has private key X and its corresponding public key
Y.  Alice has a certificate from Charlie, a CA, containing Y.  Alice uses X to
sign a transaction T.  Without POP, Mal could also get a certificate from
Charlie containing the same public key, Y.  Now, there are two possible
threats: Mal could claim to have been the real signer of T; or Alice can
falsely deny signing T, claiming that it was instead Mal.  Since no one can
reliably prove that Mal did or did not ever possess X, neither of these claims
can be refuted, and thus the service provided by and the confidence in the PKI
has been defeated.  (Of course, if Mal really did possess X, Alice’s private
key, then no POP mechanism in the world will help, but that is a different
problem.)  

Note that one level of protection can be gained by having Alice, as the true
signer of the transaction, include in the signed information her certificate or
an identifier of her certificate (e.g., a hash of her certificate).  This might
make it more difficult for Mal to claim authorship;  he would have to assert
that he incorrectly included Alice’s certificate, rather than his own. 
However, it would not stop Alice from falsely repudiating her actions. Since
the certificate itself is a public item, Mal indeed could have inserted Alice’s
certificate or identifier into the signed transaction, and thus its presence
does not indicate that Alice was the one who participated in the now-repudiated
transaction. The only reliable way to stop this attack is to require that Mal
prove he possesses X before his certificate is issued.

For signing keys used only for authentication, and not for non-repudiation, the
threat is lower because users may not care about Alice’s after-the-fact
repudiation, and thus POP becomes less important.  However, POP SHOULD still be
done wherever feasible in this environment, by either off-line or on-line
means. 

POP for key management keys:  Similarly, POP for key management keys (that is,
keys used for either key agreement or key exchange) can help to prevent
undermining confidence in the PKI.  Suppose that Al is a new instructor in the
Computer Science Department of a local University.  Al has created a draft
final exam for the Introduction to Networking course he is teaching.  He wants
to send a copy of the draft final to Dorothy, the Department Head, for her
review prior to giving the exam.  This exam will of course be encrypted, as
several students have access to the computer system.  However, a quick search
of the certificate repository (e.g., search the repository for all records with
subjectPublicKey=Dorothy’s-value) turns up the fact that several students have
certificates containing the same public key management key as Dorothy.  At this
point, if no POP has been done by the CA, Al has no way of knowing whether all
of the students have simply created these certificates without knowing the
corresponding private key (and thus it is safe to send the encrypted exam to
Dorothy), or whether the students have somehow acquired Dorothy’s private key
(and thus it is certainly not safe to send the exam).  Thus, the service to be
provided by the PKI  allowing users to communicate with one another, with
confidence in who they are communicating with - has been totally defeated. If
the CA is providing POP, then either no students will have such certificates,
or Al can know with certainty that the students do indeed know Dorothy’s
private key, and act accordingly.

CMP requires that POP be provided for all keys, either through on-line or
out-of-band means.  There are any number of ways to provide POP, and the choice
of which to use is a local matter.  Additionally, a certificate requester can
provide POP to either a CA or to an RA, if the RA can adequately assure the CA
that POP has been performed.  Some of the acceptable ways to provide POP
include:

        Out-of-band means:  
For keys generated by the CA or an RA (e.g., on a token such as a smart card or
PCMCIA card), possession of the token can provide adequate proof of possession
of the private key.

For user-generated keys, another approach can be used in environments where
“key recovery” requirements force the requester to provide a copy of the
private key to the CA or an RA.  In this case, the CA will not issue the
requested certificate until such time as the requester has provided the private
key.  This approach is in general not recommended, as it is extremely risky
(e.g., the system designers need to figure out a way to protect the private
keys from compromise while they are being sent to the CA/RA/other authority,
and how to protect them there), but it can be used. 

        On-line means:
For signature keys that are generated by an end-entity, the requester of a
certificate can be required to sign some piece of data (typically, the
certificate request itself) using the private key.  The CA will then use the
requested public key to verify the signature.  If the signature verification
works, the CA can safely conclude that the requester had access to the private
key.  If the signature verification process fails, the CA can conclude that the
requester did not have access to the correct private key, and reject the
request.

For key management keys that are generated by the requester, the CA can send
use the requested public key, along with the CA’s own private key, to encrypt
some piece of data, and send it to the requester to be decrypted. For example,
the CA can generate some random challenge, and require some action to be taken
after decryption (e.g., “decrypt this encrypted random number and send it back
to me”). If the requester does not take the requested action, the CA concludes
that the requester did not possess the private key, and the certificate is not
issued.  

Another method of providing POP for key management keys is for the CA to
generate the requested certificate, and then send it to the requester in
encrypted form.  If the requester does not have access to the appropriate
private key, the requester cannot decrypt the certificate, and thus cannot use
it. After some period of time in which the certificate is not used, the CA will
revoke the certificate.  (This only works if the certificate is not made
available to any untrusted entities until after the requester has successfully
decrypted it.

--=====================_1391583843==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
Okay, based on comments from several people, attached is a revision of
the proposed POP section for the next Roadmap draft.&nbsp; While Denis
had some very good inputs, I mostly agree with Juergen, and think that
the &quot;new mechanisms&quot; that Denis talked about don't solve all of
the problems caused by not doing POP.&nbsp; I did modify the
&quot;signing keys&quot; section to describe - in words to be put in the
text, or maybe in a footnote, whichever works better - the &quot;new
mechanisms&quot; Denis mentioned, and state that they help to solve part
of the problem.&nbsp; However, I don't think they solve the whole
problem.<br>
<br>
Additionally, I separated out use of signing keys in non-repudiation
services vs. authentication services, because I think that the need for
POP is lesser in the latter.<br>
<br>
Re:&nbsp; the key-management example:&nbsp; I've been told by a couple of
reviewers that this is kind of weak (Dorothy would probably already
notice that her key had been compromised if it had been, and so the fact
that she hasn't reported a problem means it's safe,...), but it's the
best I can think of at this point.&nbsp; <br>
<br>
I've also tried to reword a couple of things that were seen as pejorative
by some reviewers. <br>
<br>
At any rate, here's the revision:<br>
<font size=3D4><b><i>
<dl>
<dd>1.1<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>POP</font></b></i><font=
 face=3D"Courier New, Courier">
</dl>Proof of Possession, or POP, means that the CA is adequately
convinced that the entity requesting a certificate containing a public
key Y has access to the private key X corresponding to that public
key.&nbsp; <br>
<br>
POP is important because it provides an appropriate level of assurance in
the correct operation of the PKI as a whole.&nbsp; At its lowest level,
POP counters the =93self-inflicted denial of service=94; that is, an entity
voluntarily getting a certificate that cannot be used to sign or
encrypt/decrypt information.&nbsp; However, as the following two examples
demonstrate, POP also counters less direct, but more severe,
threats:<br>

<dl>
<dd>POP for signing keys: it is important to provide POP for keys used to
sign material, in order to provide non-repudiation of transactions.&nbsp;
For example, suppose Alice legitimately has private key X and its
corresponding public key Y.&nbsp; Alice has a certificate from Charlie, a
CA, containing Y.&nbsp; Alice uses X to sign a transaction T.&nbsp;
Without POP, Mal could also get a certificate from Charlie containing the
same public key, Y.&nbsp; Now, there are two possible threats: Mal could
claim to have been the real signer of T; or Alice can falsely deny
signing T, claiming that it was instead Mal.&nbsp; Since no one can
reliably prove that Mal did or did not ever possess X, neither of these
claims can be refuted, and thus the service provided by and the
confidence in the PKI has been defeated.&nbsp; (Of course, if Mal really
did possess X, Alice=92s private key, then no POP mechanism in the world
will help, but that is a different problem.)&nbsp; <br>
<br>

<dd>Note that one level of protection can be gained by having Alice, as
the true signer of the transaction, include in the signed information her
certificate or an identifier of her certificate (e.g., a hash of her
certificate).&nbsp; This might make it more difficult for Mal to claim
authorship;&nbsp; he would have to assert that he incorrectly included
Alice=92s certificate, rather than his own.&nbsp; However, it would not
stop Alice from falsely repudiating her actions. Since the certificate
itself is a public item, Mal indeed could have inserted Alice=92s
certificate or identifier into the signed transaction, and thus its
presence does not indicate that Alice was the one who participated in the
now-repudiated transaction. The only reliable way to stop this attack is
to require that Mal prove he possesses X before his certificate is
issued.<br>
<br>

<dd>For signing keys used only for authentication, and not for
non-repudiation, the threat is lower because users may not care about
Alice=92s after-the-fact repudiation, and thus POP becomes less
important.&nbsp; However, POP SHOULD still be done wherever feasible in
this environment, by either off-line or on-line means. <br>
<br>

<dd>POP for key management keys:&nbsp; Similarly, POP for key management
keys (that is, keys used for either key agreement or key exchange) can
help to prevent undermining confidence in the PKI.&nbsp; Suppose that Al
is a new instructor in the Computer Science Department of a local
University.&nbsp; Al has created a draft final exam for the Introduction
to Networking course he is teaching.&nbsp; He wants to send a copy of the
draft final to Dorothy, the Department Head, for her review prior to
giving the exam.&nbsp; This exam will of course be encrypted, as several
students have access to the computer system.&nbsp; However, a quick
search of the certificate repository (e.g., search the repository for all
records with subjectPublicKey=3DDorothy=92s-value) turns up the fact that
several students have certificates containing the same public key
management key as Dorothy.&nbsp; At this point, if no POP has been done
by the CA, Al has no way of knowing whether all of the students have
simply created these certificates without knowing the corresponding
private key (and thus it is safe to send the encrypted exam to Dorothy),
or whether the students have somehow acquired Dorothy=92s private key (and
thus it is certainly not safe to send the exam).&nbsp; Thus, the service
to be provided by the PKI&nbsp; allowing users to communicate with one
another, with confidence in who they are communicating with - has been
totally defeated. If the CA is providing POP, then either no students
will have such certificates, or Al can know with certainty that the
students do indeed know Dorothy=92s private key, and act accordingly.<br>
<br>

</dl>CMP requires that POP be provided for all keys, either through
on-line or out-of-band means.&nbsp; There are any number of ways to
provide POP, and the choice of which to use is a local matter.&nbsp;
Additionally, a certificate requester can provide POP to either a CA or
to an RA, if the RA can adequately assure the CA that POP has been
performed.&nbsp; Some of the acceptable ways to provide POP=20
include:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Out-of-band
means:
<dl>
<dd>For keys generated by the CA or an RA (e.g., on a token such as a
smart card or PCMCIA card), possession of the token can provide adequate
proof of possession of the private key.<br>
<br>

<dd>For user-generated keys, another approach can be used in environments
where =93key recovery=94 requirements force the requester to provide a copy
of the private key to the CA or an RA.&nbsp; In this case, the CA will
not issue the requested certificate until such time as the requester has
provided the private key.&nbsp; This approach is in general not
recommended, as it is extremely risky (e.g., the system designers need to
figure out a way to protect the private keys from compromise while they
are being sent to the CA/RA/other authority, and how to protect them
there), but it can be used. <br>
<br>

</dl><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>On-line
means:<br>

<dl>
<dd>For signature keys that are generated by an end-entity, the requester
of a certificate can be required to sign some piece of data (typically,
the certificate request itself) using the private key.&nbsp; The CA will
then use the requested public key to verify the signature.&nbsp; If the
signature verification works, the CA can safely conclude that the
requester had access to the private key.&nbsp; If the signature
verification process fails, the CA can conclude that the requester did
not have access to the correct private key, and reject the request.<br>
<br>

<dd>For key management keys that are generated by the requester, the CA
can send use the requested public key, along with the CA=92s own private
key, to encrypt some piece of data, and send it to the requester to be
decrypted. For example, the CA can generate some random challenge, and
require some action to be taken after decryption (e.g., =93decrypt this
encrypted random number and send it back to me=94). If the requester does
not take the requested action, the CA concludes that the requester did
not possess the private key, and the certificate is not issued.&nbsp;
<br>
<br>

<dd>Another method of providing POP for key management keys is for the CA
to generate the requested certificate, and then send it to the requester
in encrypted form.&nbsp; If the requester does not have access to the
appropriate private key, the requester cannot decrypt the certificate,
and thus cannot use it. After some period of time in which the
certificate is not used, the CA will revoke the certificate.&nbsp; (This
only works if the certificate is not made available to any untrusted
entities until after the requester has successfully decrypted it.<br>
<br>
</font>
</dl></html>

--=====================_1391583843==_.ALT--

Date: Mon, 01 Feb 1999 17:25:43 +0100
From: Juergen Walter <[email-masked]>
Reply-To: [email-masked]
To: Denis Pinkas <[email-masked]>, Al Arsenault <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: POP section for next Roadmap draft
Sender: [email-masked]

Denis,

I agree essentially with Al´s position. I would like to add some
comments.

For non-repudiation key usage the CA must ensure that the public key is
UNIQUE. Even if the signed data includes a cert identifier the threat
described by Al remains unsolved. Substitution of certs is a minor
problem (the cert identifier encapsulation has solved the problem as you
wrote, i. e. "new" mechanism). The major problem is key uniqueness. Even
the "new" mechanism needs POP.

If CAs do not POP prior to certification then they probably allow that
two end entities share the same signature key. This may be approriate in
certain circumstances, but this is definitely not appropriate in
non-repudiation framework. The other certificate applications may be
restricted according to their usage (see Al´s key management example).

I would like to use Al´s signature key example where Alice and Mal are
involved. If I have understood correctly, a CA which does not POP may
issue two certificates with different subject identifiers (e. g.
distinguished names) and one identical public key. So, Alice may include
Mal´s identifier and sign the transaction. In the following the dispute
arises when Mal repudiated the transaction. Alice then repudiates the
possession of private key as well. Who is responsible for the
transaction? Mal?! What is about the case when there exist more than one
Mal (i. e. more than two certificates with identical public key and
different identities)?! What do you answer provided that Mal says,
sorry, it had been a joke? Is your agreement with Mal legally approved
for such cases?

Furthermore, if a person signs a document with its private key in a
non-repudiation framework, then it has accepted the information content.
When a CA signs the PRETENDED subject public key, then it has probably
accepted false information. One basic function of a CA is key
registration. But, if CAs does not verify POP, then the key is not
well-registered. So, the CA does not warrant for information contained
in the issued certificate. Why a relying party should trust such CAs? A
new certificate extension "CA has done POP" is a very bad idea (see next
para).

I think that the mechanism called "new" without POP is essentially an
attribute certification. The PRETENDED subject public key is then one of
the certified attributes. The attribute certificate binds the PRETENDED
subject public key to the end entity´s distinguished name and other
attributes if appropriate. May be, I have overseen somewhat, but your
solution is essentially a X.509 attribute certificate.

Summarizing, POP is a key registration matter. At least the
non-repudiation framework REQUIRES POP. POP SHOULD be done prior to
certification (personally, I prefer MUST). Alternatively, a CA MAY
ensure the uniqueness of the registered public keys. If a CA receives a
public key that has not been certified yet for another entity, then it
MAY drop POP (for the moment?). Those CAs that do this MUST reject a
registration request, that contains a public key always certified for a
different entity. When this registration request includes a POP and its
verification was succesful, the corresponding certificate MUST be
revoked immediately.

When entities use signature keys before they are certified by a CA or
other inappropriate key usage is another outstanding (?) key management
problem. Especially, in those cases where key pairs are generated by end
entities themselves.

Key sharing is not covered by the comments above. One may replace
entities by groups of entities where separation within the same group is
not desirable or is provided by additional certs, respectively. POP must
then be done by ALL entities who share a certain key.

Juergen

Denis Pinkas wrote:
> 
> Al,
> 
> This is nice to send that section, otherwise I would not have taken a look at
> the road map :-(
> 
> >  Folks,
> >
> > Sean and I are working on the next draft of the PKIX Roadmap.  One of the
> > things that has to be done is filling in the Proof of Possession section
> > (section 5.2 in draft -00).  Attached is a first cut at text for that
> > section.  Any strong comments one way or the other on this?
> >
> 
> Oh ! yes. I have strong opinions on this topic.
> 
> >      POP
> >
> > Proof of Possession, or POP, means that the CA is adequately convinced that
> > the entity requesting a certificate containing a public key Y has access to
> > the private key X corresponding to that public key.
> >
> > POP is important because it provides an appropriate level of assurance in
> > the correct operation of the PKI as a whole.  There are those who dismiss
> > POP as unimportant because the most direct threat it counters is the
> > “self-inflicted denial of service”; that is, an entity voluntarily gets a
> > certificate that cannot be used to sign or encrypt/decrypt information.
> 
> Up to here the text is fine.
> 
> There are three types of keys, each one being indicated with a different key
> usage. Whether POP or is not required depends on the key usage. The three main
> key usages for leaf certificates are: non repudiation, data encryption and ...
> all others in particular authentication.
> 
> The case for signing key below does not match with this separation and
> therefor is not adequate. You have to separate authentication from non
> repudiation. You also have to consider "old" mechanisms (which contain
> "errors") which mandate POP and "new" (error free) mechnisms which do not
> mandate POP.
> 
> Because some people wanted to use PKIX in any context they wanted to mandate
> POP. As soon as you use it with "new" mechanism POP is no more always needed
> (see below).
> 
> The example you provide below is an example with an "old" mechanism. The bad
> side is that many people could infer from the text that POP is always needed
> whereas this is not true.
> 
> > However, as the following two examples demonstrate, the true threat
> > countered by POP is less direct, but more important:
> >
> >      POP for signing keys:  it is important to provide POP for keys used to
> >      sign material, in order to provide authentication and possibly
> >      non-repudiation of transactions.  For example, suppose Alice
> >      legitimately has private key X and its corresponding public key Y.
> >      Alice has a certificate from Charlie, a CA, containing Y.  Alice uses X
> >      to sign a transaction T.  Without POP, Mal could also get a certificate
> >      from Charlie containing the same public key, Y.  Now, there are two
> >      possible threats:  Mal could claim to have been the real signer of T;
> >      or Alice can falsely deny signing T, claiming that it was instead Mal.
> >      Since no one can reliably prove that Mal did or did not ever possess X,
> >      neither of these claims can be refuted, and thus the service provided
> >      by and the confidence in the PKI has been defeated.  (Of course, if Mal
> >      really did possess X, Alice’s private key, then no POP mechanism in the
> >      world will help, but that is a different problem.)
> >
> 
> The simple solution to the problem is to include an identifier of the
> certificate in the signed data. In this way the substitution is no more
> possible. What you have provided is an example of an "old" mechanism whereas
> my example would be refered as a "new" mechanism.
> 
> As far as authentication is concerned some "old" mechanisms cannot be changed
> to include the certificate identifier. For non repudiation it is mandatory to
> include it, not only because of the substitution with a certificate from
> someone else but because the same signer may use different certificates all
> containing the same public key but including different security attributes (in
> an extension).
> 
> >
> >      POP for key management keys:  Similarly, POP for key management keys
> >      (that is, keys used for either key agreement or key exchange) can help
> >      to prevent undermining confidence in the PKI.  Suppose that Al is a new
> >      instructor in the Computer Science Department of a local University.
> >      Al has created a draft final exam for the Introduction to Networking
> >      course he is teaching.  He wants to send a copy of the draft final to
> >      Dorothy, the Department Head, for her review prior to giving the exam.
> >      This exam will of course be encrypted, as several students have access
> >      to the computer system.  However, a quick search of the certificate
> >      repository turns up the fact that several students have certificates
> >      containing the same public key management key as Dorothy.  At this
> >      point, if no POP has been done by the CA, Al has no way of knowing
> >      whether all of the students have simply created these certificates
> >      without knowing the corresponding private key (and thus it is safe to
> >      send the encrypted exam to Dorothy), or whether the students have
> >      somehow acquired Dorothy’s private key (and thus it is certainly not
> >      safe to send the exam).  Thus, the service to be provided by the PKI -
> >      allowing users to communicate with one another, with confidence in who
> >      can read their communications - has been totally defeated. If the CA is
> >      providing POP, then either no students will have such certificates, or
> >      Al can know with certainty that the students do indeed know Dorothy’s
> >      private key, and act accordingly.
> >
> 
> I am not convinced by this example. Alice Dorothy will be able to decrypt the
> document. If the key was indeed compromised, Dorothy would have reported it
> (and any way POP would not have helped, since all others were indeed knowing
> the key ansd would have get their certificate by exercising POP !).
> 
> > CMP requires that POP be provided for all keys, either through on-line or
> > out-of-band means.
> 
> This may be necessary in some cases, however it is not only always necessary.
> A conservative measure is to mandate it but I do not think this is
> appropriate. For authentication if the mechanism is designed very fast and no
> protection is taken, then POP is necessary. This is true for both signing keys
> and (I guess) encryption keys. When a message is encrypted so that only the
> intended recipient may decipher it, POP is not needed.
> 
> For non repudiation, since some protection is always needed at the protocol
> level, POP is NOT needed.
> 
> You may have (re-)opened a new long thread on that topic. Anyway thanks for
> trying to clarify this issue.
> 
> If I had the time I would have propose a new text. However, I thought it was
> better to provide explanations first at that stage.
> You may "canibalize" my rational and re-use it in a new text if you wish.
> 
> Denis
> 
> > There are any number of ways to provide POP, and the choice of which to use
> > is a local matter.  Additionally, a certificate requester can provide POP to
> > either a CA or to an RA, if the RA can adequately assure the CA that POP has
> > been performed.  Some of the acceptable ways to provide POP include:
> >
> > POP by Out-of-band means:
> >
> >      For keys generated by the CA or an RA (e.g., on a token such as a smart
> >      card or PCMCIA card), possession of the token can provide adequate
> >      proof of possession of the private key.
> >
> >      For user-generated keys, another approach can be used in environments
> >      where “key recovery” requirements force the requester to provide a copy
> >      of the private key to the CA or an RA.  In this case, the CA will not
> >      issue the requested certificate until such time as the requester has
> >      provided the private key.  This approach is in general not recommended,
> >      as it is extremely risky (e.g., the system designers need to figure out
> >      a way to protect the private keys from compromise while they are being
> >      sent to the CA/RA/other authority, and how to protect them there), but
> >      it can be used.
> >
> >
> > POP by On-line means:
> >
> >      For signature keys that are generated by an end-entity, the requester
> >      of a certificate can be required to sign some piece of data (typically,
> >      the certificate request itself) using the private key.  The CA will
> >      then use the requested public key to verify the signature.  If the
> >      signature verification works, the CA can safely conclude that the
> >      requester had access to the private key.  If the signature verification
> >      process fails, the CA can conclude that the requester did not have
> >      access to the correct private key, and reject the request.
> >
> >      For key management keys that are generated by the requester, the CA can
> >      send use the requested public key, along with the CA’s own private key,
> >      to encrypt some piece of data, and send it to the requester to be
> >      decrypted.  For example, the CA can generate some random challenge, and
> >      require some action to be taken after decryption (e.g., “decrypt this
> >      encrypted random number and send it back to me”).  If the requester
> >      does not take the requested action, the CA concludes that the requester
> >      did not possess the private key, and the certificate is not issued.
> >
> >      Another method of providing POP for key management keys is for the CA
> >      to generate the requested certificate, and then send it to the
> >      requester in encrypted form.  If the requester does not have access to
> >      the appropriate private key, the requester cannot decrypt the
> >      certificate, and thus cannot use it. After some period of time in which
> >      the certificate is not used, the CA will revoke the certificate.  (This
> >      only works if the certificate is not made available to any untrusted
> >      entities until after the requester has successfully decrypted it.
> >
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Al Arsenault
> >
> > -- these are my opinions only. They do not necessarily reflect the
> > opinions of my employer, or of any other organization with which I have a
> > relationship.

From: "Miklos, Sue A." <[email-masked]>
To: Tammy Carter <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Attribute used to store cached certificate chains?
Date: Mon, 1 Feb 1999 11:03:08 -0500 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE4DFC.5FE24316
Content-Type: text/plain;
	charset="iso-8859-1"

the 1997 X.501 contains the following definition for an encrypted attribute
(independent of whatever attribute type is contained within) - didn't know
if this is useful for the 'crypto-protected' feature mentioned.

18.2.2	Encrypted Attribute Value Template
If an encrypted variant is required of an existing directory attribute type,
the following syntax is used:
	EncryptedAttributeSyntax {AttributeSyntax} ::= SEQUENCE {
			keyInfo		SEQUENCE OF KeyIdOrProtectedKey,
			encAlg			AlgorithmIdentifier,
			encValue		ENCRYPTED { AttributeSyntax
} }
	KeyIdOrProtectedKey ::= SEQUENCE {
			keyIdentifier		[0]	KeyIdentifier
OPTIONAL,
			protectedKeys	[1]	ProtectedKey OPTIONAL}
	-At least one key identifier or protected key must be present 
					}
	ProtectedKey  ::=  SEQUENCE  {
		authReaders		AuthReaders,
						-- if absent, use attribute
in authorized reader entry
		keyEncAlg		AlgorithmIdentifier  OPTIONAL,
						--  algorithm to encrypt
encAttrKey
		encAttKey		EncAttKey  }
						-- confidentiality key
protected with authorized user's
						-- protection mechanism
	AuthReaders  ::=  SEQUENCE OF Name
	EncAttKey ::= PROTECTED {SymmetricKey, keyProtection}
	SymmetricKey ::= BIT STRING
	keyProtection PROTECTION-MAPPING ::= 
		SECURITY-TRANSFORMATION {genEncryption}

NOTE -  It is not reasonable that ordering matching rules or sub-string
matching rules be used for encrypted attributes. It is also recommended that
encrypted attributes are only defined for user attributes.

> ----------
> From: 	Stephen Kent[SMTP:[email-masked]]
> Sent: 	Friday, January 29, 1999 5:56 PM
> To: 	Tammy Carter
> Cc: 	[email-masked]
> Subject: 	RE: Attribute used to store cached certificate chains?
> 
> Tammy,
> 
> I agree wholeheartedly with your observations.  I've designed a number of
> certificate-enabled systems over the last decade, and they have always
> included the notion of a local cache of validated certificates and CRLs.
> Directory access is not always feasible, and it always imposes some costs
> in terms of delays.  Caches are a fine way to improve performance in
> certificate chain validation, and a well-understood part of most system
> designs.
> 
> The separate question is how to make such caches mobile, when a user is
> not
> able to bring his/her computing environment along in all cases  In that
> context I think it very appropriate to provide a well-defined directory
> attribute for use in storing a crypto-protected cert, CRL, and key
> context.
> At the RSA show a week ago, this was a common theme. The basic concept is
> not new; it appears in the DEC Distributed System Security Architecture
> published in the latter 80s, e.g., in the IEEE Security and Privacy
> Symposium.
> 
> Steve
> 

------_=_NextPart_001_01BE4DFC.5FE24316
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Attribute used to store cached certificate chains?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">the 1997 X.501 contains the following =
definition for an encrypted attribute (independent of whatever =
attribute type is contained within) - didn't know if this is useful for =
the 'crypto-protected' feature mentioned.</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"TIMES">18.2.2&nbsp; Encrypted Attribute =
Value Template</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"TIMES">If an encrypted variant is required =
of an existing directory attribute type, the following syntax is =
used:</FONT>
<UL>
<P><B><FONT SIZE=3D2 FACE=3D"HELVETICA">EncryptedAttributeSyntax =
{AttributeSyntax} ::=3D SEQUENCE {</FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">keyInfo&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
SEQUENCE OF KeyIdOrProtectedKey,</FONT></B></P>

<P><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">encAlg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; &nbsp; AlgorithmIdentifier,</FONT></B></P>

<P><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">encValue&nbsp;&nbsp;&nbsp; &nbsp; ENCRYPTED { =
AttributeSyntax } }</FONT></B></P>

<P><B><FONT SIZE=3D2 FACE=3D"HELVETICA">KeyIdOrProtectedKey ::=3D =
SEQUENCE {</FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">keyIdentifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp; [0]&nbsp;&nbsp;&nbsp;&nbsp; =
KeyIdentifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OPTIONAL,</FONT></B></P>

<P><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">protectedKeys&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[1]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ProtectedKey =
OPTIONAL}</FONT></B></P>

<P><B><FONT SIZE=3D2 FACE=3D"HELVETICA">-At least one key identifier or =
protected key must be present </FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">}</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"HELVETICA">ProtectedKey&nbsp; ::=3D&nbsp; =
SEQUENCE&nbsp; {</FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">authReaders&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AuthReaders,</FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">-- if absent, use attribute in authorized reader =
entry</FONT></B></P>

<P><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">keyEncAlg&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
AlgorithmIdentifier&nbsp; OPTIONAL,</FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">--&nbsp; algorithm to encrypt =
encAttrKey</FONT></B></P>

<P><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">encAttKey&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
EncAttKey&nbsp; }</FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">-- confidentiality key protected with authorized =
user's</FONT></B></P>

<P><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">-- protection mechanism</FONT></B></P>

<P><B><FONT SIZE=3D2 FACE=3D"HELVETICA">AuthReaders&nbsp; ::=3D&nbsp; =
SEQUENCE OF Name</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"HELVETICA">EncAttKey ::=3D PROTECTED =
{SymmetricKey, keyProtection}</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"HELVETICA">SymmetricKey ::=3D BIT =
STRING</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"HELVETICA">keyProtection =
PROTECTION-MAPPING ::=3D </FONT></B>
<BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"HELVETICA">SECURITY-TRANSFORMATION {genEncryption}</FONT></B>
</P>
</UL>
<P><B><FONT SIZE=3D2 FACE=3D"TIMES">NOTE -</FONT></B><FONT SIZE=3D2 =
FACE=3D"TIMES">&nbsp; It is not reasonable that ordering matching rules =
or sub-string matching rules be used for encrypted attributes. It is =
also recommended that encrypted attributes are only defined for user =
attributes.</FONT></P>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Stephen =
Kent[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Friday, January 29, 1999 5:56 =
PM</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans Serif">Tammy =
Carter</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">RE: Attribute used to store cached certificate chains?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Tammy,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree wholeheartedly with your =
observations.&nbsp; I've designed a number of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificate-enabled systems over the =
last decade, and they have always</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">included the notion of a local cache =
of validated certificates and CRLs.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Directory access is not always =
feasible, and it always imposes some costs</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in terms of delays.&nbsp; Caches are =
a fine way to improve performance in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificate chain validation, and a =
well-understood part of most system</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">designs.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The separate question is how to make =
such caches mobile, when a user is not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">able to bring his/her computing =
environment along in all cases&nbsp; In that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">context I think it very appropriate =
to provide a well-defined directory</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">attribute for use in storing a =
crypto-protected cert, CRL, and key context.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">At the RSA show a week ago, this was =
a common theme. The basic concept is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not new; it appears in the DEC =
Distributed System Security Architecture</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">published in the latter 80s, e.g., in =
the IEEE Security and Privacy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Symposium.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Steve</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE4DFC.5FE24316--

Date: Mon, 01 Feb 1999 10:17:02 -0500
To: ietf-pkix <[email-masked]>
From: Al Arsenault <[email-masked]>
Subject: RE: Terminology question:  "root CA"
Cc: [email-masked]
Sender: [email-masked]

Okay, to wrap this up, here's how we're proposing to proceed:

The problem is as follows:  In the scenario outlined before, where T
certifies A, B, and C, which do not have self-signed certificates but are
still CAs; and some relying party deems A to be the point in the PKI which
it trusts "the most",

	RFC 2459 says that T is the root CA and A is the most trusted CA

	CMP says that A is the root CA and T for all practical purposes doesn't exist.

Most of the literature in the field, and most (although certainly not all)
of the comments on this list tend to prefer the CMP terms.  Thus, the
Roadmap will also prefer those terms, although it will point out the
unfortunate difference in terminology between RFC 2459 and
RFC-whatever-number-CMP-winds-up-being.  

As an FYI, the section of the Roadmap where this arises is where we try to
explain:

	- what happens to A when T's key is compromised;

	- what happens to user Fred, who has selected A as the "root of trust",
when A's certificate is revoked by T.

Thanks for the useful input,

				Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.

From: Simon Tardell <[email-masked]>
To: "'Markus Bitterli'" <[email-masked]>
Cc: [email-masked]
Subject: RE: RE: OCSP and historical data
Date: Mon, 1 Feb 1999 10:00:43 +0100 
Sender: [email-masked]

> Hello,
> Probably I do misunderstand this, but I think this is just to  provide an
> answer for certificates which are already expired.
> My problem is that I would like to check certificates which signs
> transactions, e.g. within an e-mail. In this case   I should  actually
check
> the validity of the certificate for the time of the signing  process and
not
> when I receive it. For this I saw no mechanism in the standard.
> 
> Regards,
> Markus

If a certificate is revoked, you get the revocation time _and_ revocation
reason in the response. From that, you should be able to figure if you
should trust the signature or not (obviously, the revocation reason is
important here -- e.g. if the keys are compromised and you don't have a
trusted time stamp, the revocation time doesn't matter). The archive cutoff
time is just to tell you if the OCSP responder keeps that information for
old (expired) certificates, as it is not normally required to.

Simon

Simon Tardell       voice +46 8 7755225, fax +46 8 191499
iD2 Technologies    [email-masked], http://www.iD2tech.com
Grand Prize Winner European IT-prize 1998  --  http://www.it-prize.org