Subject: Re: NEW Data type for certificate selection ?

From: Mark Shuttleworth <[email-masked]>
Date: Thu, 24 Sep 1998 16:26:50 +0200

Hiya

I'd love to see a general solution to this problem. For example, this
might enable servers to run multiple SSL servers on one IP/port address,
instead of requiring an IP per secure domain. It might also work well
with our Strong Extranet, because the server could say "I need a client
cert from one of these CA's, and it must have an identity in this sxnet
zone".

--
Mark Shuttleworth
Thawte

---

From: "Miklos, Sue A." <[email-masked]>
Date: Thu, 24 Sep 1998 12:02:05 -0400

Please consider the following matching rules for certificates, based on
the X.500 series.  I would really like to see products developed that
can invoke them (as client) and products developed that can retrieve
them from the storage (as repository).  I am not advocating this exact
syntax, but something very similar would be extremely beneficial.
Sandi

>----------
>From: 	Stefan Santesson[SMTP:[email-masked]]
>Sent: 	Thursday, September 24, 1998 8:41 AM
>To: 	[email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: 	NEW Data type for certificate selection ?
>
>All,
>
>During the TLS session in Chicago (IETF meeting) I discussed with Jeff
>Weinstein, Netscape, the problem of certificate selection in an environment
>where the client is populated with many similar certificates for different
>purposes.
>
>We concluded that this is a general problem, not only for TLS, but for
>S/MIME, Java, Java script, etc, where signing and encryption based on an
>X.509 PKI is an option. I also conclude that the current TLS approach,
>using Issuer name as selection criteria, is hopelessly insufficient for the
>general case.
>
>In fact we can NEVER claim that we have an X.509 based architecture ready
>for the big market IF WE DON'T SOLVE THIS PROBLEM.
>
>A normal user (I.e grandmother) will never be able to pick the right
>certificate by herself, if there is more than 1 to pick.
>
>The question raised here is:
>
>WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD START.
>
>If we could create a standardized ASN.1 data type with the purpose of
>defining the criteria for selecting 1 out of n certificates, then this
>could be used as a common base for enhancing TLS, Java, Java script, S/MIME
>etc.
>
>The data type could be communicated from server to client, client to
>server, server to server, client to client; I.e in any case where one party
>which to assist another party in selecting an appropriate certificate for
>any purpose (defined by the context).
>
>Do anyone have a better idea.
>
>I think this is a lost problem that has to be fixed, hopefully in a
>standardized way.
>
>Comments, suggestions.
>
>/Stefan Santesson
>-------------------------------------------------------------------
>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: Stefan Santesson <[email-masked]>
Date: Fri, 25 Sep 1998 13:34:29 +0200

Thank you Sue,

This looks very useful. I could think of some enhancements, but since
this is standard it's a very good way to start.

Could you elaborate how the certificate mach rule could be invoked into a
protocoll.
Would it just be for the entity suggesting use of a certain type of
certificate to communicate one (or a SEQUECE OF) CertificateAssertion data
value(s)?

If this is so, then all we have to do is to have this included in various
protocolls and convince Microsoft, Netscape etc, to allow certificate
selection using this maching rule.

If we could achieve this then I think it would be a giant step in the right
direction.

What does Microsoft and Netscape say about this ???

Comments, suggestions!

/Stefan Santesson 

At 12:02 PM 9/24/98 -0400, Miklos, Sue A. wrote:
>Attachment Converted: "c:\internet\eudora\attach\MATCH2.DOC"
>

---

From: Alan Lloyd <[email-masked]>
Date: Sun, 27 Sep 1998 09:30:02 +1000

Yes I have views - see my draft lloyd-dir-cert-stat ..

First one needs a fully distributed directory system. 
Then one needs a good set of certificate matching rules in that
directory system to permit the selection of certficate components.
Including rules that can handle multi valued attributes.
Then one needs directory based certficate searches based on  client
business semantics.
And then one needs certficate paths to associated with business
semantics in a trusted way rather than just crypto-cert-issuerId
mechanisms.

I dont see the problem, simply because one has to add something else to
certs and pkis to make them work in a scaleable and useful way - and
that is big directory systems, matching rules that assist the
verification and a business information model that supports the
cert/crypto mechanisms.

I do not believe one will achieve much with to fix this issue without an
operational, business and information perspective.

just thoughts
regards alan

----------
From: Stefan Santesson
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Sent: 9/24/98 10:41:23 PM
Subject: NEW Data type for certificate selection ?

All,

During the TLS session in Chicago (IETF meeting) I discussed with Jeff
Weinstein, Netscape, the problem of certificate selection in an
environment
where the client is populated with many similar certificates for
different
purposes.

We concluded that this is a general problem, not only for TLS, but for
S/MIME, Java, Java script, etc, where signing and encryption based on an
X.509 PKI is an option. I also conclude that the current TLS approach,
using Issuer name as selection criteria, is hopelessly insufficient for
the
general case.

In fact we can NEVER claim that we have an X.509 based architecture
ready
for the big market IF WE DON'T SOLVE THIS PROBLEM.

WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD
START.

If we could create a standardized ASN.1 data type with the purpose of
defining the criteria for selecting 1 out of n certificates, then this
could be used as a common base for enhancing TLS, Java, Java script,
S/MIME
etc.

The data type could be communicated from server to client, client to
server, server to server, client to client; I.e in any case where one
party
which to assist another party in selecting an appropriate certificate
for
any purpose (defined by the context).

Comments, suggestions.

/Stefan Santesson

---

From: tyone <[email-masked]>
Date: Mon, 28 Sep 1998 11:19:19 +0900

Hi.

What do you think of the idea that using cert policies extension for
this purpose?
The reason is, cert policies extension indicating how the certificate
has been issued,
and how the certificate should be used.

If two different certificates have the same cert policies extension
value and
one can be used for application A, then it is reasonable that the other
can be
used for application A.

if we decide to introduce  a new extension or a new ASN1 field  to X509
format,
,which indicates what kinds of applications can use the certificate,
we first have to  categorize applications from some view points( data
sensitivity?).
This categorizing work seems to be very hard and difficult.

Takeshi Yoneda
Mitsubishi Electric Corp.

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 28 Sep 1998 18:16:45 +1000

Tyone - the problem gets worse if one uses extensions - It means one is
tying (by cryptography) the local context/usage of a certificate. And as
you say, contexts may not be universal. In fact scaleability will hit
once we force "application" tags into certificates, simply because - as
you say, usage identifiers are open ended.

Nothing will be perfect in this space, but my preference is to have
certificate/permissions/business information approach that ties the
crypto trust components to the User capabilities and applies these into
a business context - all of which must be designed from a directory
information perspective because of the authentication, access control,
distribution and validation requirements demanded.

As said, the requirement is to have a trusted EC environment. The
components of such an environment include cert based fns, distributed
dirs and a business/organisational directory schema and (as small as
possible) client applications that rely on such services. Adding an
extension in my mind does not solve the problem, it simply creates more
because the "fix" is in the wrong place. And as you say correctly - its
hard and difficult which just indicates IMHO that the problem is
somewhere else.

I personally think that one cannot add anymore detail to PKI/509 becuase
the problems that are now being discussed are the limitations of LDAP to
support efficient and scaleable PKI systems (when X.500 should be used)
and the application,performance and trust of certificate based systems
now depend on the application they are used for. And these are cost,
operational, assurance and cost related issues.

regards alan

----------
From: tyone
To: [email-masked]
Sent: 9/28/98 12:19:19 PM
Subject: Re: NEW Data type for certificate selection ?

Hi.

Takeshi Yoneda

environment
different

the

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 29 Sep 1998 03:01:30 (NZST)

Stefan Santesson <[email-masked]> writes:
 
>The problem I want to solve is how to pick 1 out of many certificates within
>an end user application.
 
>The problem is how to select the right certificate in every suitable occasion
>when several certificates is accessed by the same application.
 
>In order to make this user friendly, we have to create a mechanism where a
>server can help a client application to select one proper certificate out of
>many. In the example there is just 3 certificates to choose among but what if
>there is 20 or 30?
 
This was something I looked at about 6 months ago while trying to come up with
a general abstraction for a certificate store.  The problem you face is that
while it's easy enough to go from certificate -> capabilities, it's very
difficult to go from capabilities -> certificate.  Put another way, given a
cert it's easy to answer the query "Can I do X with this", but given a
collection of certs it's very difficult to answer the query "Which cert is
required to do X".
 
Take the example of using a cert for email encryption.  You start by trying a
search for one of the extKeyUsage's which cover email encryption.  If this
fails you try again with a Netscape cert-type.  If that fails you try again
with one of the appropriate keyUsage's.  Finally, if that fails you try again
with no particular usage specified.  This is an incredible pain to do,
especially since each step can involve matching on multiple usage attributes,
possibly with some sort of preferred order for a match.
 
I never really came up with a solution for this, the best I could do was define
a meta-attribute which summarised the various usage types in a single place so
I could perform a single query to match on "name = foo and usage = mail
encryption" (rather than arbitrary numbers of queries with the possibility of
conflicting usages).  The disadvantages of this are that you have to keep
extending it to cover new usage types, and it needs to be stored somewhere
other than the cert itself.  My general idea was to include a kind of TLB
mechanism for cert lookups which would allow (reasonably) fast and simple
matching for frequently-used certs, but this is messy to do in an abstract
manner.  After discussing it with various people I dropped it into the "leave
it for the next release" basket.
 
If anyone has any useful solutions for this (apart from "We should force
everyone to use an X.500 directory, that would solve everything" :-) I'd be
interested in hearing them.
 
Peter.

---

From: Ed Gerck <[email-masked]>
Date: Mon, 28 Sep 1998 16:47:25 -0300 (EST)

>collection of certs it's very difficult to answer the query "Which cert is

Stefan and Peter:

As I understood, Stefan's problem (and examples) was pertinent to
*signing* and *user authentication*. Specifically, this leads to two
different subproblems, which are how to:

1. select which user's private-key should be used in response to a
web *signing* query to be done by the user -- when many private-keys
exist that can be accessed by the same application (eg, web browser),
and

2. select which user public-key certificate should be exported in
response to a web *authentication* query on the user, without
exporting any public-key cert that has sensitive attribute data (eg,
Alice's SSN).

Of course, one can argue that "public-key certs" are just what the
name implies -- public. Hence, sensitive private data such as SSN
should not be stored in them and it is immaterial which public-key
cert you export, securitywise and privacywise. In this line of
thought, if hardpressed one would include a hash of the sensitive
data in the public cert but never the data itself.

In this scenario, subproblem (2) is trivial: select any or all.
Subproblem (1) is not trivial, due to non-repudiation bits and other
qualifiers, but is answered by each application and its user
customization/history -- how it allows signing to be done (eg, if
signing is automatic, if it requires a yes/no decision, if it needs a
passphrase, etc.), how each private-key certificate is stored (eg, in
plain-text, off-line in a SC, encrypted, etc.), and so on.

However, if we accept that there may be valid uses for "public-key
certs" which are not public, with all the security and privacy risks
that may ensue from such usage (such as when Bill trusts Monica that
trusts Linda; or, when Bill cannot revoke a token that was given to
Monica and which unfortunately Monica had to surrender) -- then we
must consider that each "non-public" public-key cert and private-key
will be handled either by a special application or by an interactive
and possibly customized procedure in a general application (eg, a web
browser). Which then answers subproblems (1) and (2) also for
"non-public" public-key certs.

In that, the server application cannot define anything, at most could
suggest a list of CAs (see below), otherwise it would be easy either
to subvert the user's security choices or do a DoS attack. So, the
server must not be allowed to "help" in a decisive way which user
cert *will* be used -- as though it might seem useful at first:
 
>> In order to make this user friendly, we have to create a mechanism
>> where a server can help a client application to select one proper
>> certificate out of many. In the example there is just 3
>> certificates to choose among but what if there is 20 or 30?

but such is not safe.

Regarding Peter's statements above, they seem to address a more
general scenario where also server authentication is involved -- not
just user signing/authentication. 

The server already sends a list of server acceptable CAs, to the
client in SSL, but indeed that does not help much as the server is
gropping in the dark as to what CAs would be acceptable to the user
and what their capabilities might be acceptable to the user at the
time. Which seems to need a deeper look in terms of Peter's two
questions, also as we ask ourselves if the first question (ie, the
relation certificate -> capabilities) is really "easy enough" in a
more general scenario.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 29 Sep 1998 09:26:09 +0200

Peter, see in-line comment below.

 

>but such is not safe.

The authenticating server may surely *suggest* a list of possible certificates
that it may accept because it is always *you* (the user) that should manually
select the proper one.  In case you feel that a cert with SSN could create a disaster
if you accidentally gave it to a wrong server the solution would be to have a local
(user-defined) set of valid servers (i.e. their public keys).

To insert a new server would require a few more clicks.  I.e. similar to ActiveX
controls or signed Java Applets.  Such servers would typically be
governmental (who gave you the SSN) and a *few* other parties that
you hopefully trust like your bank or employer.   A similar scheme could be used
for defining a list of valid receivers of mail signed with a cert containing an SSN
(or other sensitive information). 

I will come back soon with a server-to-cert selection scheme.

Anders

---

From: "Robert Klerer" <[email-masked]>
Date: Wed, 30 Sep 1998 13:44:02 -0400

Stefan,

If I can suggest a more trivial example.  I have a key pair that others use
to send me encrypted email and another for encrypting files on my hard disk.
There are good reasons to use two key pairs (different escrow policies, key
lengths etc.).  Locally my applications can use various means of keeping my
private keys straight.

My CA, by policy, will put both certifucates in a repository.  People who
have access to the repository who want to send me mail have no
distinguishing application usage to select the proper certificate.

The answer is not "Don't put your file certificate in the repostory".

>David,
>
>Thank's for putting this issue in the right focus.
>
>Alan, I don't suggest any new certificate extensions
>Ed, I don't want to define any universal criteria for how certificate
>selection SHALL be done or any who decides what for whom, regulations.
>
>All I want to do is to define some mechanisms that CAN be used, if
>required, by local PKI-related services in order to make it POSSIBLE for
>them to build working services with STANDARD components.
>
>Let me highlight this again and describe a realistic problem relevant to
me.
>
>Bank A offer web-based banking applications. This requires the end user to
>get a specific certificate issued by Bank A. The certificate and the
>corresponding private key is processed through the standard web browser of
>the client.
>
>Two certificates and private keys are used in the normal process.
>1) Certificate for SSL (TLS) security
>2) Certificate for non-repudiation protection of Bank transactions.
>
>In addition to these certificates, a specific end-user may be populated
>with several other certificates, un-known to the Bank.
>
>The question is. How can this Bank create a web based application without
>distributing a customized client plug-in for the purpose. Well the Bank can
>get far using Java Scripts but it will fail due to the problem that the
>end-user may have to select a certificate.
>Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK
APPLICATION.
>
>I realize that today there is no way to do this without distributing
>customized plug-in components to end-users, but I strongly would like to se
>options developed that helps getting around this. The current matching
>mechanism in SSL and TLS is just not good enough to solve the problem.
>
>So If we instead had a standardized matching rule that could be invoked
>into protocols and Java Scripts etc, then the situation would be much more
>hopeful for the Bank in my case.
>
>They would then construct a match rule that with high probability would
>point out the right end-user certificate and invoke that matching rule both
>in the TLS protocol and in the Java Script, forming their secure
>transaction application.
>
>It wouldn't have to be perfect, just good enough to handle some 95%+ of the
>cases as long as the Bank could detect cases where it didn't work. Then the
>non-working cases could be fixed by personal customer service.
>
>I see even more use for this matching rule. It could be used in S/MIME so
>specify a preferred encryption certificate for replies to a mail. Of course
>this matching rule could be used for X.500 directories as well (that's what
>it was built for). MY concern here is however not _where_ the certificates
>are stored but, how to select 1 of several known certificates regardless of
>where they reside.
>
>
>Comments?
>How do wee proceed ?
>Could we have any comments from Microsoft and Netscape ?
>
>/Stefan
>
>At 11:15 AM 9/30/98 -0400, David Horvath wrote:
>>--- Message on the SEIS mailing list ([email-masked])
>>
>>Alan,
>>
>>While I personally agree that X.500 provides a mature and feature rich
>>core to implement certificate repositories, I am having trouble
>>understanding some of your assertions as to why X.500 is the answer to
>>so many problems.
>>
>>It seems to me that the first step for locating certificates in a
>>repository is to define the fields in the certificate object that are a
>>prerequisite to perform the match.  Matching rules are a good start and
>>foster the thought process required to provide a well designed solution.
>>Once the matching rules are defined, a protocol such as DAP or LDAP V3
>>with extensions may be used to exploit the matching rules.  In some
>>cases, clients may choose not to use the matching rules and retrieve all
>>certificates.  Perhaps matching rules are not supported by the protocol
>>(LDAP V2 or HTTP), therefore the client will collect all the
>>certificates and perform the match locally.  This may be even more
>>efficient than submitting multiple searches with different variations of
>>matching rules.  It could easily be more efficient to submit one search
>>and retrieve 10 certificates, then to submit 3 searches with different
>>matching rules each time until the required certificate is found.  This
>>should be defined by local policies based on performance analysis.
>>
>>Once the rules for matching certificates are defined ( and I think X.500
>>matching rules are an excellent start ) the distribution model can be
>>analyzed.  This is another case where X.500 may be superior to LDAP, but
>>unless you have a well planned global infrastructure neither X.500 or
>>LDAP can help with the distribution model.
>>
>>Dave Horvath
>>
>>Alan Lloyd wrote:
>>>
>>>
>>> Snip
>>>
>>> ----------
>>> From: [email-masked]
>>> To: [email-masked]; [email-masked];
>>> [email-masked]
>>> Sent: 9/29/98 1:01:30 PM
>>> Peter - you went through great lenghts to define the problem with
>>> relationships between and searching directory based objects and a
>>> distributed information issue and then you say:
>>> "
>>> everyone to use an X.500 directory, that would solve everything" :-) I'd
>>> be interested in hearing them.
>>>
>>> "
>>> Oh well - that counts me out. I cannot do solutions - without the
>>> solution :-)))
>>> regards alan
>>>
>>> Peter.
>>>
>>
>>
>>----------------- SEIS mailing list ([email-masked])
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: [email-masked]
>>
>>
>>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Oct 1998 00:35:02 +0200

Ed,

Thank you for very interesting input. If I may try a very compressed sum of
your discussion it would be:

1) In SSL the server may select preferred client certificate by Issuer DN,
and "certificate type"
2) You suggest hashed SSN (social security numbers) using "salt"

Regarding "certificate type" I can't find this as an active selection
mechanism. It is however mentioned as prerequisite that the certificate
type have to match the selected key exchange algorithm.

Regardless of this I fail to see how this can be used to pick the right
"non-repudiation" certificate in the Java script application. I also fail
to understand if you suggest that the current SSL/TLS functions solves all
my problems or just a part of them.

Do you suggest that a more general matching mechanism is not needed?

/Stefan

P.s
Regarding hashed SSN with salt, I don't get how the "salt" solves this. If
the salt is unknown then the SSN can't be checked and if the salt is known
the dictionary attack is still possible. I would say that your "salt" is
equal to suggest that the SSN should be encrypted with a secret key (where
the "salt" is being that secret key).

You and I can argue for centuries if certificates handled in browsers
should, or should not, be allowed to contain SSN. The fact is that many
organizations require this and they will create those certificates
regardless of whether you and I like it or not. All we can do is to try to
help building architectural principles that to the greatest extent is as
forgiving as possible for those examples of bad engineering that by
provable fact will show up out there. 
D.s.

At 03:08 PM 9/30/98 -0300, Ed Gerck wrote:
>On Wed, 30 Sep 1998, Stefan Santesson wrote:
>
>>
>Stefan:
>Thank you for changing the focus and not requiring (as in your
>previous examples) that Alice would have her SSN in a public cert :-)
>
>Your question below fits now the first part of my previous reply,
>with a direct solution in SSL, as I present below.
>
>>
>>Let me highlight this again and describe a realistic problem relevant to me.
>>
>>distributing a customized client plug-in for the purpose.
>
>
>Suppose the Bank signs its own CA certificate and uses that
>self-signed CA cert to sign all Bank customer's certs of a certain
>class (to make your problem still more realistic), for types (1) and
>(2) above for each customer or, (for higher security) with a
>different CA cert for each type. 
>
>Of course, that CA cert can be easily registered in a costumer's
>browser -- just using the standard menu options. This is justifiable
>regarding trust acceptance by a Bank's customer, because the Bank
>already exibits trusted functionality to the Bank's customer and the
>Bank's CA cert is used in the realm of said trusted functionality in
>regard to the customer's browser in cases (1) and (2) of your
>example. In other words, it requires no new assumptions, for neither
>party.
>
>Now, you have two phases:
>
>1. The customer's browser must automatically authenticate the Bank's
>server, using the pre-acquired and trusted public-key Bank CA cert.
>
> If the Bank's server sends its server cert to the browser in SSL,
> right after the "server hello" message and self-signed by their own
> CA, the browser will be able to automatically verify and accept the
> Bank's server cert -- since it can be checked by the public-key
> contained in the Bank's own self-signed CA cert stored at the
> costumer's browser.
>
>2. The Bank's server must authenticate the required customer's cert,
>which is appropriately requested by the Bank's server and is
>automatically presented by the customer's browser according to cert
>class and cert type, from a larger collection.
>
> Since the Bank's server is non-anonymous, it can automatically
> request the intended cert from the browser by sending only the DN of
> their own appropriate (ie, for that customer's class) CA cert in the
> "certificate request" message sent from server to browser in SSL --
> which Bank CA cert is exactly the one that signed the required
> customer's cert. Since the Bank certainly did not use their own CA
> cert to sign any other types of certs for the customer, the Bank
> (and the customer) can trust the browser/SSL combination to block
> other customer certs that could have been selected from the
> customer's certificate pool and sent back in response. The server
> can also specify in the "certificate request" message the customer's
> "certificate type" it is requesting, as needed by the Bank -- for
> example in your cases (1) and (2) above. Or, for higher security,
> the Bank can use different CA certs for each type and send their DNs
> accordingly, in each case.
>
>
>It is important to note that *if* the customer's browser fails to
>authenticate the Bank's server, then this will generate a fatal
>handshake-failure alert in SSL if the non-authenticated Bank still
>tries to go into phase 2 above -- so, the second phase is privacy
>protected by the first. Perhaps, this also answers some of your
>previous concerns and could allow more sensitive information (from
>the customer) to be included in the customer's cert sent to the
>server -- but, by all means, not in plain (eg, the SSN itself) if
>privacy is really a concern since public client certificates are
>stored in general access areas at the server.
>
>
>Regarding possible problems of using hashes to protect US's SSN
>numbers in public certs (as I suggested in my previous reply), I
>include below one comentary I received and my reply -- since it may
>be also useful in your context:
>
>===============================
>>This does not help. American SSN is only 9 digits long and only
>>includes digits. It will be trivial to do a dictionary attack in
>>this case. This may be true for other pieces of sensitive info as
>>well.
>
>The solution is to add "salt" -- like it is done in UNIX passwords.
>For example, you can add 50 chars of salt or as many as you want -- a
>passphrase. The point here is that since you know the SSN and the
>salt, no one else can guess the SSN from a dictionary attack on only
>9 digits. Better still, you can change the hash in a new cert and
>keep the SSN constant, by changing the salt, so no one can verify
>your SSN in a new cert without your cooperation.
>
>Part of this technique is used in the MC-DN token in the
>Meta-Certificate Standard being developed by the MCG. See
>http://www.mcg.org.br/mcfaq.htm
>
>===============================
>
>
>Cheers,
>
>Ed Gerck

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Oct 1998 00:53:52 +0200

Dave,  (Sorry for misspelling your name before)

I really do agree with you, sticking with the X.500 matching rules makes it
possible to link a certificate select from a local application to a
suitable directory.

Say that the client certificates is stored in a directory and not in the
client application (or any mix). When receiving the match rule from the
server it would then be very easy to use the same match data to perform an
extended lookup in the directory.

The question is now, Should this be worked on in IETF ?
Is there enough interest in getting this done and implemented?
Steve and Warwick, what do you say? Is this something for PKIX?

Unfortunately I just represent some of those service providers who need
this to be done, I will not be implementing this myself. Personally I can
just predict better business for all if we solve this.

/Stefan

At 01:20 PM 9/30/98 -0400, Dave Horvath wrote:
>Stefan,
>
>Agreed, particularly on the point of not creating any new extensions.  
>
>I would add that I firmly believe the matching rule mechanisms should be
>compatible with the work being done in X.500 and LDAP.   I would also like to
>see X.500 and LDAP join forces and be compatible in the area of matching
rules,
>I am not sure where LDAP stands at this time.
>
>
>Dave Horvath
>
>Stefan Santesson wrote:
>> 
>> David,
>> 
me.
APPLICATION.
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  [email-masked]
>
>

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 1 Oct 1998 09:25:18 +1000

Sob story introduction - still on the road in the UK now - and flat chat
with the upswing in big X.500 systems and PKIs  from every point on the
compass. So the details below may have been skipped...
anyway. 

I always thought that the matching rules for certs and crls as defined
in X.509 were like other matching rules in that objects/attrs of
particular types can be searched for and managed whilst in the directory
system.

The issues is that the PKI /CA design has been designed as a set of
"sort of related objects, but operationally there are multipaths and
multi domains.. so we have an information relationship and managment
issue (in an originators domain).. and in some form, knowledge of this
"environment" must be propagated to the recipient of signed message with
a cert - so that efficient validation can occur.

The matching rule system is a mechanism for finding what one wants and
it can be configured with the desired values - ie knowledge (not
knowledge as per DSA access point knowledge) english meaning.

It strikes me that this knowledge (and the certficate)of the originating
domain should be transferred to the recipient domain and this knowledge
supplimented by the recipient - where appropriate - and this applied
through the matching rule mechanism into the directory system to achieve
validation.

the draft I submitted - draft-lloyd-dir-cert-stat  starts the
validation/matching rule direction off. And in fact permits orgainised
knowledge of validity - which is maintained by a CA..

Any way please read. 

Its an information management and knowledge issue associated with
CA/directory systems we are dealing with  - it wont be fixed by more
attributes on certficates and more protocols like OCSP.

thoughts are welcome
regards alan
----------
From: Stefan Santesson
To: Dave Horvath
Cc: Alan Lloyd; [email-masked] '; [email-masked] ';
[email-masked] '
Sent: 10/1/98 8:53:52 AM
Subject: Re: NEW Data type for certificate selection ?

I really do agree with you, sticking with the X.500 matching rules makes
it
possible to link a certificate select from a local application to a
suitable directory.

Say that the client certificates is stored in a directory and not in the
client application (or any mix). When receiving the match rule from the
server it would then be very easy to use the same match data to perform
an
extended lookup in the directory.

Unfortunately I just represent some of those service providers who need
this to be done, I will not be implementing this myself. Personally I
can
just predict better business for all if we solve this.

/Stefan

rules,
me.
APPLICATION.
>> >>  If anyone has any useful solutions for this (apart from "We
should
>> >> force

Date: Thu, 1 Oct 1998 00:48:37 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
cc: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan:

pls add in your 1) "if the server is non-anonymous"

pls add also a 0) "a self-signed common CA cert for the server and
user certs can make your life and the customer's life a lot more
pleasant"

>2) You suggest hashed SSN (social security numbers) using "salt"

if you must add SSN-based info in a public cert, IMO yes!

>type have to match the selected key exchange algorithm.

I fail to see why you "can't find this as an active selection
mechanism" together with the issuer DN, even if you want to keep the
same type for your repudiable and non-repudiable cases (which I
possibly would not, but that is another story). As I wrote:

>> (for higher security) with a different CA cert for each type.

and, again, later in the same msg:

>> Or, for higher security, the Bank can use different CA certs for
>> each type and send their DNs accordingly, in each case.
>>

so, all you need is to have different "types" (ie, DNs) of CA certs,
where both "types" should be signed by the same root CA cert of
course and the public-key root CA cert should be included in the
distribution.

Can you pls explain what causes selection difficulties for you in the
above scenario?

>"non-repudiation" certificate in the Java script application.

Please read above, I hope it is clearer now.

> I also fail

;-) If "all your problems" is what you stated, sure, all at one stop.

>Do you suggest that a more general matching mechanism is not needed?

If the problem is what you defined, yes.

>the dictionary attack is still possible.

1. The salt is only known to those entities that should know the SSN
-- not to the evildoer that is trying to get SSNs from a list of
cached client certs, in a common access area or in memory.

2. the salt is treated as client's private information -- and kept
separate from the cert, in a protected area together with other
private information from the client.

BTW, this is similar to "dividing" a SSN "signature" into two parts,
one public (in the cert) and another private (the salt).

> I would say that your "salt" is

Yes, certainly -- but it is more appropriately called a keyed-MAC.

BTW, I am glad that you now repudiate your phrase after your P.s
above ;-)

>should, or should not, be allowed to contain SSN.

No, I don't argue. As I wrote two msgs ago, some think they have
valid reasons for it and I do not disagree with the need to preserve
freedom. In that, I follow the C maxim -- even though I think that
security work is perhaps not the best place to leave enough rope so
that you may hang yourself with it if you so want or don't think it
is dangerous...

Cheers,

Ed Gerck

From: Alan Lloyd <[email-masked]>
To: "'Dave Horvath '" <[email-masked]>, "'Stefan Santesson '" <[email-masked]>
Cc: Alan Lloyd <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 09:25:18 +1000
Sender: [email-masked]

Sob story introduction - still on the road in the UK now - and flat chat
with the upswing in big X.500 systems and PKIs  from every point on the
compass. So the details below may have been skipped...
anyway. 

I always thought that the matching rules for certs and crls as defined
in X.509 were like other matching rules in that objects/attrs of
particular types can be searched for and managed whilst in the directory
system.

The issues is that the PKI /CA design has been designed as a set of
"sort of related objects, but operationally there are multipaths and
multi domains.. so we have an information relationship and managment
issue (in an originators domain).. and in some form, knowledge of this
"environment" must be propagated to the recipient of signed message with
a cert - so that efficient validation can occur.

The matching rule system is a mechanism for finding what one wants and
it can be configured with the desired values - ie knowledge (not
knowledge as per DSA access point knowledge) english meaning.

It strikes me that this knowledge (and the certficate)of the originating
domain should be transferred to the recipient domain and this knowledge
supplimented by the recipient - where appropriate - and this applied
through the matching rule mechanism into the directory system to achieve
validation.

the draft I submitted - draft-lloyd-dir-cert-stat  starts the
validation/matching rule direction off. And in fact permits orgainised
knowledge of validity - which is maintained by a CA..

Any way please read. 

Its an information management and knowledge issue associated with
CA/directory systems we are dealing with  - it wont be fixed by more
attributes on certficates and more protocols like OCSP.

thoughts are welcome
regards alan
----------
From: Stefan Santesson
To: Dave Horvath
Cc: Alan Lloyd; [email-masked] '; [email-masked] ';
[email-masked] '
Sent: 10/1/98 8:53:52 AM
Subject: Re: NEW Data type for certificate selection ?

I really do agree with you, sticking with the X.500 matching rules makes
it
possible to link a certificate select from a local application to a
suitable directory.

Say that the client certificates is stored in a directory and not in the
client application (or any mix). When receiving the match rule from the
server it would then be very easy to use the same match data to perform
an
extended lookup in the directory.

Unfortunately I just represent some of those service providers who need
this to be done, I will not be implementing this myself. Personally I
can
just predict better business for all if we solve this.

/Stefan

rules,
me.
APPLICATION.
>> >>  If anyone has any useful solutions for this (apart from "We
should
>> >> force

Date: Thu, 01 Oct 1998 00:53:52 +0200
To: Dave Horvath <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Cc: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

/Stefan

rules,
me.
APPLICATION.

Date: Thu, 01 Oct 1998 00:35:02 +0200
To: Ed Gerck <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Cc: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

Ed,

/Stefan

P.s

Date: Wed, 30 Sep 1998 15:08:26 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
cc: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan:

Cheers,

Ed Gerck

From: "Robert Klerer" <[email-masked]>
To: <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Date: Wed, 30 Sep 1998 13:44:02 -0400
Sender: [email-masked]

Stefan,

me.
APPLICATION.
>>SEIS Contact: [email-masked]

Date: Wed, 30 Sep 1998 13:20:43 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: Stefan Santesson <[email-masked]>
CC: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan,

I would add that I firmly believe the matching rule mechanisms should be
compatible with the work being done in X.500 and LDAP.   I would also like to
see X.500 and LDAP join forces and be compatible in the area of matching rules,
I am not sure where LDAP stands at this time.

Dave Horvath

Stefan Santesson wrote:
> Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.
> 

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Wed, 30 Sep 1998 16:43:41 +0200
To: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

David,

Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.

Comments?
How do wee proceed ?

/Stefan

Date: Wed, 30 Sep 1998 11:15:51 -0400
From: David Horvath <[email-masked]>
Organization: @Home Network
To: Alan Lloyd <[email-masked]>
CC: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Alan,

Dave Horvath

> Snip

Date: Tue, 29 Sep 1998 13:30:03 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
Cc: [email-masked]
Sender: [email-masked]

Allen:

It means that the data in the CRL cannot be used to validate any
certificates.  Another source of revocation information must be used.

Russ

At 02:55 PM 9/28/98 -0700, [email-masked] wrote:
>First the question.   In Section 5.2 "CRL Extensions", p. 46, it says:
>
>     "A CRL validation MUST fail if it encounters a critical extension
>which it does not know how to process".
>
>My question is exactly what does it means that a "CRL validation fails"?.
>Does this mean that the CRL is to be ignored and that any certificates that
>might appear on the CRL are not invalidated by the CRL?.  I would suppose
>it is that interpretation rather than that a certificate validation fails
>if such a CRL is encountered.
>
>And now a minor comment.  I notice that RFC 2044 (on UTF8 strings) has been
>obsoleted by RFC 2279.  The comment is just to update the RFC reference in
>the spec in Appendix A.1 under UTF8String (p.69).
>
>
>

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure Certificate and CRL Profile to Proposed Standard
Date: Tue, 29 Sep 1998 08:06:00 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft Internet X.509 Public Key
Infrastructure Certificate and CRL Profile
<draft-ietf-pkix-ipki-part1-11.txt> as a Proposed Standard.  This
document is the product of the Public-Key Infrastructure (X.509)
Working Group.  The IESG contact persons are Jeffrey Schiller and
Marcus Leech.

Technical Summary
 
  The PKIX Working Group is chartered to specify an Internet profile
  for the use of X.509 certificates. The focus of the profile is to
  ensure interoperation between implementations that conform to it. The
  Part I specification defines formats and requirements for Certificates
  and Certificate Revocation Lists (CRLs). It is part of a suite of 
  documents, but can stand alone.

Working Group Summary

  This document is  the tenth  revision  of the Part I profile
  document. Input from many members of the community has gone into this
  draft which the working group has consensus on.

Protocol Quality

  Many  experts on Public Key Infrastructure and contributed and
  commented on  this  specification. Jeffrey  I. Schiller  reviewed the
  document for the IESG.

Y2K Compliance

  The protocols and formats in this document are Year 2000 compliant.

From: Anders Rundgren <[email-masked]>
To: "'Ed Gerck'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 09:26:09 +0200
Sender: [email-masked]

 

Anders

Date: Mon, 28 Sep 1998 15:31:45 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
Sender: [email-masked]

>And now a minor comment.  I notice that RFC 2044 (on UTF8 strings) has been
>obsoleted by RFC 2279.  The comment is just to update the RFC reference in
>the spec in Appendix A.1 under UTF8String (p.69).

Yes, please, since RFC 2279 had some technical corrections to RFC 2044, I
believe.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: [email-masked]
Date: Mon, 28 Sep 1998 14:55:42 -0700
Subject: A question and comment about PKIX - Part 1, Version 11.
Sender: [email-masked]

First the question.   In Section 5.2 "CRL Extensions", p. 46, it says:

     "A CRL validation MUST fail if it encounters a critical extension
which it does not know how to process".

My question is exactly what does it means that a "CRL validation fails"?.
Does this mean that the CRL is to be ignored and that any certificates that
might appear on the CRL are not invalidated by the CRL?.  I would suppose
it is that interpretation rather than that a certificate validation fails
if such a CRL is encountered.

And now a minor comment.  I notice that RFC 2044 (on UTF8 strings) has been
obsoleted by RFC 2279.  The comment is just to update the RFC reference in
the spec in Appendix A.1 under UTF8String (p.69).

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 07:11:56 +1000
Sender: [email-masked]

Snip

----------

 If anyone has any useful solutions for this (apart from "We should
force

" 
 
Peter.

Date: Mon, 28 Sep 1998 16:47:25 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Peter Gutmann <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan and Peter:

 

but such is not safe.

Cheers,

Ed Gerck

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Time Stamp and Notary Drafts
Date: Mon, 28 Sep 1998 13:36:34 -0400
Sender: [email-masked]

As some of you may have noticed, I have submitted the latest versions of our
Time Stamp and Data Certification Server drafts as PKIX Internet Drafts, in
accordance with the decisions made in Chicago.  These drafts are based on
the drafts that we have been submitting independently on these topics for
some time now and reporting to PKIX on their progress.

The Time Stamp Draft describes a protocol in which a trusted Time Stamp
Authority provides evidence that a message existed at a particular point in
time.  It is available at:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt

The Data Certification Server provides "notary" type services (signature
validation, certificate path validation) in support of non-repudiation.
This draft is available at:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt

As usual, comments are welcome.

	Robert Zuccherato.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Reply-To: [email-masked]
Date: Tue, 29 Sep 1998 03:01:30 (NZST)
Sender: [email-masked]

 

 

 
Peter.

Date: Mon, 28 Sep 1998 07:32:49 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Questions about PKIX
Sender: [email-masked]

Actually, those are questions about a specific PKIX implementation. As
announced here earlier, that's being discussed on a different mailing list.
See <http://www.imc.org/imc-pfl/> for information about signing up for the
list and all the news that is known about the product.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Alan Lloyd'" <[email-masked]>
Cc: "'Warwick Ford'" <[email-masked]>, "'Steve Kent'" <[email-masked]>
Subject: RE: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 09:07:02 -0400
Sender: [email-masked]

Hi Alan,

The PKIX WG embarked on this spec well over a year ago with the primary
purpose being to standardize what was predominantly deployed at that time -
LDAPv2 for use to access PKI repositories. A minimum subset of the LDAPv2
protocol was profiled, in order to enable relying party and certification
authority systems to be able to access LDAP server PKI repositories without
needing all the code a typical LDAP client would have. We were not
attempting to standardize server to server communications, only a protocol
for clients (relying parties and CAs) to use to access the repository. 

While I personally agree with some of your views about the more
comprehensive functionality that can be provided in an X.500 based
distributed systems environment, that wasn't the task we undertook. 

As the work on LDAPv2 dragged on and on and on we qestioned several times
within the WG whether to drop this activity and concentrate instead on a
more 'modern' directory technology such as LDAPv3, but every time this was
raised, the PKIX WG agreed to proceed with the LDAPv2 specs and get them
progressed since this is still a very widely deployed protocol, even though
there is plenty of interest in LDAPv3 as well. The LDAPv2 protocol profile
completed PKIX WG last call in January and the schema spec just a short time
ago. No changes have been made to the protocol spec, the only reason it was
re-issued was because it was about to expire becasue the schema spec
(required for IESG approval of the protocol profile) took so long.

I hope this answers your questions on 'why' the LDAP activity. 
Sharon 

> ----------
> From: 	Alan Lloyd[SMTP:[email-masked]]
> Sent: 	September 27, 1998 6:24 PM
> To: 	[email-masked]'
> Subject: 	comments on draft-ietf-pkix-ipki2opp-08.txt
> 
> Comments: Internet X.509 Public Key Infrastructure 
>                             Operational Protocols - LDAPv2
> 
> Sorry for being my usual self. But what does this document do or solve.
> 
> All it states is use LDAP V2 to a PKI repository? and highlights the
> major failings of LDAP encoding when dealing with certificate attributes
> with multiple values. ie. In that the client gets the lot (every
> certificate - regardless) --  and if the client goes for CRLs as well  -
> and they are multi values of a CRL attribute - the client will get the
> lot as well.
> 
> Lets do some rough sums. A cert = 600 - 2k bytes average 1kb, 5-10 certs
> per user, 3 certs in a path.. transfer = 20- 30kb just to verify a
> signature. In addition CRLs - bad sites, and they could get large.
> And LDAP  accesses for the certs could be via referrals. Lets say that
> we could be looking at optimistically  at 10-30 seconds of validation
> time.
> I would be happy to be corrected here..
> 
> 
> Fundamental Problems with LDAP
> 
> LDAP servers are "string based" and non distributed - hence the need to
> use X.500 and migrate these LDAP servers to a distributed architecture.
> Not all certificates one wishes to deal with will be in your local ldap
> server - they will be in the directory system that one cooperates with.
> 
> X.500 has certficate matching rules to enable selection of certificates
> within a multi value attribute.
> 
> I am not sure what cert matching rules LDAP servers have or even if they
> support multi valued att matching or if they are compatible with X.500.
> Again the encoding restrictions in LDAP could imply the non use of
> these.
> 
> It is obvious to most that LDAP is not very good generally and in the
> case of PKI / certficate issues over a wider scale, totally unusable.
> 
> In addition the process one builds into an LDAP client to deal with
> referrals and LDAP certficate servers has to be lot larger and therefore
> problematic, than that that uses distributed directories with sound
> matching rules.
> 
> ie. the best it can get depends on the tools to hand.
> 
> I therefore beg why the document is being put forward because IMHO - it
> promotes systems to be built that will not provide the business utility
> demanded by companies using large scale EC/509 technologies. The result
> can only be commercial disasters and pain for both suppliers and the
> poor customer.
> 
> Oh well - 
> 
> regards alan
>    
> 

Date: Mon, 28 Sep 1998 22:11:42 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Mr. Santesson,

I am not necessarily against you.
I write all of my comments below
because I would like to contribute
to this issue.

Stefan Santesson wrote:

> Let me clarify my case.
>
> The problem I want to solve is how to pick 1 out of many certificates
> within an end user application.
>

I think that the real problem is how an application select a suitable
(or correct) certificate when there are multiple applications and
multiple certificates within one PC.

In your example below, S/MIME and another application (say,
application X) hold Cert 1 in common. If we limit the situation to
e-mail applications, this may be easy, but how do we realize it
in a generalized way ?

> An example.
>
> Alice has 4 certificates.
> 1) E-mail based ID with low security
> 2) Anonymous cert used for anonymous information services.
> 3) Qualified ID-certificate (with her social security number)
> 4) VISA SET-certificate.
>
> In this example:
> - Cert 1 and 2 are issued by the same CA and have the same key usage.
> - Cert 3 has key usage non-repudiation
>
> The problem is how to select the right certificate in every suitable
> occasion when several certificates is accessed by the same application.
> Clearly certificate 4 is no problem since it is used by a separate
> application (the SET wallet). So starting the SET wallet application
> automatically selects the right certificate.
>
> The problem in this case is not even S/MIME since Alice in this example
> only uses certificate 1 in her mail application.
>
> Here the problem is her web-based applications since she use certificate
> 1,2 and 3 with her browser. So every time she is asked to make a signature
> or authenticate via TLS, there is a risk that she will select and export
> the wrong certificate. In some cases maybe with a very unpleasant result.
>

In this example, I think the client application needs two kinds of
information: which application it is and which level of security it
needs.
Something like "application identifier" and "secuirty level
identifier" are necessary ?
(Honestly speaking, I myself don't like the idea, "let's register
 an object identifier for each application in the world".
Somebody has a good idea for this ?)
Or something like "security context" which can determine
a suitable certificate from among Cert 1, 2, or 3 ?

> server can help a client application to select one proper certificate out
> of many. In the example there is just 3 certificates to choose among but
> what if there is 20 or 30?
>

This is not limited to that a server can help a client application.
I think there is a case where a client application has to "think"
which certificate it must select for itself. (I mean, without help
from other party.)

I think there is a case where an application has to
select a certificate before it begins to communicate with other
party, especially in the case of peer to peer communication.

> The way to do this is, as I would suggest, a 2 step process:
> 1) To define a general selective mechanism (such as the X.500 match rule)
> 2) Get protocols, script languages and applications to support this.
>

Regretfully, the X.500 matching rule doesn't have "application identifer",
"security level identifer",  "security context", or something like that.

I think we have to think a new mechanism outside it, if we don't
modify or enhance it any more.

> So this is not about whether selection should be done based on issuer name,
> policy OID pr something else, but instead how to define a general
> mechanisms which allows customized selection rules within a broad range of
> applications and protocols. (In step 2 it is also about how a certificate
> can be stored and marked so it won't be exported by any application without
> the consent from its owner.)
>

For this purpose, too, I think we need a general mechanism to store
and to select (namely, to manage) certificates within one machine.

> I still think that The X.500 certificateMatch rule sounds interesting.
> Is there any will to go further in this process?
>

As I said, I think we have to think a new mechanism outside the X.500
matching rules.

I also think we can use the X.500 matching rules if we have some pieces
of information within a certificate, but that in the situation which we are
thinking, we are trying to select a certificate based on the information
outside the certificate. (This is the one reason that I think of the term,
"security context".)

> To us this is a MAJOR factor for succeeding with a broad CA business case
> and the vendors picking up this line will at least be in favor in those
> procurements that I'm involved in.
>
> /Stefan

(snip)

Actually I have designed a system where there are a few applications
and a few certificates in one PC. And I faced the problem how an
application could select a suitable or correct certificate.
In the end, I used something like "application identifier" for that system.
But as I said, to "register an object identifier for each
application in the world" don't seem to be a good idea.
I have kept seeking a good solution since then ...

Sorry that I can't show a clear and good solution,
but I hope my comments will be of some help.

Regards,

Jun Yoshitake

From: Sharon Boeyen <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Mon, 28 Sep 1998 08:13:13 -0400
Sender: [email-masked]

Hi Santosh, 

This mechanism does allow Delta CRLs to be included in pkiCA entries. Both
pkiCA and deltaCRL are auxiliary object classes. Multiple auxiliary object
classes can be present in the same directory entry. Only one structural
object class can be present in that same entry. 

For example, a CA entry could also be an organization entry. In that case,
organization would be the structural object class. pkiCA would be an
auxiliary class present in the same entry. If that CA used delta CRLs then
the deltaCRL auxiliary object class would also be present in the same entry.

The primary difference between structural and auxiliary object classes is
that the structural object class is the one that is used to base the naming
and the entry's location in in a directory tree structure, that's the reason
there can only be one present in each entry. Auxiliary classes do not have
this restriction. By defining the separate class for deltas we are now able
to add them, in a uniform way, to entries of other types in future (e.g.
possibly in attribute authority).  

Hope this helps. Happy to discuss further if required, give me a call.

Sharon

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 27, 1998 12:32 PM
> To: 	[email-masked]'
> Cc: 	[email-masked]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
> 
> I find the schema acceptable for the certificates.
> 
> I do not find the schema acceptable for delta CRL.  I thought we had a
> mechanism by which delta CRL could be stored in the object class pkiCA.
> It does not seem to be the case.  Sharon, I assume you recall the
> comment and resolution in this forum.
> 
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Thursday, September 24, 1998 10:27 AM
> > Cc:	[email-masked]
> > Subject:	I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
> > 
> > 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
> > LDAPv2 Schema
> > 	Author(s)	: S. Boeyen, T. Howes, P. Richard
> > 	Filename	: draft-ietf-pkix-ldapv2-schema-02.txt
> > 	Pages		: 7
> > 	Date		: 23-Sep-98
> > 	
> >      The schema defined in this document is a minimal schema to
> > support
> >      PKIX  in  an  LDAPv2  environment,  as  defined in
> > draft-ietf-pkix-
> >      ipki2opp-07.txt. Only PKIX-specific components are specified
> > here.
> >      LDAP  servers, acting as PKIX repositories should support the
> > auxi-
> >      liary object classes defined in this  specification  and
> > integrate
> >      this  schema  specification with the generic and other
> > application-
> >      specific schemas as appropriate, depending on the  services  to
> > be
> >      supplied by that server.
> >  
> >      The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD',
> > 'RECOMMENDED',
> >      and  'MAY'  in  this document are to be interpreted as described
> > in
> >      RFC 2119.
> >  
> >      Please send comments on this document to the [email-masked]
> > mail
> >      list.
> > 
> > Internet-Drafts are 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-ldapv2-schema-02.txt".
> > A URL for the Internet-Draft is:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.tx
> > t
> > 
> > Internet-Drafts directories are located at:
> > 
> > 	Africa:	ftp.is.co.za
> > 	
> > 	Europe: ftp.nordu.net
> > 		ftp.nis.garr.it
> > 			
> > 	Pacific Rim: munnari.oz.au
> > 	
> > 	US East Coast: ftp.ietf.org
> > 	
> > 	US West Coast: ftp.isi.edu
> > 
> > Internet-Drafts are also available by mail.
> > 
> > Send a message to:	[email-masked].  In the body type:
> > 	"FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.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. << Message: Untitled Attachment >> 
> 

Date: Mon, 28 Sep 1998 11:17:31 +0200
To: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Sender: [email-masked]

Let me clarify my case.

The problem I want to solve is how to pick 1 out of many certificates
within an end user application.

An example.

Alice has 4 certificates. 
1) E-mail based ID with low security 
2) Anonymous cert used for anonymous information services. 
3) Qualified ID-certificate (with her social security number) 
4) VISA SET-certificate.

In this example: 
- Cert 1 and 2 are issued by the same CA and have the same key usage. 
- Cert 3 has key usage non-repudiation

The problem is how to select the right certificate in every suitable
occasion when several certificates is accessed by the same application.
Clearly certificate 4 is no problem since it is used by a separate
application (the SET wallet). So starting the SET wallet application
automatically selects the right certificate.

The problem in this case is not even S/MIME since Alice in this example
only uses certificate 1 in her mail application.

Here the problem is her web-based applications since she use certificate
1,2 and 3 with her browser. So every time she is asked to make a signature
or authenticate via TLS, there is a risk that she will select and export
the wrong certificate. In some cases maybe with a very unpleasant result.

In order to make this user friendly, we have to create a mechanism where a
server can help a client application to select one proper certificate out
of many. In the example there is just 3 certificates to choose among but
what if there is 20 or 30?

The way to do this is, as I would suggest, a 2 step process: 
1) To define a general selective mechanism (such as the X.500 match rule) 
2) Get protocols, script languages and applications to support this.

So this is not about whether selection should be done based on issuer name,
policy OID pr something else, but instead how to define a general
mechanisms which allows customized selection rules within a broad range of
applications and protocols. (In step 2 it is also about how a certificate
can be stored and marked so it won't be exported by any application without
the consent from its owner.)

I still think that The X.500 certificateMatch rule sounds interesting. 
Is there any will to go further in this process? 

To us this is a MAJOR factor for succeeding with a broad CA business case
and the vendors picking up this line will at least be in favor in those
procurements that I'm involved in.

/Stefan

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "'tyone '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 28 Sep 1998 18:16:45 +1000
Sender: [email-masked]

regards alan

----------
From: tyone
To: [email-masked]

Hi.

Takeshi Yoneda

environment
different

the
>general case.

From: Stefan_Salzmann/HAM/[email-masked]
To: [email-masked]
cc: Helmut_Speichermann/FRA/[email-masked], Boris_Baltzer/MUC1/[email-masked], Georg_Zyprian/FRA/[email-masked]
Date: Mon, 28 Sep 1998 09:51:59 +0200
Subject: Questions about PKIX
Sender: [email-masked]

Hi,

I have got some questions  concerning PKIX. So here they are:

When will be the code of the PKIX reference available at the MIT Web Pages?

What is Jonah in relation to PKIX?

When starts the PKIX developers converence in October?

Are there already White Papers available?

Thanks for answering,
Regards
Stefan

Date: Mon, 28 Sep 1998 11:19:19 +0900
From: tyone <[email-masked]>
To: [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Hi.

Takeshi Yoneda

>using Issuer name as selection criteria, is hopelessly insufficient for the

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 08:24:56 +1000
Sender: [email-masked]

Comments: Internet X.509 Public Key Infrastructure 
                            Operational Protocols - LDAPv2

Sorry for being my usual self. But what does this document do or solve.

All it states is use LDAP V2 to a PKI repository? and highlights the
major failings of LDAP encoding when dealing with certificate attributes
with multiple values. ie. In that the client gets the lot (every
certificate - regardless) --  and if the client goes for CRLs as well  -
and they are multi values of a CRL attribute - the client will get the
lot as well.

Lets do some rough sums. A cert = 600 - 2k bytes average 1kb, 5-10 certs
per user, 3 certs in a path.. transfer = 20- 30kb just to verify a
signature. In addition CRLs - bad sites, and they could get large.
And LDAP  accesses for the certs could be via referrals. Lets say that
we could be looking at optimistically  at 10-30 seconds of validation
time.
I would be happy to be corrected here..

Fundamental Problems with LDAP

LDAP servers are "string based" and non distributed - hence the need to
use X.500 and migrate these LDAP servers to a distributed architecture.
Not all certificates one wishes to deal with will be in your local ldap
server - they will be in the directory system that one cooperates with.

X.500 has certficate matching rules to enable selection of certificates
within a multi value attribute.

I am not sure what cert matching rules LDAP servers have or even if they
support multi valued att matching or if they are compatible with X.500.
Again the encoding restrictions in LDAP could imply the non use of
these.

It is obvious to most that LDAP is not very good generally and in the
case of PKI / certficate issues over a wider scale, totally unusable.

In addition the process one builds into an LDAP client to deal with
referrals and LDAP certficate servers has to be lot larger and therefore
problematic, than that that uses distributed directories with sound
matching rules.

ie. the best it can get depends on the tools to hand.

I therefore beg why the document is being put forward because IMHO - it
promotes systems to be built that will not provide the business utility
demanded by companies using large scale EC/509 technologies. The result
can only be commercial disasters and pain for both suppliers and the
poor customer.

Oh well - 

regards alan

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Sun, 27 Sep 1998 12:32:11 -0400
Sender: [email-masked]

I find the schema acceptable for the certificates.

I do not find the schema acceptable for delta CRL.  I thought we had a
mechanism by which delta CRL could be stored in the object class pkiCA.
It does not seem to be the case.  Sharon, I assume you recall the
comment and resolution in this forum.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, September 24, 1998 10:27 AM
> Cc:	[email-masked]
> Subject:	I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
> 
> 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
> LDAPv2 Schema
> 	Author(s)	: S. Boeyen, T. Howes, P. Richard
> 	Filename	: draft-ietf-pkix-ldapv2-schema-02.txt
> 	Pages		: 7
> 	Date		: 23-Sep-98
> 	
>      The schema defined in this document is a minimal schema to
> support
>      PKIX  in  an  LDAPv2  environment,  as  defined in
> draft-ietf-pkix-
>      ipki2opp-07.txt. Only PKIX-specific components are specified
> here.
>      LDAP  servers, acting as PKIX repositories should support the
> auxi-
>      liary object classes defined in this  specification  and
> integrate
>      this  schema  specification with the generic and other
> application-
>      specific schemas as appropriate, depending on the  services  to
> be
>      supplied by that server.
>  
>      The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD',
> 'RECOMMENDED',
>      and  'MAY'  in  this document are to be interpreted as described
> in
>      RFC 2119.
>  
>      Please send comments on this document to the [email-masked]
> mail
>      list.
> 
> Internet-Drafts are 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-ldapv2-schema-02.txt".
> A URL for the Internet-Draft is:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.tx
> t
> 
> Internet-Drafts directories are located at:
> 
> 	Africa:	ftp.is.co.za
> 	
> 	Europe: ftp.nordu.net
> 		ftp.nis.garr.it
> 			
> 	Pacific Rim: munnari.oz.au
> 	
> 	US East Coast: ftp.ietf.org
> 	
> 	US West Coast: ftp.isi.edu
> 
> Internet-Drafts are also available by mail.
> 
> Send a message to:	[email-masked].  In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.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. << Message: Untitled Attachment >> 

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "'Stefan Santesson '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Sun, 27 Sep 1998 09:30:02 +1000
Sender: [email-masked]

just thoughts
regards alan

----------
From: Stefan Santesson

All,

Comments, suggestions.

/Stefan Santesson

Date: Fri, 25 Sep 1998 09:24:36 -0700
To: Denis Pinkas <[email-masked]>, IETF-PXIX <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: Archive cutoff & Retention period
Sender: [email-masked]

Denis,

At 10:03 AM 9/23/98 -0700, Denis Pinkas wrote:
>
>The "retention period" should be supported by all OCSP responders
>and thus should be part of the standard response. Adding a
>"retentionPeriod" after the "produceAt" from the ResponseData would
>be simpler than defining an extension.

We didn't want to break the response syntax, especially in light of the
fact that support for long term retention of status data is not a core
requirement.

>Then, let us address the « Archive Cutoff » issue.
>
>If we were to support the archiving capability, with e.g. a 7 year
>retention, we would need an additional time parameter in the request
>to point to the equivalent of the right CRL issued at that time e.g.
>7 years ago. This parameter is currently not present. Unless it is
>added, the function cannot work. We thus have two options : add the
>missing parameter or delete this capability. Opinions ? 

As the public debate on this issue had concluded, the requirement is to
enable responders to assert a bound on the historical accuracy of their
responses.  The archive cutoff extension satisfies this requirement.  This
function speaks only to the most current status of the certificate, not to
its status at any point in time.

Mike

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-08.txt
Date: Fri, 25 Sep 1998 10:27:54 -0400
Sender: [email-masked]

--NextPart

Note: This revision reflects comments received during the last call period.

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 
                          Operational Protocols - LDAPv2
	Author(s)	: S. Boeyen, T. Howes, P. Richard
	Filename	: draft-ietf-pkix-ipki2opp-08.txt
	Pages		: 12
	Date		: 24-Sep-98
	
     The protocol described in this document is designed to satisfy some
     of  the  operational  requirements within the Internet X.509 Public
     Key Infrastructure (IPKI).  Specifically, this  document  addresses
     requirements  to  provide access to Public Key Infrastructure (PKI)
     repositories for the purposes of  retrieving  PKI  information  and
     managing  that  same  information.  The mechanism described in this
     document is based on  the  Lightweight  Directory  Access  Protocol
     (LDAP) v2, defined in RFC 1777, defining a profile of that protocol
     for use within the IPKI and updates encodings for certificates  and
     revocation  lists  from  RFC 1778. Additional mechanisms addressing
     PKIX operational requirements are specified in separate documents.
 
     The key words  'MUST',  'REQUIRED',  'SHOULD',  'RECOMMENDED',  and
     'MAY'  in  this  document are to be interpreted as described in RFC
     2119.
 
     Please send comments on this document to the [email-masked] mail
     list.

Internet-Drafts are 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-ipki2opp-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki2opp-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki2opp-08.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-ipki2opp-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki2opp-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 25 Sep 1998 13:34:29 +0200
To: "Miklos, Sue A." <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Sender: [email-masked]

Thank you Sue,

Comments, suggestions!

/Stefan Santesson 

Date: Fri, 25 Sep 1998 18:29:35 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

I have two comments.

1. I'd like to clarify the scope.

Is it limited to the case where one party
which to assist another party ?
I suggest that it include the case
where a person has multiple certificates
in his / her PC, WS, etc. It will be more
useful and more efficient if there is
a standardized mechanism for the case
like this rather than that each application
manages its certificates in its own way
on one machine. Some applications could
hold a certificate in common.

2. It would be better that we consider
the generation management of a certificate.

Suppose a certificate has expired and you
get the new certificate on your PC. Namely,
you have two certificates on your PC, the old
one and the new one. Attention should be paid
not to let an application select the old one.
(Of course, things are easy if the old one is deleted.
But is it really always good for all the cases, all applications,...?)
(Issuer and Serial Number is nice, but you need
the mechanism to record "this serial number is for
the new one" when you get it for the first time.)

Jun Yoshitake

Stefan Santesson wrote:

> Accurata Systems$BgL(Berhet AB
> 216 42  Malm$Bö (B                  Fax. +46-40 150790

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 24 Sep 1998 12:02:05 -0400
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_000_01BDE7B3.26345CD0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

>Weinstein, Netscape, the problem of certificate selection in an =
environment
>where the client is populated with many similar certificates for =
different
>S/MIME, Java, Java script, etc, where signing and encryption based on =
an
>using Issuer name as selection criteria, is hopelessly insufficient for =
the
>general case.
>
>In fact we can NEVER claim that we have an X.509 based architecture =
ready
>WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD =
START.
>could be used as a common base for enhancing TLS, Java, Java script, =
S/MIME
>server, server to server, client to client; I.e in any case where one =
party
>which to assist another party in selecting an appropriate certificate =
for
>Accurata Systems=E4kerhet AB    =20
>Lotsgatan 27 D                  Tel. +46-40 152211             =20
>216 42  Malm=F6                   Fax. +46-40 150790             =20

------ =_NextPart_000_01BDE7B3.26345CD0
Content-Type: application/msword; name="MATCH.DOC"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAAAgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////HgAAAP7///8fAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA
ACAAAAD+/////v///yEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA
LAAAAP7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8=

------ =_NextPart_000_01BDE7B3.26345CD0--

Date: Thu, 24 Sep 1998 08:05:20 -0700
From: Michael McNeil <[email-masked]>
Organization: GMT
To: Denis Pinkas <[email-masked]>
CC: Stephen Kent <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], Jeffrey Schiller <[email-masked]>
Subject: Re: meeting minutes
Sender: [email-masked]

Denis Pinkas wrote:
>Michael,
>As you say it, the minutes from the meeting are correct.

>>Stephen Kent wrote:
>>[snip]
>>>NEW TOPICS:
>>>- Timestamp & Notary proposals (Carlisle Adams)
>>>
>>>Several folks continuing work on these topics and have published
>>>an independent draft on these topics. The authors received a fair
>>>amount of private feedback, and hope to be able to bring forward a
>>>well-formed proposal. Jeff Schiller gave his permission to bring
>>>this into the WG, based on the WG having made substantial progress
>>>on the other work items. Thus we will expand the charter to
>>>encompass these topics.

>>This is what occurred during the PKIX sessions at the 42nd IETF
>>meeting with regards to timestamping; however the above is not
>>the whole story.
>>
>>Between sessions at the IETF meeting I talked with various people
>>about the new Internet-Draft (authored by Dave Mills, Todd Glassey,
>>and me) which extends the NTP protocol towards serving as a vehicle
>>for PKI certified and secured time ("ephemeral" time; "what time is
>>it *now*?" time), as well as also providing for *timestamps* of
>>data -- within the same protocol, essentially as gravy (a different
>>usage, I admit).

>From your short description,  people might think that the two drafts
>are equivalent.

Yes, thank you for pointing that out.  The two sets of drafts are quite
distinct, of course, as we're well aware.  I thought insufficiently of
the readers' perspective in wording the description unfortunately.

>Let me highlight some of the main differences:
>Let us call:
>
>"draft 1", the draft:
>ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt

Et al.

>and "draft 2", the draft:
>ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt
>
>Draft 1 is all in ASN1, as the rest of the other messages supported
>by PKIX, e.g. CMP. So it is in the spirit of the other documents. On
>the contrary, Draft 2 is supporting 32 bits words and is much more
>compact (unless that advantage will be lost by many extensions !)

We think not, but good point.

>The time formats are different between draft 1 and 2. Draft 1 is
>using the same time format as the rest of the PKIX documents, while
>draft 2 is using a 32 bits time representation.

NTP actually uses 64 bits of time, with 32 bits of fractional second
information.  The 32-bit seconds count will roll over in 2038; I have
suggested (Dave Mills and I disagree as to the desirability of this)
that 8-bit extensions to the time fields be added in an extension field.

>Draft 1 supports the time stamping of an imprint and as a side
>effect, may provide a trusted time when using the optional nonces.

The question is what would be the quality of the time (ephemeral time)
passed using that protocol.  A heavyweight protocol almost by definition
takes more time to convey than a lightweight one -- and it's the quality
of the time itself that we're interested in here (ignoring timestamps
for the moment).  A longer time to pass the time futzes the precision of
the time.  Moreover, draft 1 lacks the fractional seconds information
NTP maintains, lacks the extra fields NTP possesses which allow it to
communicate the accuracy of the time and the last time that the server's
time was updated from a reliable source.  These last deficiencies can be
fixed, of course, in the draft 1 proposal (though perhaps not the
"heavyweight" issue); any deficiencies in the draft 2 protocol noted
below can also be repaired (except perhaps the "lightweight" issue). ;-)

>Draft 2 is unclear about time stamping, in particular the indication
>of the hash function used for the imprint and its protection. It
>allows various extension fields and so the minimum format to be
>supported is left undefined.

Draft 2 is a work in progress (this last is the second version), and
admittedly is less finished in this regard than draft 1.  We expect to
have another Internet-Draft ready for publication, with details of the
important extensions fields fleshed out, by the 43rd IETF in December.

>It is also unclear about the replay protection when only the time
>is returned (unless that information is present is some other
>documents ?).

NTP has inherent replay resistance in that if your time is already
reasonably good, replay attacks are instantly visible as being old. 
Moreover, NTP normally (despite conveying an absolute time) only steers
the time -- it doesn't reset a machine to a radically different time,
appearing out of the blue within an NTP packet.  Even so, additional
authentication is desirable to present spurious NTP attacks; that is the
point of the "draft 2" Internet-Draft.  A more fundamental protection
against replay attacks, from a cryptographic point of view, is to
require that the client as a sanity check do a unicast probe of the
server every now and then, rather than depending on broadcast packets,
including random bits of its own in its request -- which then get echoed
back in the signed NTP reply from the server.  Detecting its bits in the
reply, the client knows it's in response to its own most recent request.

>>I spoke with Jeff Schiller about this.  After he'd had a chance
>>to look over the Internet-Draft (i.e.,
>><draft-mills-ntp-auth-coexist-01.txt>), we spoke again, very near
>>the end of the IETF meeting.  Jeff at that time suggested that
>>since it was now apparent to him that the issue of PKI and time
>>goes well beyond the question of timestamps to the issue of how
>>secure *time itself* can be conveyed over an insecure network, he
>>thought that perhaps the PKIX working group was not equipped to
>>properly address this expanded issue -- or at least Jeff thought
>>the IESG ought to be consulted first on the question before the
>>issue of PKIX handling it or a separate "time" working group
>>being set up is laid to rest.

>From what is above, "draft 2" would not be usable in a PKIX
>environment, where the compactness of the messages is not the
>issue, since the Time Stamp will be used mostly either in a
>store and forward environment or in a local environment.
>
>However, there may be some good reasons to have a 32 bits
>oriented and more compact protocol for acquiring a secure time
>for other environments and therefore it can make sense to have
>two protocols.

I agree.

>>Thus the issue stands as far as I know.  I've addressed two e-mails
>>to Jeff since the IETF meeting (on 8 and 21 September) but so far
>>have not received a reply (I assume it takes time to poll the IESG
>>membership).  I have no particular stake in which way the decision
>>goes (except I think *some* working group needs to address time
>>*and* timestamping),

>I am not sure that a *single* working group needs to address both
>time and timestamping.

Good point.

>As a good example, we have already have the PKIX and the SPKI
>working groups: PKIX is using ASN.1, while SPKI does not.
>A similar parallelism ! :-)

A parallelism I hope doesn't draw a rain of stones and bricks!  ;-)

>>but wished to alert you that despite the outcome of the PKIX sessions,
>>the question of whether PKIX handles it appears not quite settled.

Thank you for your comments, Denis!

Regards,
Michael McNeil
GMT
[email-masked]
1-831-438-7811

Date: Thu, 24 Sep 1998 16:26:50 +0200
From: Mark Shuttleworth <[email-masked]>
Reply-To: [email-masked]
Organization: Thawte Consulting
To: [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms78C9DE34404C8A045EF33A31
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiya

--
Mark Shuttleworth
Thawte
--------------ms78C9DE34404C8A045EF33A31
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms78C9DE34404C8A045EF33A31--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Thu, 24 Sep 1998 10:27:24 -0400
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 LDAPv2 Schema
	Author(s)	: S. Boeyen, T. Howes, P. Richard
	Filename	: draft-ietf-pkix-ldapv2-schema-02.txt
	Pages		: 7
	Date		: 23-Sep-98
	
     The schema defined in this document is a minimal schema to  support
     PKIX  in  an  LDAPv2  environment,  as  defined in draft-ietf-pkix-
     ipki2opp-07.txt. Only PKIX-specific components are specified  here.
     LDAP  servers, acting as PKIX repositories should support the auxi-
     liary object classes defined in this  specification  and  integrate
     this  schema  specification with the generic and other application-
     specific schemas as appropriate, depending on the  services  to  be
     supplied by that server.
 
     The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
     and  'MAY'  in  this document are to be interpreted as described in
     RFC 2119.
 
     Please send comments on this document to the [email-masked] mail
     list.

Internet-Drafts are 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-ldapv2-schema-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.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-ldapv2-schema-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldapv2-schema-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dcs-00.txt
Date: Thu, 24 Sep 1998 10:26:39 -0400
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 
                          Data Certification Server Protocols
	Author(s)	: C. Adams, R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-00.txt
	Pages		: 14
	Date		: 23-Sep-98
	
This document describes a general data certification service and the
protocols to be used when communicating with it.  The Data Certification
Server  is a Trusted Third Party (TTP) that can be used as one component
in building reliable non-repudiation services (see [ISONR]).  Useful
Data Certification Server responsibilities in a PKI are to validate
signatures and to provide up-to-date information regarding the status of
public key certificates.  We give examples of how to use the Data
Certification Server to extend the lifetime of a signature beyond key
expiry or revocation and to query the Data Certification Server
regarding the status of a public key certificate.
 
      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 [RFC2119].

Internet-Drafts are 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-dcs-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-dcs-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-dcs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dcs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-00.txt
Date: Thu, 24 Sep 1998 10:26:34 -0400
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 
                          Time Stamp Protocols
	Author(s)	: C. Adams, P. Cain, B. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-00.txt
	Pages		: 15
	Date		: 23-Sep-98
	
This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]).  In order to reduce the amount of trust required of a TSA we
introduce (in Appendix C) the optional Temporal Data Authority (TDA)
whose function is to provide further corroborating evidence of the time
contained in the token.  We also give an example of how to place a
signature at a particular point in time, from which the appropriate
certificate status information (e.g. CRLs) may be checked.

Internet-Drafts are 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-time-stamp-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-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-time-stamp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-time-stamp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-11.txt
Date: Thu, 24 Sep 1998 10:26:08 -0400
Sender: [email-masked]

--NextPart

Note: This revision reflects comments received during the last call period.

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 Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, T. Polk, D. Solo
	Filename	: draft-ietf-pkix-ipki-part1-11.txt
	Pages		: 128
	Date		: 23-Sep-98
	
   This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
   in the Internet.  An overview of the approach and model are provided
   as an introduction.  The X.509 v3 certificate format is described in
   detail, with additional information regarding the format and
   semantics of Internet name forms (e.g., IP addresses). Standard
   certificate extensions are described, and a set of required
   extensions is defined.  The X.509 v2 CRL format is described and a
   required extension set is defined as well.  An algorithm for X.509
   certificate path validation is described. Supplemental information is
   provided describing the format of public keys and digital signatures
   in X.509 certificates for common Internet public key encryption
   algorithms (i.e., RSA, DSA, and Diffie-Hellman).  ASN.1 modules and
   examples are provided in the appendices.
 
   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.

Internet-Drafts are 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-ipki-part1-11.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-11.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-part1-11.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-ipki-part1-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part1-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 24 Sep 1998 09:56:50 -0400
To: "Todd S. Glassey" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Amending the PKIX-WG Charter to reflect the addition of timestamping
Cc: [email-masked]
Sender: [email-masked]

It looks okay to me.....

At 07:17 PM 9/22/98 -0700, you wrote:
>Hi All, back in February we were working to amend the PKI WG's charter to
>encompass timestamping and the certified timer resources that enable these
>facilities. Now that Jeff Schiller has OK'd PKIX's having its own
>timestamping/timebase facility we need to finish the charter update process.
>here then is a proposed charter for your review and comments.
>
>Thanks,
>
>-----
>
>Todd Glassey
>
>Stephen Kent's report of the meeting minutes - excerpt below -
>
>- Timestamp & Notary proposals (Carlisle Adams)
>
>Several folks continuing work on these topics and have published an
>independent draft on
>these topics. The authors received a fair amount of private feedback, and
>hope to be able to
>bring forward a well-formed proposal. Jeff Schiller gave his permission to
>bring this into
>the WG, based on the WG having made substantial progress on the other work
>items. Thus
>we will expand the charter to encompass these topics.
>
>
>----- BEGINNING OF CHARTER TEXT ----
>
>Public-Key Infrastructure (X.509) (PKIX)
>--------------------------------------------------
>
> Charter
> Last Modified: September 18, 1998
>
> Current Status: Active Working Group
>
>Chair(s):
>Stephen Kent <[email-masked]>
>Warwick Ford <[email-masked]>
>
>Security Area Director(s):
>Jeffrey Schiller <[email-masked]>
>Marcus Leech <[email-masked]>
>
>Security Area Advisor:
>Jeffrey Schiller <[email-masked]>
>
>Mailing Lists:
>General Discussion:[email-masked]
>To Subscribe: [email-masked]
>In Body: subscribe (In Body)
>Archive: http://www.imc.org/ietf-pkix
>
>Description of Working Group:
>Many Internet protocols and applications which use the Internet employ
>public-key technology for security purposes and require a public-key
>infrastructure (PKI) to securely manage public keys for widely-distributed
>users or systems.  The X.509 standard constitutes a widely-accepted basis
>for such
>an infrastructure, defining data formats and procedures related to
>distribution
>of public keys via certificates digitally signed by certification
>authorities
>(CAs).
>
>For example, RFC 1422 specified the basis of an X.509-based PKI, targeted
>primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).
>Since RFC 1422 was issued, application requirements for an Internet PKI have
>broadened tremendously, and the capabilities of X.509 have advanced with the
>development of standards defining the X.509 version 3 certificate and
>version 2 certificate revocation list (CRL).
>
>Charter of the Working Group:
>The charter of the working group will be to develop Internet standards
>needed to support the use of an X.509-based PKI.  The goal of this Working
>Group (WG)
>will be to further facilitate the use of X.509 certificates in applications
>that
>make use of the Internet and to promote interoperability between different
>implementations choosing to make use of X.509 certificates.
>
>The resulting PKI is intended to provide a framework, which will support a
>range of trust/hierarchy environments and a range of usage environments
>(RFC1422
>is an example of one such model).
>
>Candidate applications to be served by this PKI include, but are not limited
>to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), IPSEC protocols, Internet
>payment protocols, time based authentication, timestamping, and www
>protocols.
>
>This project will not preclude use of non-infrastructure public-key
>distribution techniques nor of non-X.509 PKIs by such applications.  Efforts
>will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
>project.
>
>The group will focus on tailoring and profiling the features available in
>the v3 X.509 certificate to best match the requirements and characteristics
>of the
>Internet environment.
>
>Other topics to be addressed potentially include:
>
>     * Alternatives for CA-to-CA certification links and structures,
>including
>       guidelines for constraints
>
>     * Revocation alternatives, including profiling of X.509 v2 CRL
>extensions
>     * Certificate and CRL distribution options (X.500-based,
>non-X.500-based)
>     * Guidelines for policy definition and registration
>     * Administrative protocols and procedures, including certificate
>       generation, revocation notification, cross-certification, and
>key-pair
>       updating
>     * Naming and name forms (how entities are identified, e.g., email
>       address, URN, DN, misc.)
>     * Generation of client key pairs by the PKI
>     * Services that support non-repudiation.  This can include sources of
>       credible time data and/or certificate path validation services.
>
>----- END OF CHARTER TEXT ----
>

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "'Denis Pinkas'" <[email-masked]>
Cc: [email-masked]
Subject: RE: X.509 Documentation
Date: Thu, 24 Sep 1998 08:51:15 -0400
Sender: [email-masked]

On the server that Denis pointed to, you'll find the final text of the 1997
edition of X.509 (as submitted to the ITU and ISO for publication) at:

ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

(the primary reason this is not yet available for purchase from either ITU
or ISO is that they will not publish or sell it until all the other parts of
the 1997 X.500 Series are also ready (soon we're told by the editor).

As for current work underway in X.509, there is a Working Document which is
currently being revised to reflect the outcome of the September meeting. The
previous version of that document is available at:

ftp://ftp.bull.com/pub/OSIdirectory/Phoenix98Output/CertificateExtensionsWD.
doc

When the revisions are complete (within 2 months) the new version will
likely be found in:

ftp://ftp.bull.com/pub/OSIdirectory/Beijing98/Vancouver98/

These two documents provide a complete picture of the X.509 activity except
of course for defect reports. These are recorded together with the defects
on the other parts of the X.500 Series at the bull.com site, but at present
it is somewhat out of date (should be updated within 2 months as well).

Hope this helps.
Sharon

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	September 24, 1998 2:59 PM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	Re: X.509 Documentation
> 
> [email-masked] a écrit:
> 
> > Ladies and Gentlemen,
> >
> > Some body posted an address of a site where a document for X.509 can be
> > obtained.
> > Can that kind person post the information again?
> 
> Take a look at :ftp://ftp.bull.com/pub/OSIdirectory/
> 
> Denis
> 
> > Thanks,
> >
> > CryptoNEWS
> 
> 
> 

Date: Thu, 24 Sep 1998 14:41:23 +0200
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: NEW Data type for certificate selection ?
Sender: [email-masked]

All,

Comments, suggestions.

/Stefan Santesson

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: basic constraint extension
Reply-To: [email-masked]
Date: Thu, 24 Sep 1998 23:59:34 (NZST)
Sender: [email-masked]

>the draft-ietf-pkix-ipki-part1-10 says the basic constraint extension MUST 
>appear as a critical extension in all CA certificates but it SHOULD NOT 
>appear in end entity certificates.
>
>Why should the basic constraint extension not appear in end entity 
>certificates? 
 
Looking back through the different versions, this has been in there since at 
least -08, although not worded quite as strongly as this.  It seems like a Bad 
Thing, since this clashes with the (US) federal profile and Australian profile 
and... well I'm not going to enumerate them all, but unless there's some 
really good reason for it I don't see why it should be absent, especially 
since the generally accepted way (other profiles notwithstanding) seems to be 
to encode it as an empty sequence in end-user certs.
 
Peter.

Date: Thu, 24 Sep 1998 11:59:24 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: X.509 Documentation
Sender: [email-masked]

[email-masked] a écrit:

> Ladies and Gentlemen,
>
> Some body posted an address of a site where a document for X.509 can be
> obtained.
> Can that kind person post the information again?

Take a look at :ftp://ftp.bull.com/pub/OSIdirectory/

Denis

> Thanks,
> CryptoNEWS

Date: Thu, 24 Sep 1998 11:28:15 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael McNeil <[email-masked]>
CC: Stephen Kent <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], Jeffrey Schiller <[email-masked]>
Subject: Re: meeting minutes
Sender: [email-masked]

Michael,

As you say it, the minutes from the meeting are correct.

> Stephen Kent wrote:
> [snip]
> >NEW TOPICS:
> >- Timestamp & Notary proposals (Carlisle Adams)
> >
> >Several folks continuing work on these topics and have published
> >an independent draft on these topics. The authors received a fair
> >amount of private feedback, and hope to be able to bring forward a
> >well-formed proposal. Jeff Schiller gave his permission to bring
> >this into the WG, based on the WG having made substantial progress
> >on the other work items. Thus we will expand the charter to
> >encompass these topics.
>
> This is what occurred during the PKIX sessions at the 42nd IETF meeting
> with regards to timestamping; however the above is not the whole story.
>
> Between sessions at the IETF meeting I talked with various people about
> the new Internet-Draft (authored by Dave Mills, Todd Glassey, and me)
> which extends the NTP protocol towards serving as a vehicle for PKI
> certified and secured time ("ephemeral" time; "what time is it *now*?"
> time), as well as also providing for *timestamps* of data -- within the
> same protocol, essentially as gravy (a different usage, I admit).

>From your short description,  people might think that the two drafts are
equivalent. Let me highlight some of the main differences:

Let us call:

"draft 1", the draft:
ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt and
"draft 2", the draft:
ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt

Draft 1 is all in ASN1, as the rest of the other messages supported by PKIX,
e.g. CMP. So it is in the spirit of the other documents. On the contrary,
Draft 2 is supporting 32 bits words and is much more compact (unless that
advantage will be lost by many extensions !)

The time formats are different between draft 1 and 2. Draft 1 is using the
same time format as the rest of the PKIX documents, while draft 2 is using a
32 bits time representation.

Draft 1 supports the time stamping of an imprint and as a side effect, may
provide a trusted time when using the optional nonces.

Draft 2 is unclear about time stamping, in particular the indication of the
hash function used for the imprint and its protection. It allows various
extension fields and so the minimum format to be supported is left
undefined. It is also unclear about the replay protection when only the time
is returned (unless that information is present is some other documents ?).

> I spoke with Jeff Schiller about this.  After he'd had a chance to look
> over the Internet-Draft (i.e., <draft-mills-ntp-auth-coexist-01.txt>),
> we spoke again, very near the end of the IETF meeting.  Jeff at that
> time suggested that since it was now apparent to him that the issue of
> PKI and time goes well beyond the question of timestamps to the issue of
> how secure *time itself* can be conveyed over an insecure network, he
> thought that perhaps the PKIX working group was not equipped to properly
> address this expanded issue -- or at least Jeff thought the IESG ought
> to be consulted first on the question before the issue of PKIX handling
> it or a separate "time" working group being set up is laid to rest.

>From what is above, "draft 2" would not be usable in a PKIX environment,
where the compactness of the messages is not the issue, since the Time Stamp
will be used mostly either in a store and forward environment or in a local
environment.

However, there may be some good reasons to have a 32 bits oriented and more
compact protocol for acquiring a secure time for other environments and
therefore it can make sense to have two protocols.

> Thus the issue stands as far as I know.  I've addressed two e-mails to
> Jeff since the IETF meeting (on 8 and 21 September) but so far have not
> received a reply (I assume it takes time to poll the IESG membership).
> I have no particular stake in which way the decision goes (except I
> think *some* working group needs to address time *and* timestamping),

I am not sure that a *single* working group needs to address both time and
timestamping. As a good example, we have already have the PKIX and the SPKI
working groups: PKIX is using ASN.1, while SPKI does not. A similar
parallelism ! :-)

Regards,

Denis

> but wished to alert you that despite the outcome of the PKIX sessions,
> the question of whether PKIX handles it appears not quite settled.
>
> Regards,
> Michael McNeil
> GMT
> [email-masked]
> 1-831-438-7811

From: [email-masked]
Date: Thu, 24 Sep 1998 05:11:36 EDT
To: [email-masked]
Subject: X.509 Documentation
Sender: [email-masked]

Ladies and Gentlemen,

Some body posted an address of a site where a document for X.509 can be
obtained.
Can that kind person post the information again?

Thanks,

CryptoNEWS

Date: Wed, 23 Sep 1998 20:39:10 -0700
From: Michael McNeil <[email-masked]>
Organization: GMT
To: Stephen Kent <[email-masked]>, Warwick Ford <[email-masked]>
CC: [email-masked], Jeffrey Schiller <[email-masked]>
Subject: Re: meeting minutes
Sender: [email-masked]

Stephen Kent wrote:
[snip]
>NEW TOPICS:
>- Timestamp & Notary proposals (Carlisle Adams)
>
>Several folks continuing work on these topics and have published
>an independent draft on these topics. The authors received a fair
>amount of private feedback, and hope to be able to bring forward a
>well-formed proposal. Jeff Schiller gave his permission to bring
>this into the WG, based on the WG having made substantial progress
>on the other work items. Thus we will expand the charter to
>encompass these topics.

This is what occurred during the PKIX sessions at the 42nd IETF meeting
with regards to timestamping; however the above is not the whole story.

Between sessions at the IETF meeting I talked with various people about
the new Internet-Draft (authored by Dave Mills, Todd Glassey, and me)
which extends the NTP protocol towards serving as a vehicle for PKI
certified and secured time ("ephemeral" time; "what time is it *now*?"
time), as well as also providing for *timestamps* of data -- within the
same protocol, essentially as gravy (a different usage, I admit).

I spoke with Jeff Schiller about this.  After he'd had a chance to look
over the Internet-Draft (i.e., <draft-mills-ntp-auth-coexist-01.txt>),
we spoke again, very near the end of the IETF meeting.  Jeff at that
time suggested that since it was now apparent to him that the issue of
PKI and time goes well beyond the question of timestamps to the issue of
how secure *time itself* can be conveyed over an insecure network, he
thought that perhaps the PKIX working group was not equipped to properly
address this expanded issue -- or at least Jeff thought the IESG ought
to be consulted first on the question before the issue of PKIX handling
it or a separate "time" working group being set up is laid to rest.

Thus the issue stands as far as I know.  I've addressed two e-mails to
Jeff since the IETF meeting (on 8 and 21 September) but so far have not
received a reply (I assume it takes time to poll the IESG membership). 
I have no particular stake in which way the decision goes (except I
think *some* working group needs to address time *and* timestamping),
but wished to alert you that despite the outcome of the PKIX sessions,
the question of whether PKIX handles it appears not quite settled.

Regards,
Michael McNeil
GMT
[email-masked]
1-831-438-7811

Date: Wed, 23 Sep 1998 11:05:32 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
Sender: [email-masked]

I thought this might be of interest to the PKIX WG.

--Paul Hoffman, Director
--Internet Mail Consortium

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
>Date: Wed, 23 Sep 1998 10:43:01 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Transport Layer Security Working Group of 
>the IETF.
>
>	Title		: An Internet AttributeCertificate Profile 
>                          for Authorization
>	Author(s)	: S. Farrell
>	Filename	: draft-ietf-tls-ac509prof-00.txt
>	Pages		: 11
>	Date		: 22-Sep-98
>	
>   Authorization support is required for various Internet
>   protocols, for example, TLS, CMS and their consumers,
>   and others. The X.509 AttributeCertificate provides a
>   structure which can form the basis for such services
>   [X.509]. This specification defines two profiles (a
>   simple one and a 'full' one)  for the use of X.509
>   AttributeCertificates to provide such authorization
>   services.
>
>Internet-Drafts are 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-tls-ac509prof-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nis.garr.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[email-masked].  In the body type:
>	"FILE /internet-drafts/draft-ietf-tls-ac509prof-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.
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-tls-ac509prof-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt>

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Steve Kent'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>
Subject: Revised LDAPv2 specs have been submitted
Date: Wed, 23 Sep 1998 09:57:43 -0400
Sender: [email-masked]

A revision of the PKIX LDAPv2 protocol profile has been submitted and notice
should appear shortly. The only reason for this revision is because the
previous one (in the hands of the IESG pending submission of an accompanying
schema spec) exires this month. No changes other than updating version
number, date and the name of the ietf-pkix mail list were made.

A revision of the PKIX LDAPv2 schema I-D has been submitted and notice
should appear shortly. This revision addresses the comments submitted during
PKIX WG last call.

Sharon

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Wed, 23 Sep 1998 13:32:27 +0200
To: Al Arsenault <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Al,

I totally agree with everything you say in this last mail.

/Stefan

At 08:15 AM 9/22/98 -0400, Al Arsenault wrote:
>At 06:25 AM 9/22/98 +0200, Stefan Santesson wrote:
>>Al,
>>
>>Just a short reply to CA disaster (See below).
>>
>>Thanks for your reply, I still disagree to the disaster part.
>>
>>CA2 does not have to be dismanteled, since CA 2:s key is intact.
>>What has to be done is that:
>>- CA1 is rebuilt with new key
>>- The compromise of CA1 and its new key has to be communicated with
>>out-of-band means
>>- CA1 cross certify CA2 (and other CA:s) using the new key
>>- New cross certificates to CA1 has to be issued and published by other
CA:s.
>>
>>Now all certificates issued by CA2 before the disaster of CA1 can be used
>>and trusted.
>>This since the disaster of CA1 didn't destroy CA2, just the link to CA2
>>from CA1.
>>
>>/Stefan
>
>Stefan,
>
>	The more I think about this, the more I realize we agree.  It's the words
>that need figuring out. Perhaps the words in the draft roadmap are too
>strong; we'll have to think about that.
>
>	First, let me note that when CA1 and CA2 are cross-certified - that is,
>have a peer relationship, with neither subordinate to the other - I agree
>with you about what happens when CA1's key is compromised.
>
>	Now, let us assume that there is a hierarchical relationship - CA2 is
>subordinate to CA1. This means to me that the trust anchor used by end
>entities below CA2 is  not CA2 - it's CA1.  When CA1's key is discovered to
>be compromised, what you do is:
>
>	1 - communicate out of band the compromise. This means that CA2 and all
>entities below it are essentially "out of action" temporarily; since CA1 is
>the trust anchor, there's no way to construct a valid cert path
>
>	2 - reconstitute CA1 with a new key;
>
>	3 - get CA2's key to CA1 for certification (most likely through
>out-of-band means). Yes, this can still be the same key; since CA2's key
>wasn't compromised, it can still be used, and it will make things easier in
>that you don't have to go re-signing end-entity certs with a new CA2 key.
>
>Now, you're back in action.  
>
>If you agree that this is right, we can figure out words that say that.
>The point I wanted to convey is that the entire PKI is dead in this case
>until CA1 is brought up and a new CA2 cert is signed, because you can't
>construct a valid path back to a valid trust anchor.
>
>(Of course, if trust anchor's compromised key happens to be on all
>end-entity hardware tokens in a form that can't easily be changed, you've
>still got a problem, but that's beyond the scope of PKIX :-)
>
>				Al Arsenault
>
>- the above opinions are my own.  They may or may not reflect the opinions
>of my employer or of any other organization with which I have a relationship.
>
>
>
>
>

Date: Wed, 23 Sep 1998 10:03:55 -0700
From: Denis Pinkas <[email-masked]>
To: IETF-PXIX <[email-masked]>
Subject: Archive cutoff & Retention period
Sender: [email-masked]

Archive cutoff & Retention period

This item has been separated from my list of other comments since it
might start a new thread.

On page 12 there is section 5.4.4. named « Archive Cutoff ».

In part PKIX-1 on page 12, we have the following sentence: 

   An entry may be removed from
   the CRL after appearing on one regularly scheduled CRL issued
beyond
   the revoked certificate's validity period.

This means that a revoked entry has to stay at least "little bit"
after the expiration date of the certificate. In practice this is a
few days, but not necessarily years because the size of the
information to keep would be pretty big. So we need to make a
difference between a "retention period" of a few days and a possible
archiving of the status information during years (see later).

The "retention period" should be supported by all OCSP responders
and thus should be part of the standard response. Adding a
"retentionPeriod" after the "produceAt" from the ResponseData would
be simpler than defining an extension.

Then, let us address the « Archive Cutoff » issue.

If we were to support the archiving capability, with e.g. a 7 year
retention, we would need an additional time parameter in the request
to point to the equivalent of the right CRL issued at that time e.g.
7 years ago. This parameter is currently not present. Unless it is
added, the function cannot work. We thus have two options : add the
missing parameter or delete this capability. Opinions ? 

Denis

Date: Wed, 23 Sep 1998 09:59:40 -0700
From: Denis Pinkas <[email-masked]>
To: IETF-PXIX <[email-masked]>
Subject: Minor comments on OCSP-06
Sender: [email-masked]

Here are a few minor/editorial comments on OCSP-06. An additional
comment (on "Archive cutoff") has been separated from this list of
comments since it might generate a new thread. Some of them might be
a duplication of comments already made.

1. On page 2, in the second paragraph of the section 3 a sentence
may let think that once the OCSP server replies « good » the
certificate can be accepted. The only thing that is known is « not
revoked ». A better rewording would be : « An OCSP client issues a
status request to an OCSP responder and obtains a revocation status
of the certificate in question. »
 
2. On page 3, third paragraph before the bottom of the page. The
term « produceAt » is used but not yet introduced. For clarity of
reading a rephrasing should be made. Hereafter is a proposal : « At
the minimum, this positive response indicates that the certificate
is not revoked, but does not necessarily mean that the certificate
was ever issued or that the current time is within the certificate’s
validity interval ».
 
3. On page 3, second paragraph before the bottom of the page. « On
hold » is reason code under « revoke ». In the explanations it would
be nice to remember here that « on hold » is under this category.
Here is a proposal: « The « revoked » state indicates that the
certificate has been definitively or temporarily revoked (i.e.
placed on hold). »
 
4. On page 4, in the fifth paragraph of the section 3.3. the
response « certRequired » is of no use any more since only a CertId
can be placed in the request. Therefore it should be deleted. [This
comment has already be made].
 
5. On page 6, the fifth item of the section 4.2. states : « The
response is in its validity period ». It is unclear to understand
what this means. It may be guessed that it is the time interval
between the « thisUpdate » and « nextUpdate ». However in section
5.2.2.1. pages 9/10, nextUpdate is optional so this test cannot be
done in general. By splitting this item into two items, a better
wording would be :
 
6.  The time at which the status being indicated is known to be 
    correct (thisUpdate) is sufficiently recent.
 
7.  When available, the time at or before which newer information 
    will be available about the status of the certificate 
    (nextUpdate)is greater than the current time.
 
8. On page 8, in the same way  « certRequired (4)  » should be
deleted. [This comment has already be made]
 
9. On page 9, CRLReason should be expanded so that the « on hold »
status can be made visible. This is pretty important since by trying
again it is possible to get later on a « good » result. 
 
10. On page 11, The section 5.4 "Extensions" should be renumbered 6
in order to have a section dealing with all the optional extensions. 

Denis

From: "Todd S. Glassey" <[email-masked]>
To: "Ietf-Pkix" <[email-masked]>
Subject: Amending the PKIX-WG Charter to reflect the addition of timestamping
Date: Tue, 22 Sep 1998 19:17:57 -0700
Importance: Normal
Sender: [email-masked]

Hi All, back in February we were working to amend the PKI WG's charter to
encompass timestamping and the certified timer resources that enable these
facilities. Now that Jeff Schiller has OK'd PKIX's having its own
timestamping/timebase facility we need to finish the charter update process.
here then is a proposed charter for your review and comments.

Thanks,

-----

Todd Glassey

Stephen Kent's report of the meeting minutes - excerpt below -

- Timestamp & Notary proposals (Carlisle Adams)

Several folks continuing work on these topics and have published an
independent draft on
these topics. The authors received a fair amount of private feedback, and
hope to be able to
bring forward a well-formed proposal. Jeff Schiller gave his permission to
bring this into
the WG, based on the WG having made substantial progress on the other work
items. Thus
we will expand the charter to encompass these topics.

----- BEGINNING OF CHARTER TEXT ----

Public-Key Infrastructure (X.509) (PKIX)
--------------------------------------------------

 Charter
 Last Modified: September 18, 1998

 Current Status: Active Working Group

Chair(s):
Stephen Kent <[email-masked]>
Warwick Ford <[email-masked]>

Security Area Director(s):
Jeffrey Schiller <[email-masked]>
Marcus Leech <[email-masked]>

Security Area Advisor:
Jeffrey Schiller <[email-masked]>

Mailing Lists:
General Discussion:[email-masked]
To Subscribe: [email-masked]
In Body: subscribe (In Body)
Archive: http://www.imc.org/ietf-pkix

Description of Working Group:
Many Internet protocols and applications which use the Internet employ
public-key technology for security purposes and require a public-key
infrastructure (PKI) to securely manage public keys for widely-distributed
users or systems.  The X.509 standard constitutes a widely-accepted basis
for such
an infrastructure, defining data formats and procedures related to
distribution
of public keys via certificates digitally signed by certification
authorities
(CAs).

For example, RFC 1422 specified the basis of an X.509-based PKI, targeted
primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).
Since RFC 1422 was issued, application requirements for an Internet PKI have
broadened tremendously, and the capabilities of X.509 have advanced with the
development of standards defining the X.509 version 3 certificate and
version 2 certificate revocation list (CRL).

Charter of the Working Group:
The charter of the working group will be to develop Internet standards
needed to support the use of an X.509-based PKI.  The goal of this Working
Group (WG)
will be to further facilitate the use of X.509 certificates in applications
that
make use of the Internet and to promote interoperability between different
implementations choosing to make use of X.509 certificates.

The resulting PKI is intended to provide a framework, which will support a
range of trust/hierarchy environments and a range of usage environments
(RFC1422
is an example of one such model).

Candidate applications to be served by this PKI include, but are not limited
to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), IPSEC protocols, Internet
payment protocols, time based authentication, timestamping, and www
protocols.

This project will not preclude use of non-infrastructure public-key
distribution techniques nor of non-X.509 PKIs by such applications.  Efforts
will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
project.

The group will focus on tailoring and profiling the features available in
the v3 X.509 certificate to best match the requirements and characteristics
of the
Internet environment.

Other topics to be addressed potentially include:

     * Alternatives for CA-to-CA certification links and structures,
including
       guidelines for constraints

     * Revocation alternatives, including profiling of X.509 v2 CRL
extensions
     * Certificate and CRL distribution options (X.500-based,
non-X.500-based)
     * Guidelines for policy definition and registration
     * Administrative protocols and procedures, including certificate
       generation, revocation notification, cross-certification, and
key-pair
       updating
     * Naming and name forms (how entities are identified, e.g., email
       address, URN, DN, misc.)
     * Generation of client key pairs by the PKI
     * Services that support non-repudiation.  This can include sources of
       credible time data and/or certificate path validation services.

----- END OF CHARTER TEXT ----

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Steve Kent'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Subject: text for attributes
Date: Tue, 22 Sep 1998 08:28:14 -0400
Sender: [email-masked]

Although we have not reached specific wording which is 100% agreed by
everyone, we have reached agreement on what the contents of the
cACertificate and crossCertificatePair attributes are to be used for. In
order to bring this to closure, Santosh and I plan to go with the advice of
our co-chairs and proceed with the word 'realm', along with the
clarification that its meaning is defined locally and hope everyone will be
willing to live with that.

Also, this will be liaised to the X.509 group as the PKIX recommendation to
resolve the associated defect report in that standard.

Thanks to everyone for their input and I assume I'm not the only one looking
forward to a reduced amount of email each morning :-)

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Tue, 22 Sep 1998 08:15:43 -0400
To: Stefan Santesson <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Al Arsenault <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

At 06:25 AM 9/22/98 +0200, Stefan Santesson wrote:
>Al,
>
>Just a short reply to CA disaster (See below).
>
>Thanks for your reply, I still disagree to the disaster part.
>
>CA2 does not have to be dismanteled, since CA 2:s key is intact.
>What has to be done is that:
>- CA1 is rebuilt with new key
>- The compromise of CA1 and its new key has to be communicated with
>out-of-band means
>- CA1 cross certify CA2 (and other CA:s) using the new key
>- New cross certificates to CA1 has to be issued and published by other CA:s.
>
>Now all certificates issued by CA2 before the disaster of CA1 can be used
>and trusted.
>This since the disaster of CA1 didn't destroy CA2, just the link to CA2
>from CA1.
>
>/Stefan

Stefan,

	The more I think about this, the more I realize we agree.  It's the words
that need figuring out. Perhaps the words in the draft roadmap are too
strong; we'll have to think about that.

	First, let me note that when CA1 and CA2 are cross-certified - that is,
have a peer relationship, with neither subordinate to the other - I agree
with you about what happens when CA1's key is compromised.

	Now, let us assume that there is a hierarchical relationship - CA2 is
subordinate to CA1. This means to me that the trust anchor used by end
entities below CA2 is  not CA2 - it's CA1.  When CA1's key is discovered to
be compromised, what you do is:

	1 - communicate out of band the compromise. This means that CA2 and all
entities below it are essentially "out of action" temporarily; since CA1 is
the trust anchor, there's no way to construct a valid cert path

	2 - reconstitute CA1 with a new key;

	3 - get CA2's key to CA1 for certification (most likely through
out-of-band means). Yes, this can still be the same key; since CA2's key
wasn't compromised, it can still be used, and it will make things easier in
that you don't have to go re-signing end-entity certs with a new CA2 key.

Now, you're back in action.  

If you agree that this is right, we can figure out words that say that.
The point I wanted to convey is that the entire PKI is dead in this case
until CA1 is brought up and a new CA2 cert is signed, because you can't
construct a valid path back to a valid trust anchor.

(Of course, if trust anchor's compromised key happens to be on all
end-entity hardware tokens in a form that can't easily be changed, you've
still got a problem, but that's beyond the scope of PKIX :-)

				Al Arsenault

- the above opinions are my own.  They may or may not reflect the opinions
of my employer or of any other organization with which I have a relationship.

From: Anders Rundgren <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: OCSP - Public Key Dstribution
Date: Tue, 22 Sep 1998 13:30:44 +0200
Sender: [email-masked]

Denis,
> something that is nontrivial.   And "Certificate Domain" is also missing.

???
Certificate Domain is some kind of indication of what kind of certificate(s)
you want to validate.  I.e. like SET-certificates, a National ID-card, OBI-trader etc.
This could be of interest in both the request and in the response.  I.e. a trusted OCSP
server may support overlapping or disjunct domains and a typical subscriber
may be interested in just one type.  To standardize this seems unnecessary
in the same sense as defining trust models in OCSP.  It is a *deployment* issue
like certificate policies and liabilities.

Other extensions, like certificate validation might be considered
once OCSP is closed.

I assume that the "closing" of OCSP will be pretty theoretical when the definition
of extensions starts.  Already an IETF agenda item it seems

Regards
Anders

Date: Tue, 22 Sep 1998 11:26:49 +0200
From: "Petra Glöckner" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: basic constraint extension
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms6C21A3596B2679A5F64C275F
Content-Type: multipart/mixed; boundary="------------C84E92343668538B0D7F006C"

This is a multi-part message in MIME format.
--------------C84E92343668538B0D7F006C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

the draft-ietf-pkix-ipki-part1-10 says the basic constraint extension 
MUST appear as a critical extension in all CA certificates but it 
SHOULD NOT appear in end entity certificates.

Why should the basic constraint extension not appear in end entity 
certificates ? Is it purely to safe some bits or is there another
reason, like keeping the draft more flexibel, e.g. to allow an
end entity to issue a certificate for his encryption key himself using
his signature key and certificate ?

In general, is it possible for an end entity to use his signature key 
and certificate to issue a certificate for his encryption key himself ?
Or do you have to have the CA bit set to true in your certificate in
order to be able to issue certificates for your own encryption keys ?

Any ideas and thoughts are welcome !

Best regards - Petra
--------------C84E92343668538B0D7F006C
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Petra Glöckner
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Petra Glöckner
n:              ;Petra Glöckner
org:            GMD-TKT
email;internet: [email-masked]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------C84E92343668538B0D7F006C--

--------------ms6C21A3596B2679A5F64C275F
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms6C21A3596B2679A5F64C275F--

Date: Tue, 22 Sep 1998 06:25:35 +0200
To: Al Arsenault <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Al,

Just a short reply to CA disaster (See below).

Thanks for your reply, I still disagree to the disaster part.

CA2 does not have to be dismanteled, since CA 2:s key is intact.
What has to be done is that:
- CA1 is rebuilt with new key
- The compromise of CA1 and its new key has to be communicated with
out-of-band means
- CA1 cross certify CA2 (and other CA:s) using the new key
- New cross certificates to CA1 has to be issued and published by other CA:s.

Now all certificates issued by CA2 before the disaster of CA1 can be used
and trusted.
This since the disaster of CA1 didn't destroy CA2, just the link to CA2
from CA1.

/Stefan

At 01:32 PM 9/21/98 -0400, Al Arsenault wrote:
>Stefan,
>
>	Thanks for your comments.  Responses in line (Sean can make changes to the
>draft as appropriate).
>
>
>At 04:19 PM 9/21/98 +0200, Stefan Santesson wrote:
>>Al,
>>
>>I finally got time to look a little bit deeper into the roadmap document.
>>I think it is very well formed but I have some minor disagreements.
>>
>>1) Concerning definition and use of the term Root CA
>>2) Result from CA compromise
>>3) Use of certificates.
>>
>>1 - Root CA
>>---------
>>Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives
>>the impression that Root CA is at the top of some hierarchy. 
>>
>>This does not seem to harmonize with the definition of root CA in
>>"Certificate Management Protocols"
>>
>>  "We use the term "root CA" to indicate a CA that is directly trusted by 
>>   an end entity; that is, securely acquiring the value of a root CA public 
>>   key requires some out-of-band step(s). This term is not meant to imply 
>>   that a root CA is necessarily at the top of any hierarchy, simply that 
>>   the CA in question is trusted directly."
>>
>>So in fact every CA in a domain is likely to be "root" for some of its
>>subscribers.
>>I personally prefer the rem "Top CA" when describing a hierarchy.
>>
>
>You are correct; I was using the term "rootCA" to indicate the top of a
>hierarchy (possibly, a hierarchy of depth one - two counting the end
>entity).  That is inconsistent with CMP.  We'll have to resolve that.  I
>personally prefer using the term "rootCA" to mean the top of a hierarchy,
>and "trust anchor" to mean the CA that the end-entity directly trusts.  But
>we'll figure out something - "topCA" is probably feasible for now.
>
>
>>
>>2 - CA compromise
>>------------------
>>In section 3.4.5 it is said that compromise of a root CA is always
>>catastrophic and that the entire infrastructure subordinate to that root CA
>>has to be dismantled and started over again. This gives the impression that
>>a subordinate CA has to be dismatled.
>>
>>My comment is that 
>>a) Since the rootCA does not denote any hierarchy we can't define which CA
>>that is subordinate or not to a specific root CA
>>b) A compromised CA does only require that particular CA to be dismantled.
>>No other non-compromised CA has to be dismantled. Other CA:s has to revoke
>>cross certificates to th compromised CA and all subscribers using the
>>compromised CA as root CA, are totally cut off until they get another
>>rootCA key, but that's another aspect.
>>
>
>Your comment (a) is correct, given the different meaning of "rootCA" that I
>didn't catch earlier.  However, I disagree with part of your comment (b).
>That to me goes to the heart of a "CA Certificate" vs. a
>"Cross-certificate".  
>
>Suppose that CA2 has no self-signed certificates (it might have a
>self-issued certificate for key management, but that's not relevant at this
>point). CA2's CA certificate is issued and signed by CA1.  Thus, CA2 is
>subordinate to CA1.  Now, if CA1's private key is compromised, then CA2
>must be "dismantled".  That is, there is no reliable way for an outside
>entity to know whether CA2's cert was legitimately issued prior to the
>compromise of CA1's key, or whether CA2's cert was signed by the malicious
>party now holding the copy of CA1's private key.  The only thing you can do
>is kill CA2 and start over with a new cert issued by the new, re-installed
>CA1.  (Not to mention the mechanical problem of constructing a valid cert
>path going through CA2 to the valid CA1:-). Of course, "dismantling" is a
>strong word; you'd have to rebuild CA1 with a new key, and sign a new
>certificate for CA2 using the new, un-compromised key.  You wouldn't
>necessarily need to erase CA2's database, train new people, buy a new
>hardware platform, etc. :-)
>
>With a cross-certificate, as you point out, there's no need to do anything
>over than revoke the cross-cert CA2 has issued for CA1 (if there is one).
>
>
>>3 - Certificate usage
>>---------------------
>>Section 3.1 states that:
>>"Certificates is used in the process of validating signed data."
>>This definition is leaving out any use for the purpose of encryption. I.e.
>>data encryption, key agreement and key exchange.
>>
>
>Agreed.
>
>
>				Al Arsenault
>
>- the above opinions are my own.  They may or may not reflect the opinions
>of my employer or of any other organization with which I have a relationship.
>
>
>
>
>

Date: Mon, 21 Sep 1998 13:32:57 -0400
To: Stefan Santesson <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Al Arsenault <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Stefan,

	Thanks for your comments.  Responses in line (Sean can make changes to the
draft as appropriate).

At 04:19 PM 9/21/98 +0200, Stefan Santesson wrote:
>Al,
>
>I finally got time to look a little bit deeper into the roadmap document.
>I think it is very well formed but I have some minor disagreements.
>
>1) Concerning definition and use of the term Root CA
>2) Result from CA compromise
>3) Use of certificates.
>
>1 - Root CA
>---------
>Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives
>the impression that Root CA is at the top of some hierarchy. 
>
>This does not seem to harmonize with the definition of root CA in
>"Certificate Management Protocols"
>
>  "We use the term "root CA" to indicate a CA that is directly trusted by 
>   an end entity; that is, securely acquiring the value of a root CA public 
>   key requires some out-of-band step(s). This term is not meant to imply 
>   that a root CA is necessarily at the top of any hierarchy, simply that 
>   the CA in question is trusted directly."
>
>So in fact every CA in a domain is likely to be "root" for some of its
>subscribers.
>I personally prefer the rem "Top CA" when describing a hierarchy.
>

You are correct; I was using the term "rootCA" to indicate the top of a
hierarchy (possibly, a hierarchy of depth one - two counting the end
entity).  That is inconsistent with CMP.  We'll have to resolve that.  I
personally prefer using the term "rootCA" to mean the top of a hierarchy,
and "trust anchor" to mean the CA that the end-entity directly trusts.  But
we'll figure out something - "topCA" is probably feasible for now.

>
>2 - CA compromise
>------------------
>In section 3.4.5 it is said that compromise of a root CA is always
>catastrophic and that the entire infrastructure subordinate to that root CA
>has to be dismantled and started over again. This gives the impression that
>a subordinate CA has to be dismatled.
>
>My comment is that 
>a) Since the rootCA does not denote any hierarchy we can't define which CA
>that is subordinate or not to a specific root CA
>b) A compromised CA does only require that particular CA to be dismantled.
>No other non-compromised CA has to be dismantled. Other CA:s has to revoke
>cross certificates to th compromised CA and all subscribers using the
>compromised CA as root CA, are totally cut off until they get another
>rootCA key, but that's another aspect.
>

Your comment (a) is correct, given the different meaning of "rootCA" that I
didn't catch earlier.  However, I disagree with part of your comment (b).
That to me goes to the heart of a "CA Certificate" vs. a
"Cross-certificate".  

Suppose that CA2 has no self-signed certificates (it might have a
self-issued certificate for key management, but that's not relevant at this
point). CA2's CA certificate is issued and signed by CA1.  Thus, CA2 is
subordinate to CA1.  Now, if CA1's private key is compromised, then CA2
must be "dismantled".  That is, there is no reliable way for an outside
entity to know whether CA2's cert was legitimately issued prior to the
compromise of CA1's key, or whether CA2's cert was signed by the malicious
party now holding the copy of CA1's private key.  The only thing you can do
is kill CA2 and start over with a new cert issued by the new, re-installed
CA1.  (Not to mention the mechanical problem of constructing a valid cert
path going through CA2 to the valid CA1:-). Of course, "dismantling" is a
strong word; you'd have to rebuild CA1 with a new key, and sign a new
certificate for CA2 using the new, un-compromised key.  You wouldn't
necessarily need to erase CA2's database, train new people, buy a new
hardware platform, etc. :-)

With a cross-certificate, as you point out, there's no need to do anything
over than revoke the cross-cert CA2 has issued for CA1 (if there is one).

>3 - Certificate usage
>---------------------
>Section 3.1 states that:
>"Certificates is used in the process of validating signed data."
>This definition is leaving out any use for the purpose of encryption. I.e.
>data encryption, key agreement and key exchange.
>

Agreed.

				Al Arsenault

- the above opinions are my own.  They may or may not reflect the opinions
of my employer or of any other organization with which I have a relationship.

Date: Mon, 21 Sep 1998 12:20:00 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: meeting minutes
Sender: [email-masked]

--============_-1305727475==_ma============
Content-Type: text/plain; charset="us-ascii"

Folks,

I apologize for not having mailed these sooner, for review.  They were done
by Friday, of IETF week, but then got lost in an avalanche of travel and
e-mail.  Please review and respond to me with corrections by the end of
this week.

Thanks,

Steve

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

	PKIX WG Meeting Minutes 8/26-27/98

The PKIX WG met twice during the 42nd IETF and a approximately 190
individuals participated in these meetings.

The meeting began with a review of the status of all of the WG document,
presented by
Warwick Ford, WG co-chair. The following text summarizes the status of the
documents:

PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG
Last Call

KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to
completion by Editors

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for WG
last call

LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2 Schema

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last call

OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF
(draft-ietf-pkix-crmf-01.txt) - In hands
of IESG; pending IESG last call

CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt) -
In WG last
call

Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt)
- In SA Director's
hands, pending publication as Informational RFC

REVIEWS OF ESTABLISHED PROJECTS:

- PKIX Certificate and CRL Profile (Tim Polk)

Ready for IESG ballot, after receipt of minor editorial comments during
IETF last call.
Straw polls used to resolve last few contentious issues, specifically
mandating use of DNs
for all Issuers, and mandating use of strict subtrees for the
NameConstraints extension.
Jeff Schiller noted that the IETF web site has pointers to the Entrust
license required for
inclusion of CRL distribution point within this document.  The license is
easy to execute;
there is a reciprocity clause that requires licensing to Entrust  any
intellectual property
associated with CRL distribution, as a side effect of

- KEA and ECDS Algorithms (Tim Polk)

Work on these algorithm IDs continues, subject to resolution of some
intellectual property
issues.

- LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh Chokhani)

Most of the schema are not controversial; outstanding issues is whether all
CA certificates
should appear in the cross certificate directory attribute, or whether
certificates that are
internal to a domain should appear in the CA certificate attribute.  There
is consensus that
any self-signed CA certificates belong in the latter attribute.  The
disagreement here
revolves around alternative certificate validation algorithms; both
approaches have been
implemented and both work, each favoring a different PKI model. The CA
certificate
attribute has been a feature of X.509 for a long while, so the proposal to
move all (non-
self-signed) CA certificates to the cross CA certificate attribute
represents a non-backward
compatible change for systems not making use of cross certificates.  Still,
this is the
direction currently being pursued by the X.509 committee in resolving this
ambiguity in the
original standard.

Performance analysis of 6 different approaches, under varying assumptions
of PKI
models, shows that putting all (non-self signed) CA certificates in the
cross certificate
attribute results in worse performance.

We can make a decision now to get this long overdue schema out, or postpone
and discuss
more (since this is a newly discovered issue).  (Although this discussion
is taking place in
the context of LDAP v2, the same issue arises in LDAP v3.  However, v3 has
better
filtering capabilities and this it is believed that the issue would be less
of a concern, but this
is not universally agreed upon.) Work on LDAP v3 is progressing in the
IETF, and so if
we postpone action on this ID, it may be OBE and we will need to focus on
v3 instead.

Proposed compromise approach is to duplicate intra-domain CA certificates
in both
attributes (#4 in Santosh's analysis posted to the WG list), and which has
very good
overall performance. One objection raised to this is that it can result in
added data sent back
if one retrieves both attribute contents. Straw poll conducted resulted on
no clear winner,
but the two finalists are the proposed compromise and the older, backward
compatible
approach; the WG rejected the proposal from the current LDAP schema.

- OCSP (Tim Myers and Ambrish Malpani)

Various minor, but technically important, edits to many parts of the
document, in response
to comments from the WG list. Changes included a uniform key identifier,
optional use of
TLS/SSL for privacy protection of exchanges, etc. An objection was raised
to mandating
use of a signature, when a lower layer protocol might be used to provide
security.  A straw
poll overwhelmingly supported the mandatory use of signatures of in OCSP.
Thus there
appears to be no outstanding significant technical issues at this time. A
separate OCSP response extensions document will be created to define
additional responses

- CMP and CRMF

In IESG last call. No further status to report.

- CMMF and CMC (Mike Myers)

The CMMF draft has completed WG last call, minor changes have been made in
response to comments received during last call, it and will be forwarded to
the IESG. CMC also has completed WG last call, and undergone changes in
response to comments received during that process.  Pending approval of
secure initialization issues briefed at this meeting, the document will be
forwarded to the IESG. The secure initialization requirements for CMC
include use of a shared secret in a keyed hash calculation, with this
secret distributed via a confidentiality-secure channel.  However,
objections were raised to defining this as the only way to achieve secure
initialization, e.g., as opposed to use of SecurID cards or S-KEY
authentication in the context of an integrity and confidentiality secure
channel. It seems likely that additional mechanisms should be allowed, but
there is a desire to avoid an explosion of allowed user authentication
techniques, which would hinder interoperability or greatly burden CA
software.  This issue will be brought to the list for resolution.

- IBM PKIX Software Distribution (Charlie Kaufman)

IBM is implementing PKIX technology and making it available  for use in
products, as
well as in R&D environments.  Code is a mix of C++ software plus Java GUIs.
Provided
facilities include CMP, CRMF, LDAP, basic CA and RA functions, and client
certificate
processing.  No crypto is included in the distribution; the software makes
calls to a CAPI.
The first release relies on the Cylink cyrpto toolkit, which also will be
available via this
web site; later version will also make use of BSAFE. Initial distribution
is via an MIT web
site and is not exportable.  A pointer for a mailing list was provided:
[email-masked].

NEW TOPICS:

- Timestamp & Notary proposals (Carlisle Adams)

Several folks continuing work on these topics and have published an
independent draft on
these topics.  The authors received a fair amount of private feedback, and
hope to be able to
bring forward a well-formed proposal. Jeff Schiller gave his permission to
bring this into
the WG, based on the WG having made substantial progress on the other work
items. Thus
we will expand the charter to encompass these topics.

- Web-based Integrated CA services Protocol (Mine Sakurai)

This presentation describes use of HTTP as an underlying communication
protocol among CAs, RAs, etc.  The underlying model also defines issuing,
validation, and publishing authority modules within the CA.  ICAP has been
implemented for use with S/MIME in a medical information system in Japan.
An I-D has been published describing ICAP: draft-ietf-????.  It was noted
that the acronym "ICAP" is already in use by a calendar protocol, so
another protocol acronym would be appropriate.

- Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick Ford)

There is an I-D describing alternatives CRL distribution technique, which
was developed in response to the intellectual property problem that
temporarily prevented use of the CRL distribution point mechanism. The CRL
format can be extended to specify the scope of the CRL, e.g., by serial
number range, as an alternative to placing the pointer in the certificate.
To address the CRL location aspect of CRL distribution points, one also can
establish CRL managers that are either locally trusted or that represent a
separate CRL distribution channel, perhaps serving multiple CAs. By adding
two new CRL extensions, one can extend the CRL distribution model in
interesting new ways.  These suggestions are being forwarded to ISO for
consideration. See the latest I-D, under the PKIX, for more details.

- PKIX Roadmap (Al Arsenault)

The set of PKIX documents has become rather large and potentially
confusing.  An outline
was presented as a basis for a document that would become an informational
RFC, to help
explain the relationships among these documents, and to other efforts,
e.g., SPKI.  An
initial draft is ready and will be made available immediately after this
IETF meeting.

- Qualified Certificates (Stefan Santesson)

In EC a legal framework for "qualified certificates" is being developed,
referring to individual certificates that will be accepted for legally
binding, international transactions, and with legal liability implications
for the CAs issuing such certificates.  (These certificates are used only
for non-repudiation.) It is analogous to some of the work under UNICTRAL
for EDI. For PKIX, the potential work item would be a profile for such
certificates, specifying which extensions are mandatory and optional,
establishing values and semantics for some of the extensions. For example,
one might mandate use of the policy extension with a specific value to
identify such certificates, with policy qualifiers to express additional
characteristics of policy variants, appropriate key usage flags, naming
schema constraints, etc.
--============_-1305727475==_ma============
Content-Type: text/enriched; charset="us-ascii"

Folks,

I apologize for not having mailed these sooner, for review.  They were
done by Friday, of IETF week, but then got lost in an avalanche of
travel and e-mail.  Please review and respond to me with corrections by
the end of this week.

Thanks,

Steve

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

	<fontfamily><param>Times</param><bigger><bigger>PKIX WG Meeting
Minutes 8/26-27/98

The PKIX WG met twice during the 42nd IETF and a approximately 190

individuals participated in these meetings.

The meeting began with a review of the status of all of the WG
document, presented by 

Warwick Ford, WG co-chair. The following text summarizes the status of
the documents:

PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG
Last Call

KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to
completion by Editors

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for
WG last call

LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2
Schema

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last
call

OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF
(draft-ietf-pkix-crmf-01.txt) - In hands 

of IESG; pending IESG last call

CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt)
- In WG last 

call

Certificate Policy/Practices Guideline
(draft-ietf-pkix-ipki-part4-03.txt) - In SA Director's 

hands, pending publication as Informational RFC

REVIEWS OF ESTABLISHED PROJECTS:

- PKIX Certificate and CRL Profile (Tim Polk)

Ready for IESG ballot, after receipt of minor editorial comments during
IETF last call.  

Straw polls used to resolve last few contentious issues, specifically
mandating use of DNs 

for all Issuers, and mandating use of strict subtrees for the
NameConstraints extension. 

Jeff Schiller noted that the IETF web site has pointers to the Entrust
license required for 

inclusion of CRL distribution point within this document.  The license
is easy to execute; 

there is a reciprocity clause that requires licensing to Entrust  any
intellectual property 

associated with CRL distribution, as a side effect of 

- KEA and ECDS Algorithms (Tim Polk)

Work on these algorithm IDs continues, subject to resolution of some
intellectual property 

issues.

- LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh
Chokhani)

Most of the schema are not controversial; outstanding issues is whether
all CA certificates 

should appear in the cross certificate directory attribute, or whether
certificates that are 

internal to a domain should appear in the CA certificate attribute. 
There is consensus that 

any self-signed CA certificates belong in the latter attribute.  The
disagreement here 

revolves around alternative certificate validation algorithms; both
approaches have been 

implemented and both work, each favoring a different PKI model. The CA
certificate 

attribute has been a feature of X.509 for a long while, so the proposal
to move all (non-

self-signed) CA certificates to the cross CA certificate attribute
represents a non-backward 

compatible change for systems not making use of cross certificates. 
Still, this is the 

direction currently being pursued by the X.509 committee in resolving
this ambiguity in the 

original standard.

Performance analysis of 6 different approaches, under varying
assumptions of PKI 

models, shows that putting all (non-self signed) CA certificates in the
cross certificate 

attribute results in worse performance.

We can make a decision now to get this long overdue schema out, or
postpone and discuss 

more (since this is a newly discovered issue).  (Although this
discussion is taking place in 

the context of LDAP v2, the same issue arises in LDAP v3.  However, v3
has better 

filtering capabilities and this it is believed that the issue would be
less of a concern, but this 

is not universally agreed upon.) Work on LDAP v3 is progressing in the
IETF, and so if 

we postpone action on this ID, it may be OBE and we will need to focus
on v3 instead.

Proposed compromise approach is to duplicate intra-domain CA
certificates in both 

attributes (#4 in Santosh's analysis posted to the WG list), and which
has very good 

overall performance. One objection raised to this is that it can result
in added data sent back 

if one retrieves both attribute contents. Straw poll conducted resulted
on no clear winner, 

but the two finalists are the proposed compromise and the older,
backward compatible 

approach; the WG rejected the proposal from the current LDAP schema.

- OCSP (Tim Myers and Ambrish Malpani)

Various minor, but technically important, edits to many parts of the
document, in response 

to comments from the WG list. Changes included a uniform key
identifier, optional use of 

TLS/SSL for privacy protection of exchanges, etc. An objection was
raised to mandating 

use of a signature, when a lower layer protocol might be used to
provide security.  A straw 

poll overwhelmingly supported the mandatory use of signatures of in
OCSP.  Thus there 

appears to be no outstanding significant technical issues at this time.
A separate OCSP response extensions document will be created to define
additional responses 

- CMP and CRMF

In IESG last call. No further status to report.

- CMMF and CMC (Mike Myers)

The CMMF draft has completed WG last call, minor changes have been made
in response to comments received during last call, it and will be
forwarded to the IESG. CMC also has completed WG last call, and
undergone changes in  response to comments received during that
process.  Pending approval of secure initialization issues briefed at
this meeting, the document will be forwarded to the IESG. The secure
initialization requirements for CMC include use of a shared secret in a
keyed hash calculation, with this secret distributed via a
confidentiality-secure channel.  However, objections were raised to
defining this as the only way to achieve secure initialization, e.g.,
as opposed to use of SecurID cards or S-KEY authentication in the
context of an integrity and confidentiality secure channel. It seems
likely that additional mechanisms should be allowed, but there is a
desire to avoid an explosion of allowed user authentication techniques,
which would hinder interoperability or greatly burden CA software. 
This issue will be brought to the list for resolution.

- IBM PKIX Software Distribution (Charlie Kaufman)

IBM is implementing PKIX technology and making it available  for use in
products, as 

well as in R&D environments.  Code is a mix of C++ software plus Java
GUIs. Provided 

facilities include CMP, CRMF, LDAP, basic CA and RA functions, and
client certificate 

processing.  No crypto is included in the distribution; the software
makes calls to a CAPI. 

The first release relies on the Cylink cyrpto toolkit, which also will
be available via this 

web site; later version will also make use of BSAFE. Initial
distribution is via an MIT web 

site and is not exportable.  A pointer for a mailing list was provided:
[email-masked].

NEW TOPICS:

- Timestamp & Notary proposals (Carlisle Adams)

Several folks continuing work on these topics and have published an
independent draft on 

these topics.  The authors received a fair amount of private feedback,
and hope to be able to 

bring forward a well-formed proposal. Jeff Schiller gave his permission
to bring this into 

the WG, based on the WG having made substantial progress on the other
work items. Thus 

we will expand the charter to encompass these topics.

- Web-based Integrated CA services Protocol (Mine Sakurai)

This presentation describes use of HTTP as an underlying communication
protocol among CAs, RAs, etc.  The underlying model also defines
issuing, validation, and publishing authority modules within the CA. 
ICAP has been implemented for use with S/MIME in a medical information
system in Japan.  An I-D has been published describing ICAP:
draft-ietf-????.  It was noted that the acronym "ICAP" is already in
use by a calendar protocol, so another protocol acronym would be
appropriate.

- Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick
Ford)

There is an I-D describing alternatives CRL distribution technique,
which was developed in response to the intellectual property problem
that temporarily prevented use of the CRL distribution point mechanism.
The CRL format can be extended to specify the scope of the CRL, e.g.,
by serial number range, as an alternative to placing the pointer in the
certificate.  To address the CRL location aspect of CRL distribution
points, one also can establish CRL managers that are either locally
trusted or that represent a separate CRL distribution channel, perhaps
serving multiple CAs. By adding two new CRL extensions, one can extend
the CRL distribution model in interesting new ways.  These suggestions
are being forwarded to ISO for consideration. See the latest I-D, under
the PKIX, for more details.

- PKIX Roadmap (Al Arsenault)

The set of PKIX documents has become rather large and potentially
confusing.  An outline 

was presented as a basis for a document that would become an
informational RFC, to help 

explain the relationships among these documents, and to other efforts,
e.g., SPKI.  An 

initial draft is ready and will be made available immediately after
this IETF meeting.

- Qualified Certificates (Stefan Santesson)

In EC a legal framework for "qualified certificates" is being
developed, referring to individual certificates that will be accepted
for legally binding, international transactions, and with legal
liability implications for the CAs issuing such certificates.  (These
certificates are used only for non-repudiation.) It is analogous to
some of the work under UNICTRAL for EDI. For PKIX, the potential work
item would be a profile for such certificates, specifying which
extensions are mandatory and optional, establishing values and
semantics for some of the extensions. For example, one might mandate
use of the policy extension with a specific value to identify such
certificates, with policy qualifiers to express additional
characteristics of policy variants, appropriate key usage flags, naming
schema constraints, etc. </bigger></bigger></fontfamily>

--============_-1305727475==_ma============--

Date: Mon, 21 Sep 1998 16:19:49 +0200
To: Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Al,

I finally got time to look a little bit deeper into the roadmap document.
I think it is very well formed but I have some minor disagreements.

1) Concerning definition and use of the term Root CA
2) Result from CA compromise
3) Use of certificates.

1 - Root CA
---------
Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives
the impression that Root CA is at the top of some hierarchy. 

This does not seem to harmonize with the definition of root CA in
"Certificate Management Protocols"

  "We use the term "root CA" to indicate a CA that is directly trusted by 
   an end entity; that is, securely acquiring the value of a root CA public 
   key requires some out-of-band step(s). This term is not meant to imply 
   that a root CA is necessarily at the top of any hierarchy, simply that 
   the CA in question is trusted directly."

So in fact every CA in a domain is likely to be "root" for some of its
subscribers.
I personally prefer the rem "Top CA" when describing a hierarchy.

2 - CA compromise
------------------
In section 3.4.5 it is said that compromise of a root CA is always
catastrophic and that the entire infrastructure subordinate to that root CA
has to be dismantled and started over again. This gives the impression that
a subordinate CA has to be dismatled.

My comment is that 
a) Since the rootCA does not denote any hierarchy we can't define which CA
that is subordinate or not to a specific root CA
b) A compromised CA does only require that particular CA to be dismantled.
No other non-compromised CA has to be dismantled. Other CA:s has to revoke
cross certificates to th compromised CA and all subscribers using the
compromised CA as root CA, are totally cut off until they get another
rootCA key, but that's another aspect.

3 - Certificate usage
---------------------
Section 3.1 states that:
"Certificates is used in the process of validating signed data."
This definition is leaving out any use for the purpose of encryption. I.e.
data encryption, key agreement and key exchange.

Regards
/Stefan

Date: Mon, 21 Sep 1998 09:18:44 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Anders Rundgren <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: OCSP - Public Key Dstribution
Sender: [email-masked]

Anders Rundgren a écrit:
 
> Salut Denis,

This sounds a little bit familiar to me. :-(
Please do not mix French and English.

> Pardon my ignorance but does a returned issuerKeyHash give you the
> possibility to verify a certificate signature *after* its status has been checked?

Yes.

> Don't you need the original (unhashed) issuer public key to to that?

You can get it after the OCSP request.

 > I.e. does this enhanced OCSP draft essentially support my
suggested OCSP++
> (previously I called it OCVP) system *without* requiring extensions?  That would be
> just fantastic!

I took a look at the URL address you are providing. Since the
description is pretty short, it is hard to answer your question.
However the text says "an easy-to-use system for checking status
and validity of a certificate." In this version of OCSP, there is
no intent for checking the validity of the certificate but only its
revocation/on-hold status. Checking the status would be far more
complicated and controversial.  

Denis

> http://www.jaybis.com/specifications/pkix/ocsp.html
> 
> Please enlighten me!
> 
> Regards
> Anders Rundgren
> 
> ----------
> From:  Denis Pinkas [SMTP:[email-masked]]
> Sent:  Saturday, September 19, 1998 02:15
> To:  Andreas Berger
> Cc:  Peter Sylvester; [email-masked]; [email-masked]
> Subject:  Re: fast review of draft-ietf-pkix-ocsp-06.txt
> 
> Andreas,
> 
> I share your concerns.
> 
> The current definition of CertId is as follows:
> 
>    CertID          ::=     SEQUENCE {
>        hashAlgorithm       AlgorithmIdentifier,
>        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
>        issuerKeyHash       OCTET STRING, -- Hash of Issuers public
> key
>        serialNumber        CertificateSerialNumber }
> 
> CertID is used both in the request and in the response.
> I would suggest to change it to:
> 
>    CertID          ::=     SEQUENCE {
>        hashAlgorithm       AlgorithmIdentifier,
>        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
>        issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of
> Issuers public key
>        serialNumber        CertificateSerialNumber }
> 
> making the issuerKeyHash optional.
> 
> The issuerKeyHash would be optional for a request but mandatory for
> a response. The rational is as follows: the requester needs "at
> some time" to get the public key of the issuer in order to verify
> the certificate. If we mandate that field to be always present
> thent it must get it *before* the request to the OCSP server. If we
> make it optional, then it may get it before or after the request to
> the OCSP server. This gives some flexibility, without too many
> options.
> 
> The OCSP server should anyway have the Issuers public key and thus
> its hash. The hash may allow the requester to disambigous some
> responses in case of anonymity.
> 
> Denis
> 
> > I agree with this discussion and would like to add some thoughts:
> >
> > Peter Sylvester wrote:
> > > > I actually think OCVP is a bigger thing than just making the hash
> > > > of the issuer's PUBLIC key NULL. That whole topic should be
> > > > addressed at one shot
> > > >
> > > I am *not* really talking about OCVP, I am talking about 'CertID',
> > > a short way to identify a certificate. The syntax
> > > for the identification should be flexible enough
> > >
> > > - not to require more than the original certificate in
> > >   order to construct the identification.
> > The is a very good assumption. While the authority key *may* be
> > available, it certainly isn´t always available.
> >
> > > - to allow identification of a certificate in a given context
> > >   ==> serial number for example or/and hash of cert
> > The serial number is a little bit weaker but supported by other parts of
> > X.509, PKIX and several mail protocols, using issuer/serial for
> > identification of a certificate. So issuer/serial or
> > issuer/certificate-hash look like valid combinations. It may be a good
> > idea to be able add a subject public key hash if necessary.
> >
> > > - to allow the OCSP provider to find the source of
> > >   information provider.
> > >   ==> name of issuer may be necessary, hash of issuer name
> > >       may not be sufficient.
> > So for identification of issuer we probably have a choice of issuer-name
> > or issuer-hash, probably in combination with issuer-public-key or
> > issuer-public-key-hash as an optional parameter.
> >
> > > - to ensure that the creator of the certificate really has
> > >   a copy of a cert.
> > >   ==> hash of cert for example, or serialnumber if authority
> > >       allocates them in a sparse way.
> > > If we assume that the orginal version of OCSP where it was
> > > possible to just have a cert did make sense, thus I do not
> > > see why there is a need for the issuer public key extract
> > > in the certID. At least it should be optional in some way.
> > >
> > > It seems useful to me to fix a syntax for CertID that
> > > is sufficiently open for extensions without requiring
> > > a new protocol version..
> >
> > The removal of the certificate proper as a means to "identify" a
> > certificate forced us to specify an extension to OCSP to do this
> > (transport the certificate in the request - optional, or in the reply -
> > optional). If the consensus is that OCSP should not be able to transport
> > the certificate proper, I think we should at least open the possibility
> > to transport a certitficate hash.
> >
> > That leads me back to the idea of making a lot of the identification
> > parameters in "CertID" optional. But we will get serious
> > interoperability issues. So either we build specific CertIDs with
> > specific purposes in mind or we need some profiling (and probably a
> > means for the responder to transport valid combinations back to the
> > client).
> >
> > Andreas
> > --
> > Fifty-three percent of Fortune 1000 executives think the
> > Arch Deluxe is something that helps to run a computer.
> > -- Jericho Communications
> 
> --
>  Denis Pinkas     Bull S.A.          mailto:[email-masked]
>  Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>  78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 21 Sep 1998 09:29:41 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

Michael,

I first suggest that you re-read my last proposal from Friday which
does not contradicts your rational but contradicts your conclusion.

> All,
> 
> The intent was to provide an alternative to CRLs.  Following that model,
> there's an underlying assumption that the end-entity is in possession of
> the CA's certificate (as would be needed to validate the signature on a CRL.)

Yes, the underlying assumption that the end-entity has to get the
CA's public key or certificate. But, we should not make any
assumption whether that information must be obtained BEFORE or
AFTER the OCSP request.
 
> OCSP never had a requirement to validate an end-entity certificate in the
> absence of the CA certificate at the requestor end.  It's not just a
> requirement on syntax at the request.  This would also imply path
> validation logic on the server.  The consensus has been conclusively
> established that full certificate validation is beyond the scope of this
> protocol.

I strongly agree with your last sentence.

> There's consequently no need to alter the request syntax.

I respectfully disagree with your conclusion.

Denis
 
> Mike

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

To: [email-masked]
Subject: Re: Testing the ASN.1 in Part 1
Date: Mon, 21 Sep 1998 10:08:16 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

Just another minor point: id-ad, id-ad-ocsp and id-ad-caIssuers are defined in
both PKIX1Implicit88 and PKIX1Explicit88.

-- 
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

From: Peter Sylvester <[email-masked]>
Date: Sun, 20 Sep 1998 19:41:58 +0200
To: [email-masked]
Subject: Re: OCSP - Public Key Dstribution
Cc: [email-masked]
Sender: [email-masked]

Anders,

the proposal of Denis solves a different problem. It makes the
syntax easier for the client, it doesn't require a field that
may be unnecessary. 

An interpretation of OCSP or OCVP is independant of the
syntax change. 

It is the interpretation of the RESULT that counts: 

- In OCSP you interprete 'good' as 'I have not information that it
  is NOT GOOD'.

- in OCSP you would interprete 'unknown' as 'I know that this CA
  has never issued the CA, or I do not know the CA'. 

Denis' proposal makes the proposal more lightweight.

You can even consider that an OCSP or OCVP does not need more 
than just a serial number (because it operated in a very
restricted environment of just one CA), but well, the protocol
should be able to cover a large range of applications.

From: Peter Sylvester <[email-masked]>
Date: Sun, 20 Sep 1998 19:41:28 +0200
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

> All,
You :-) ,

> 
> The intent was to provide an alternative to CRLs.  Following that model,
> there's an underlying assumption that the end-entity is in possession of
> the CA's certificate (as would be needed to validate the signature on a CRL.)
This is a description that is somewhat strange.

What is an alternative to CRLs? Read part1 of pkix. An alternative is 
something that replace completely the usage of CRLs. CRLs by definition
are one means to detect revoked certs, YOUR intention was to have just
access to a remotely manged CRL. 

There has been a lot of discussion that OCSP is a service that allows
what it says in its definition, online status verification, and not just
lookup of a remote CRL base. A lot of effort has been made to ensure that
a minimal OCSP service can actually implemented using CRLs, otherwise
one may have just used a certHash in the request, and not used the
serial number.

Anyway, an alternative has not a defined model, so what do we have to follow?
And why is there any underlying model. This is NOT documented in OCSP, and
the contrary seems to be indicated in pkix part 1. 

Splitting a local logic that looks into a list a CRLs into a client server
protocol MAY require additional security (as it is mentioned in pkix part1).

You MAY require that a request an a response to be signed by requestor
and the responder sign the response. A server MAY require that the client
proves in some way that it is actually in possession of a cert, or
whatever else you can image. 

Or: CRLs are ONE way to obtain status information of certs OCSP is not
a client server implemention of CRL lookup but a general mecanism to
obtain status information about certificates, and it CAN be implemented
using just CRLs on the server side but it is open to provide MORE service.

> 
> OCSP never had a requirement to validate an end-entity certificate in the
> absence of the CA certificate at the requestor end.  It's not just a
> requirement on syntax at the request.  This would also imply path
> validation logic on the server.  The consensus has been conclusively
> established that full certificate validation is beyond the scope of this
> protocol.
> 
The first version of the protocol allowed just to present a certificate
in a request. Whether the client actually has the corresponding cert
before or after the validation is left to the client.

Denis proposal does not put any requirement for path validation on the 
server, on the contrary,

The server otherwise tell: I know about ONE CA and it's public key hash
is what I return in the response. It the request needs to contain a key
hash, the server MUST validate the public key in order to return 'unknown'
if it doesn't match. Thus, in some sense the actual text requires
validation on the server, and Denis' proposal removes that requirement. 

The only TECHNICAL problem that can happen is that the server KNOWS about
more than ONE certificate having the SAME serial number and the same CA name.
In this case the server should return the status of all of them, 
and let the client decide. 

> There's consequently no need to alter the request syntax.

You can always deduce everything from an empty or false premises.

Peter 

From: Anders Rundgren <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: OCSP - Public Key Dstribution
Date: Sun, 20 Sep 1998 10:53:46 +0200
Sender: [email-masked]

Salut Denis,
Pardon my ignorance but does a returned issuerKeyHash give you the
possibility to verify a certificate signature *after* its status has been checked?
Don't you need the original (unhashed) issuer public key to to that?

I.e. does this enhanced OCSP draft essentially support my suggested OCSP++
(previously I called it OCVP) system *without* requiring extensions?  That would be
just fantastic!

http://www.jaybis.com/specifications/pkix/ocsp.html

Please enlighten me!

Regards
Anders Rundgren

----------
From:  Denis Pinkas [SMTP:[email-masked]]
Sent:  Saturday, September 19, 1998 02:15
To:  Andreas Berger
Cc:  Peter Sylvester; [email-masked]; [email-masked]
Subject:  Re: fast review of draft-ietf-pkix-ocsp-06.txt

Andreas,

I share your concerns.

The current definition of CertId is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public
key
       serialNumber        CertificateSerialNumber }

CertID is used both in the request and in the response.
I would suggest to change it to:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of
Issuers public key
       serialNumber        CertificateSerialNumber }

making the issuerKeyHash optional.

The issuerKeyHash would be optional for a request but mandatory for
a response. The rational is as follows: the requester needs "at
some time" to get the public key of the issuer in order to verify
the certificate. If we mandate that field to be always present
thent it must get it *before* the request to the OCSP server. If we
make it optional, then it may get it before or after the request to
the OCSP server. This gives some flexibility, without too many
options.

The OCSP server should anyway have the Issuers public key and thus
its hash. The hash may allow the requester to disambigous some
responses in case of anonymity. 

Denis
 
> I agree with this discussion and would like to add some thoughts:
> 
> Peter Sylvester wrote:
> > > I actually think OCVP is a bigger thing than just making the hash
> > > of the issuer's PUBLIC key NULL. That whole topic should be
> > > addressed at one shot
> > >
> > I am *not* really talking about OCVP, I am talking about 'CertID',
> > a short way to identify a certificate. The syntax
> > for the identification should be flexible enough
> >
> > - not to require more than the original certificate in
> >   order to construct the identification.
> The is a very good assumption. While the authority key *may* be
> available, it certainly isn´t always available.
> 
> > - to allow identification of a certificate in a given context
> >   ==> serial number for example or/and hash of cert
> The serial number is a little bit weaker but supported by other parts of
> X.509, PKIX and several mail protocols, using issuer/serial for
> identification of a certificate. So issuer/serial or
> issuer/certificate-hash look like valid combinations. It may be a good
> idea to be able add a subject public key hash if necessary.
> 
> > - to allow the OCSP provider to find the source of
> >   information provider.
> >   ==> name of issuer may be necessary, hash of issuer name
> >       may not be sufficient.
> So for identification of issuer we probably have a choice of issuer-name
> or issuer-hash, probably in combination with issuer-public-key or
> issuer-public-key-hash as an optional parameter.
> 
> > - to ensure that the creator of the certificate really has
> >   a copy of a cert.
> >   ==> hash of cert for example, or serialnumber if authority
> >       allocates them in a sparse way.
> > If we assume that the orginal version of OCSP where it was
> > possible to just have a cert did make sense, thus I do not
> > see why there is a need for the issuer public key extract
> > in the certID. At least it should be optional in some way.
> >
> > It seems useful to me to fix a syntax for CertID that
> > is sufficiently open for extensions without requiring
> > a new protocol version..
> 
> The removal of the certificate proper as a means to "identify" a
> certificate forced us to specify an extension to OCSP to do this
> (transport the certificate in the request - optional, or in the reply -
> optional). If the consensus is that OCSP should not be able to transport
> the certificate proper, I think we should at least open the possibility
> to transport a certitficate hash.
> 
> That leads me back to the idea of making a lot of the identification
> parameters in "CertID" optional. But we will get serious
> interoperability issues. So either we build specific CertIDs with
> specific purposes in mind or we need some profiling (and probably a
> means for the responder to transport valid combinations back to the
> client).
> 
> Andreas
> --
> Fifty-three percent of Fortune 1000 executives think the
> Arch Deluxe is something that helps to run a computer.
> -- Jericho Communications

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Reply-To: <[email-masked]>
From: "Amit Kapoor" <[email-masked]>
To: "PKIX" <[email-masked]>
Subject: Testing the ASN.1 in Part 1
Date: Sat, 19 Sep 1998 13:58:24 -0700
Importance: Normal
Sender: [email-masked]

	The following two in PKIX1Implicit93 (and 88):

	DistributionPoint ::= SEQUENCE {
        distributionPoint       [0]     DistributionPointName OPTIONAL,
        reasons         	  [1]     ReasonFlags OPTIONAL,
        cRLIssuer               [2]     GeneralNames OPTIONAL
	}

	DistributionPointName ::= CHOICE {
        fullName                [0]     GeneralNames,
        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName
	}

	Is the tagging correct for DistributionPointName in
	DistributionPoint considering the package is defined as IMPLICIT
	tagging?  How will will the decoder know which one of the two
	DistributionPointName (GeneralNames | RelativeDistinguishedName) is
	represented by [0]?  Similarly for IssuingDistPointSyntax.

	I recall a message from someone from OSS a while back on somewhat
	a similar subject but afraid could not locate it in the archives.

	Thanks.

Amit

Date: Fri, 18 Sep 1998 18:00:08 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

All,

The intent was to provide an alternative to CRLs.  Following that model,
there's an underlying assumption that the end-entity is in possession of
the CA's certificate (as would be needed to validate the signature on a CRL.)

OCSP never had a requirement to validate an end-entity certificate in the
absence of the CA certificate at the requestor end.  It's not just a
requirement on syntax at the request.  This would also imply path
validation logic on the server.  The consensus has been conclusively
established that full certificate validation is beyond the scope of this
protocol.

There's consequently no need to alter the request syntax.

Mike

Date: Fri, 18 Sep 1998 14:38:11 -0700
To: "Flanigan, Bill" <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: proposed text for attributes
Sender: [email-masked]

At 04:39 PM 9/18/98 -0400, Flanigan, Bill wrote:
>Hmm.  I'm starting to have a what-does-it really-say/mean problem with
>things like the "may" word, the "local policy" words, and, in fact, the
>wording of the entire paragraph on the cACertificate attribute.  What
>happened to the "shall" word, and what does "local policy" add in the way
>clarification?   
>	It's not what goes where (we seem to have rough consensus here), but
>rather how to express this with minimal ambiguity and number of words.  How
>about a single sentence along the lines of "The cACertificate attribute of a
>CA's directory entry shall be used to store self-issued certificates (if
>any) and certificates issued to this CA by CAs in the same realm as this
>CA"?

Why not replace "realm" (or domain or scope) with what the word(s) intend.
I take "CA's in the same realm/domain" to mean "CA's acting under a common
authority-to-issue".

Does this help?

___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: 510-422-3881             LLLLLLLL

From: "Flanigan, Bill" <[email-masked]>
To: [email-masked]
Subject: RE: proposed text for attributes
Date: Fri, 18 Sep 1998 16:39:58 -0400
Sender: [email-masked]

Hmm.  I'm starting to have a what-does-it really-say/mean problem with
things like the "may" word, the "local policy" words, and, in fact, the
wording of the entire paragraph on the cACertificate attribute.  What
happened to the "shall" word, and what does "local policy" add in the way
clarification?   
	It's not what goes where (we seem to have rough consensus here), but
rather how to express this with minimal ambiguity and number of words.  How
about a single sentence along the lines of "The cACertificate attribute of a
CA's directory entry shall be used to store self-issued certificates (if
any) and certificates issued to this CA by CAs in the same realm as this
CA"?

Bill Flanigan

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 681-2318
Defense Information Systems Agency      Fax:           (703) 681-2814 
Information Assurance Engineering       DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           (703) 681-2318   
Falls Church, VA 22041-2717        Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]
> Sent:	Friday, September 18, 1998 12:39 PM
> To:	[email-masked]
> Subject:	Re: proposed text for attributes
> 
> >Unless there are any other objections to the wording, I'll get the draft
> >revised with this wording and submitted by Monday. 
> 
> I'd like to echo David Kurn's concern that the wording with respect to the
> cACertificate attribute of a CA's directory entry. If you don't define
> "realm",
> then there doesn't seem much point to saying that "some things that person
> accessing the directory cannot determine will appear in the cACertificate
> attribute". Why is that still in the spec if it's up to local policy to
> decide
> what to put there?
> 
> Maybe better wording would be "The cACertificate attribute of a CA's
> directory
> entry may be populated with certificates defined by local policy" and
> leave
> the
> rest of the paragraph out.
> 
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Fri, 18 Sep 1998 21:15:06 +0300 (   )
From: Jan Willemson <[email-masked]>
To: [email-masked]
Subject: Who uses what?
Sender: [email-masked]

Hello!

Excuse me please for being yet-another-newbie and asking a newbie 
question. But this is the only way to get smart.

I have been reading ietf-pkix drafts for some time and found a lot of
proposed X.509 extensions. On the other hand there are many companies
(Netscape etc) producing cert-software that uses (as I understand) some of
these extensions and some extensions of their own. So - is there somewhere
out there an overview of who uses what? I believe there is, but my
webcrawling has not been able to find it yet. I would be grateful for all
hints/links etc.

Thank you:)

Jan

Date: Fri, 18 Sep 1998 13:29:49 -0400
To: Dean Povey <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Testing the ASN.1 in Part 1 
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

<html>
You found a minor editorial error in the document, but not an ASN.1
error.<br>
<br>
For some reason, CertificatePolicies is defined here and where it should
be.<br>
<br>
The two lines with '*' at the front should be deleted:<br>
<br>
<font face="Courier New, Courier">&nbsp;&nbsp; id-ce-policyConstraints
OBJECT IDENTIFIER ::=&nbsp; { id-ce 36 }<br>
<br>
*&nbsp; CertificatePoliciesSyntax ::=<br>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SEQUENCE SIZE (1..MAX) OF PolicyInformation<br>
<br>
&nbsp;&nbsp; PolicyConstraints ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
requireExplicitPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[0] SkipCerts OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
inhibitPolicyMapping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[1] SkipCerts OPTIONAL }<br>
<br>
&nbsp;&nbsp; SkipCerts ::= INTEGER (0..MAX)<br>
<br>
<br>
</font>Russ<br>
<br>
<br>
<br>
At 03:47 PM 9/18/98 +1000, Dean Povey wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt;Anyone who plans to get around to checking the ASN.1 after
part 1 becomes<br>
&gt;&gt;&gt;an RFC: could you do it now instead? This would be a great
help to us all.<br>
&gt;&gt;&gt;Thanks!<br>
&gt;&gt;&gt;<br>
&gt;<br>
&gt;More bugs in PKIX1ImplictXX<br>
&gt;<br>
&gt;The ASN.1 for PolicyConstraints is incorrect. In both the 88 and 93
versions <br>
&gt;it is specified as a SEQUENCE SIZE(1..MAX) OF SEQUENCE { ... }.&nbsp;
This is <br>
&gt;inconsistent with the X.509 definition and it also doesn't make any
sense for <br>
&gt;it to be a SEQUENCE OF.&nbsp; The definition of PolicyConstraints
should&nbsp; be:<br>
&gt;<br>
&gt;PolicyConstraints ::= SEQUENCE {<br>
&gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>requireExplicitPolicy<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>[0]
SkipCerts OPTIONAL,<br>
&gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>inhibitPolicyMapping<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[1]
SkipCerts OPTIONAL }<br>
&gt;<br>
&gt;Also the authorityInfoAccess OID is missing in the 88 module, it
should be:<br>
&gt;<br>
&gt;id-pe-authorityInfoAccess&nbsp; OBJECT IDENTIFIER ::= { id-pe 1
}<br>
&gt;<br>
&gt;More as I find 'em :-).<br>
&gt;<br>
&gt;<br>
&gt;-- <br>
&gt;Dean Povey,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | e-m:
[email-masked]&nbsp;&nbsp;&nbsp;&nbsp; | Cryptozilla:<br>
&gt;Research Scientist&nbsp; | ph:&nbsp; +61 7 3864
5120&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
<a href="http://www.cryptozilla.org/" eudora="autourl">www.cryptozilla.org/</a><br>
&gt;Security Unit, DSTC | fax: +61 7 3864
1282&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Oscar - PKI Toolkit:<br>
&gt;Brisbane, Australia | www: security.dstc.edu.au/ |&nbsp;
oscar.dstc.qut.edu.au/<br>
&gt;<br>
&gt;<br>
</html>

Date: Fri, 18 Sep 1998 09:39:16 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: proposed text for attributes
Sender: [email-masked]

>Unless there are any other objections to the wording, I'll get the draft
>revised with this wording and submitted by Monday. 

I'd like to echo David Kurn's concern that the wording with respect to the
cACertificate attribute of a CA's directory entry. If you don't define
"realm",
then there doesn't seem much point to saying that "some things that person
accessing the directory cannot determine will appear in the cACertificate
attribute". Why is that still in the spec if it's up to local policy to decide
what to put there?

Maybe better wording would be "The cACertificate attribute of a CA's directory
entry may be populated with certificates defined by local policy" and leave
the
rest of the paragraph out.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 17:41:07 +0200
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I support the suggestion from Denis.

I suggest that one adds an optional hash of the certificate.
it MAY be returned by the OCSP server, and it MAY be
requested by the OCSP server. one could use the now obsolete
error code certrequired (rename it certhashrequired).

Whenever a client actually has the cert I would expect that
it always sets the certHash in the request, the OCSP server
may remove the certHash in the response if the certHash
value was not used in order for identification, e.g. when
only the serialNumber was used. 

   CertID          ::=     SEQUENCE {
        hashAlgorithm       AlgorithmIdentifier,
        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
        issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of Issuers public key
        serialNumber        CertificateSerialNumber 
        certHash            OCTET STRING OPTIONAL, -- hash of the certificate.

   }

Date: Fri, 18 Sep 1998 17:14:48 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Andreas Berger <[email-masked]>
CC: Peter Sylvester <[email-masked]>, [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

Andreas,

I share your concerns.

The current definition of CertId is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public
key
       serialNumber        CertificateSerialNumber }

CertID is used both in the request and in the response.
I would suggest to change it to:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of
Issuers public key
       serialNumber        CertificateSerialNumber }

making the issuerKeyHash optional.

The issuerKeyHash would be optional for a request but mandatory for
a response. The rational is as follows: the requester needs "at
some time" to get the public key of the issuer in order to verify
the certificate. If we mandate that field to be always present
thent it must get it *before* the request to the OCSP server. If we
make it optional, then it may get it before or after the request to
the OCSP server. This gives some flexibility, without too many
options.

The OCSP server should anyway have the Issuers public key and thus
its hash. The hash may allow the requester to disambigous some
responses in case of anonymity. 

Denis
 
> I agree with this discussion and would like to add some thoughts:
> 
> Peter Sylvester wrote:
> > > I actually think OCVP is a bigger thing than just making the hash
> > > of the issuer's PUBLIC key NULL. That whole topic should be
> > > addressed at one shot
> > >
> > I am *not* really talking about OCVP, I am talking about 'CertID',
> > a short way to identify a certificate. The syntax
> > for the identification should be flexible enough
> >
> > - not to require more than the original certificate in
> >   order to construct the identification.
> The is a very good assumption. While the authority key *may* be
> available, it certainly isn´t always available.
> 
> > - to allow identification of a certificate in a given context
> >   ==> serial number for example or/and hash of cert
> The serial number is a little bit weaker but supported by other parts of
> X.509, PKIX and several mail protocols, using issuer/serial for
> identification of a certificate. So issuer/serial or
> issuer/certificate-hash look like valid combinations. It may be a good
> idea to be able add a subject public key hash if necessary.
> 
> > - to allow the OCSP provider to find the source of
> >   information provider.
> >   ==> name of issuer may be necessary, hash of issuer name
> >       may not be sufficient.
> So for identification of issuer we probably have a choice of issuer-name
> or issuer-hash, probably in combination with issuer-public-key or
> issuer-public-key-hash as an optional parameter.
> 
> > - to ensure that the creator of the certificate really has
> >   a copy of a cert.
> >   ==> hash of cert for example, or serialnumber if authority
> >       allocates them in a sparse way.
> > If we assume that the orginal version of OCSP where it was
> > possible to just have a cert did make sense, thus I do not
> > see why there is a need for the issuer public key extract
> > in the certID. At least it should be optional in some way.
> >
> > It seems useful to me to fix a syntax for CertID that
> > is sufficiently open for extensions without requiring
> > a new protocol version..
> 
> The removal of the certificate proper as a means to "identify" a
> certificate forced us to specify an extension to OCSP to do this
> (transport the certificate in the request - optional, or in the reply -
> optional). If the consensus is that OCSP should not be able to transport
> the certificate proper, I think we should at least open the possibility
> to transport a certitficate hash.
> 
> That leads me back to the idea of making a lot of the identification
> parameters in "CertID" optional. But we will get serious
> interoperability issues. So either we build specific CertIDs with
> specific purposes in mind or we need some profiling (and probably a
> means for the responder to transport valid combinations back to the
> client).
> 
> Andreas
> --
> Fifty-three percent of Fortune 1000 executives think the
> Arch Deluxe is something that helps to run a computer.
> -- Jericho Communications

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: proposed text for attributes
Date: Fri, 18 Sep 1998 07:59:42 -0400
Sender: [email-masked]

Santosh and I prefer the use of 'realm'. Scope, although not as bad as
domain, also has some other meanings associated with it in the PKI area.

Unless there are any other objections to the wording, I'll get the draft
revised with this wording and submitted by Monday. I also will be submitting
a new version of the LDAPv2 protocol profile, but this is only because the
current draft expires this month. There are no changes to it and it passed
last call back in January (for those who weren't following this list at that
time, the IESG would not allow it to progress to RFC without this
accompanying schema).

Sharon

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Fri, 18 Sep 1998 12:06:44 +0200
From: Andreas Berger <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

I agree with this discussion and would like to add some thoughts:

Peter Sylvester wrote:
> > I actually think OCVP is a bigger thing than just making the hash
> > of the issuer's PUBLIC key NULL. That whole topic should be
> > addressed at one shot
> >
> I am *not* really talking about OCVP, I am talking about 'CertID',
> a short way to identify a certificate. The syntax
> for the identification should be flexible enough
> 
> - not to require more than the original certificate in
>   order to construct the identification.
The is a very good assumption. While the authority key *may* be
available, it certainly isn´t always available.
 
> - to allow identification of a certificate in a given context
>   ==> serial number for example or/and hash of cert
The serial number is a little bit weaker but supported by other parts of
X.509, PKIX and several mail protocols, using issuer/serial for
identification of a certificate. So issuer/serial or
issuer/certificate-hash look like valid combinations. It may be a good
idea to be able add a subject public key hash if necessary.

> - to allow the OCSP provider to find the source of
>   information provider.
>   ==> name of issuer may be necessary, hash of issuer name
>       may not be sufficient.
So for identification of issuer we probably have a choice of issuer-name
or issuer-hash, probably in combination with issuer-public-key or
issuer-public-key-hash as an optional parameter.

> - to ensure that the creator of the certificate really has
>   a copy of a cert.
>   ==> hash of cert for example, or serialnumber if authority
>       allocates them in a sparse way.
> If we assume that the orginal version of OCSP where it was
> possible to just have a cert did make sense, thus I do not
> see why there is a need for the issuer public key extract
> in the certID. At least it should be optional in some way.
> 
> It seems useful to me to fix a syntax for CertID that
> is sufficiently open for extensions without requiring
> a new protocol version..

The removal of the certificate proper as a means to "identify" a
certificate forced us to specify an extension to OCSP to do this
(transport the certificate in the request - optional, or in the reply -
optional). If the consensus is that OCSP should not be able to transport
the certificate proper, I think we should at least open the possibility
to transport a certitficate hash.

That leads me back to the idea of making a lot of the identification
parameters in "CertID" optional. But we will get serious
interoperability issues. So either we build specific CertIDs with
specific purposes in mind or we need some profiling (and probably a
means for the responder to transport valid combinations back to the
client).

Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 11:02:53 +0200
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

> I thought the issue with this was that in a case of a request where the
> certificate was sent in place of the certID, a response could not be
> formed unless the responder already had the issuer cert (or at least
> knew its key hash).  This has been dealt with, since request now must
> have a certID for each requested cert.  Was there some additional issue
> I wasn't aware of?

The original text provided to USE a certificate and nothing else
to form a request. This is no longer possible.

CertID in its current form cannot be used as a replacement for a
certificate in the case where the client does not have the issuer cert.
 
The syntax for CertID has not been discussed in the context where
this is the ONLY way to identify a cert. 

Peter

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 10:56:24 +0200
To: [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [email-masked]
Sender: [email-masked]

> > 
> 
> I actually think OCVP is a bigger thing than just making the hash
> of the issuer's PUBLIC key NULL. That whole topic should be
> addressed at one shot
> 
I am *not* really talking about OCVP, I am talking about 'CertID',
a short way to identify a certificate. The syntax
for the identification should be flexible enough  

- not to require more than the original certificate in
  order to construct the identification.

- to allow identification of a certificate in a given context
  ==> serial number for example or/and hash of cert

- to allow the OCSP provider to find the source of 
  information provider.
  ==> name of issuer may be necessary, hash of issuer name
      may not be sufficient. 

- to ensure that the creator of the certificate really has
  a copy of a cert.
  ==> hash of cert for example, or serialnumber if authority
      allocates them in a sparse way.

If we assume that the orginal version of OCSP where it was
possible to just have a cert did make sense, thus I do not
see why there is a need for the issuer public key extract 
in the certID. At least it should be optional in some way.

It seems useful to me to fix a syntax for CertID that
is sufficiently open for extensions without requiring
a new protocol version..

Peter

Date: Fri, 18 Sep 1998 01:41:01 -0700
From: Dan Weinstein <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

>some remarks about the lastest OCSP draft:
>
>- It seems that the remarks about not knowing the public
>  key of an issuer are not addressed. 
>
>  It seems sufficient to ME to allow that the
>  hash of the issure private key MAY be a length 0 octet string,
>  something like that, or one might add the public
>  key of the OCSP responder instead. 
>
>  Thoughts?

I thought the issue with this was that in a case of a request where the
certificate was sent in place of the certID, a response could not be
formed unless the responder already had the issuer cert (or at least
knew its key hash).  This has been dealt with, since request now must
have a certID for each requested cert.  Was there some additional issue
I wasn't aware of?

Dan Weinstein
[email-masked]

cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Testing the ASN.1 in Part 1 
Date: Fri, 18 Sep 1998 15:47:57 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

>
>
>>Anyone who plans to get around to checking the ASN.1 after part 1 becomes
>>an RFC: could you do it now instead? This would be a great help to us all.
>>Thanks!
>>

More bugs in PKIX1ImplictXX

The ASN.1 for PolicyConstraints is incorrect. In both the 88 and 93 versions 
it is specified as a SEQUENCE SIZE(1..MAX) OF SEQUENCE { ... }.  This is 
inconsistent with the X.509 definition and it also doesn't make any sense for 
it to be a SEQUENCE OF.  The definition of PolicyConstraints should  be:

PolicyConstraints ::= SEQUENCE {
	requireExplicitPolicy	[0] SkipCerts OPTIONAL,
	inhibitPolicyMapping	[1] SkipCerts OPTIONAL }

Also the authorityInfoAccess OID is missing in the 88 module, it should be:

id-pe-authorityInfoAccess  OBJECT IDENTIFIER ::= { id-pe 1 }

More as I find 'em :-).

-- 
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

Date: Thu, 17 Sep 1998 14:53:31 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

Peter,
    Great catches - comments follow:

Peter Sylvester wrote:
> 
> hello,
> 
> some remarks about the lastest OCSP draft:
> 
> - It seems that the remarks about not knowing the public
>   key of an issuer are not addressed.
> 
>   It seems sufficient to ME to allow that the
>   hash of the issure private key MAY be a length 0 octet string,
>   something like that, or one might add the public
>   key of the OCSP responder instead.
> 
>   Thoughts?
> 

I actually think OCVP is a bigger thing than just making the hash
of the issuer's PUBLIC key NULL. That whole topic should be
addressed at one shot

> 
> - the remark
> 
>    " Response extensions may be used to
>    convey additional information on assertions made by the responder
>    regarding the status of the certificate such as positive statement
>    about issuance, validity, etc."
> 
>    should be removed behind all possible responses since extensions
>    can also be used to indicate additional interpretations for
>    revoked, notknown.
> 
> 
> -  >  The response "certRequired" is returned in cases where the server
>    >  requires the client to supply the certificate data itself in order to
>    >  construct a response.
> 
>    This paragraph should be removed
> 
>    etc for the ASN.1 response code
>       certRequired          (4),  --Must supply certificate

Agreed - will be fixed. Thanks for catching this

> 
> -  A.1.1 : "Where privacy is a
>    requirement, OCSP transactions exchanged using HTTP SHOULD be protected
>    using either TLS or SSL."
> 
>    Shouldn't the SHOULD be a MAY ?
> 
>    one could also use a VPN for example

Agreed.

> 
>    Or just add 'or by lower layer protection'.
> 
> have fun.

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 17 Sep 1998 18:36:01 +0200
To: [email-masked]
Subject: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

hello,

some remarks about the lastest OCSP draft:

- It seems that the remarks about not knowing the public
  key of an issuer are not addressed. 

  It seems sufficient to ME to allow that the
  hash of the issure private key MAY be a length 0 octet string,
  something like that, or one might add the public
  key of the OCSP responder instead. 

  Thoughts?

- the remark 
   
   " Response extensions may be used to
   convey additional information on assertions made by the responder
   regarding the status of the certificate such as positive statement
   about issuance, validity, etc."
 
   should be removed behind all possible responses since extensions
   can also be used to indicate additional interpretations for
   revoked, notknown. 

-  >  The response "certRequired" is returned in cases where the server
   >  requires the client to supply the certificate data itself in order to
   >  construct a response.

   This paragraph should be removed

   etc for the ASN.1 response code      
      certRequired          (4),  --Must supply certificate

-  A.1.1 : "Where privacy is a
   requirement, OCSP transactions exchanged using HTTP SHOULD be protected
   using either TLS or SSL."

   Shouldn't the SHOULD be a MAY ?

   one could also use a VPN for example

   Or just add 'or by lower layer protection'.  

have fun.

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 12:23:15 -0400
Sender: [email-masked]

I'm flexible on the term and have passed that on to Santosh (awaiting his
reply).  I see nothing wrong with scope or realm and am open to suggestion.
I agree that it would be good to select a term that doesn't have a
predefined meaning in the IETF. 
It is important to keep the definition of the specific criteria for its use
as a local matter so this mechanism can be used in different environments
with different criteria for the 'hints' provided by the CA to relying
parties, regardless of whether relying parties choose to examine those hints
or not. That, we've been in agreement on thoughout this debate, but I'm
quite agreeable to a different 'less loaded' term.

> ----------
> From: 	bgmiller[SMTP:[email-masked]]
> Sent: 	September 16, 1998 10:26 PM
> To: 	[email-masked]
> Subject: 	Re: Storage of CA Certificates in LDAP and X.500 Directory
> Attributes
> 
> 
> 
> Paul Hoffman / IMC wrote:
> 
> > I agree with David. The word "domain" has a specific meaning in the
> IETF,
> > and this definition doesn't match it. Could you use "realm" instead? Or
> are
> > there better words?
> 
> How about "scope"?
> 

From: "Kurn, David" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 08:43:54 -0700
Sender: [email-masked]

I think the actual choice of word here is not the issue.  You can call it
"Kingdom", but the flaw in the specification persists, since the last
sentence implies that the word has a definition that depends upon the
personal interpretation of the implementor.  This doesn't make for portable
programs.

I think the reason the specification needs the word is so that the spec can
give guidance about when to put a cross-cert in one bucket or in another
bucket.  And this, if I follow the recent conversations, has to do with
advice about how to do path development. (I'm stepping out on shaky ground
here).

*IF* we wish to say to those writing path evaluation programs:
  "You should look in the first bucket (caCertificates) first, and then in
the second bucket"
then we can give some guidance about how to populate the two buckets, which
could in effect would say:

You should put certificates in the appropriate bucket according to your
expectation about how to optimize the path development given that clients
will look in the caCertificates first.  Your choice will affect efficiency,
not correctness.

I go back to something I remember from learning about Object-Oriented
programming .... don't ask "what is it", but rather "what does it do".

David Kurn
Compaq Computer Corp

-----Original Message-----
From: bgmiller [mailto:[email-masked]]
Sent: Wednesday, September 16, 1998 7:27 PM
To: [email-masked]
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory
Attributes

Paul Hoffman / IMC wrote:

> I agree with David. The word "domain" has a specific meaning in the IETF,
> and this definition doesn't match it. Could you use "realm" instead? Or
are
> there better words?

How about "scope"?

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-06.txt
Date: Thu, 17 Sep 1998 10:09:49 -0400
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		: X.509 Internet Public Key Infrastructure 
                          Online Certificate Status Protocol - OCSP
	Author(s)	: M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams
	Filename	: draft-ietf-pkix-ocsp-06.txt
	Pages		: 20
	Date		: 16-Sep-98
	
   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs. Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents.
 
   An overview of the protocol is provided in section 3. Functional
   requirements are specified in section 4. Details of the protocol are
   in section 5. We cover security issues with the protocol in section
   6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
   syntactic elements and appendix C specifies the mime types for the
   messages.
 
   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
   'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
   document (in uppercase, as shown) are to be interpreted as described
   in [RFC2119].

Internet-Drafts are 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-ocsp-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-06.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ocsp-06.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-ocsp-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 16 Sep 1998 22:26:37 -0400
From: bgmiller <[email-masked]>
Reply-To: [email-masked]
Organization: Jones Internet Channel
To: [email-masked]
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Sender: [email-masked]

Paul Hoffman / IMC wrote:

> I agree with David. The word "domain" has a specific meaning in the IETF,
> and this definition doesn't match it. Could you use "realm" instead? Or are
> there better words?

How about "scope"?

Date: Wed, 16 Sep 1998 15:49:01 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Sender: [email-masked]

At 03:22 PM 9/16/98 -0700, Kurn, David wrote:
>I still think the use of "domain" is very confusing, and should be removed
>from the text.

I agree with David. The word "domain" has a specific meaning in the IETF,
and this definition doesn't match it. Could you use "realm" instead? Or are
there better words?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Wed, 16 Sep 1998 15:22:03 -0700
Sender: [email-masked]

I still think the use of "domain" is very confusing, and should be removed
from the text.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, September 16, 1998 2:23 PM
To: [email-masked]
Subject: Storage of CA Certificates in LDAP and X.500 Directory
Attributes

Based on the pkix co-chair request, Sharon and I jointly propose the
following text:

"The cACertificate attribute of a CA's directory entry shall be used to
store certificates issued to this CA by CAs in the same domain as this
CA.  If there are any self-issued certificates and they require
publication, the caCertificate attribute shall be used to store them.

The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all certificates issued to this
CA, which are not self-issued.  Optionally, the reverse elements of the
crossCertificatePair attribute, of a CA's directory entry may contain a
subset of certificates issued by this CA to other CAs.  When both the
forward and the reverse elements are present in a single attribute
value, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.  When a reverse element is present, the
forward element value and the reverse element value need not be stored
in the same attribute value; in other words, they can be stored in
either a single attribute value or two attribute values.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
[email-masked]
http://www.cygnacom.com

From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Subject: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Date: Wed, 16 Sep 1998 17:22:55 -0400
Sender: [email-masked]

Based on the pkix co-chair request, Sharon and I jointly propose the
following text:

"The cACertificate attribute of a CA's directory entry shall be used to
store certificates issued to this CA by CAs in the same domain as this
CA.  If there are any self-issued certificates and they require
publication, the caCertificate attribute shall be used to store them.

The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all certificates issued to this
CA, which are not self-issued.  Optionally, the reverse elements of the
crossCertificatePair attribute, of a CA's directory entry may contain a
subset of certificates issued by this CA to other CAs.  When both the
forward and the reverse elements are present in a single attribute
value, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.  When a reverse element is present, the
forward element value and the reverse element value need not be stored
in the same attribute value; in other words, they can be stored in
either a single attribute value or two attribute values.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
[email-masked]
http://www.cygnacom.com

Date: Tue, 15 Sep 1998 13:52:32 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Schema Straw Poll Closure
Sender: [email-masked]

Well, thank you all for the enthusiastic balloting and commenting.  Steve
and I have at last managed to synch up, and here is how we interpret the
Straw Poll result.

There was no clear concensus winner in either Option 1 or Option 2.  There
was significant support for both options, at least on the basis of
installed product, plus various positions on technical grounds.  

We clearly need to accommodate the requirements of option 1 supporters by
permitting the population of the cACertificate attribute with self-issued
certificates and certificates issued by another CA to this CA within the
context of a locally defined domain.  In fairness to all, we feel we should
also accommodate the requirement of option 2 supporters to have all
certificates issued by CAs to this CA (which are placed in the subject CA
entry at all), regardless of the definition of domain, populated in the
crossCertificatePair attribute forward element.  

As secondary points, there appears to be consensus that population of the
reverse element is always optional. Text regarding optional, mutual
cross-certification also needs to be finalized but this will hopefully not
be contentious. 

This resolution should allow relying parties to operate under either option
successfully; the main negative in this resolution seems to be that, in
option 1 environments, there would necessarily be some duplication of data
in the directory.

This essentially means a compromise that hopefully all parties can live
with, although we know it will not go down in history as the most brilliant
technical decision of all time.

In the absence of violent objections, we propose that Sharon and Santosh
jointly craft text that follows this resolution, and that we seek to close
debate on this topic ASAP.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

From: Trevor Sosebee <[email-masked]>
Date: Tue, 15 Sep 1998 11:02:01 -0500 (CDT)
To: [email-masked]
Subject: UTF8String definition in PKIX-3
Sender: [email-masked]

In PKIX-3, UTF8String is defined as

	UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING.

I was wondering I someone could point me to the version of X.680 where 
UTF8String is defined.

Thanks,
Trevor

To: Paul Hoffman / IMC <[email-masked]>
cc: [email-masked]
Subject: Re: Testing the ASN.1 in Part 1 
Date: Tue, 15 Sep 1998 14:29:01 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

>Anyone who plans to get around to checking the ASN.1 after part 1 becomes
>an RFC: could you do it now instead? This would be a great help to us all.
>Thanks!
>

*grr* I was putting this off :-)

I am using the 88ish syntax

PKIX1Explicit88 parses fine, but there are stuff ups in the imports in
PKIX1Implicit88 

To the IMPORTS section in PKIX1Implicit88 add the following:

id-pkix, BMPString, UniversalString, UTF8String

And delete the following two redundant definitions:

id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 } 

Other than that it looks like so far so good.  I'll have to do some more work 
until this is fully tested.

-- 
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

Date: Mon, 14 Sep 1998 10:18:54 -0700
Subject: Re: Testing the ASN.1 in Part 1
From: "Aram Perez" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, [email-masked]
Sender: [email-masked]

Hi Paul,

Check the web site of Open Systems Solutions (http://www.oss.com). They do free
ASN.1 syntax checking for groups such as IETF.

Regards,
Aram Perez
Apple Computer, Inc.

>Greetings, all. I know that all this discussion of LDAP is fascinating, but
>I'd like to come back to draft-ietf-pkix-ipki-part1 for a second. It is in
>IESG last call, almost ready (we hope) to become an RFC. Tim has just made
>minor tweaks to it (it is now -10.txt), and we're almost there.
>
>Has anyone tested the full ASN.1 in part 1 lately? Given the anti-ASN.1
>sentiment in the IETF, it would be Very Embarassing if we got an RFC and
>had to revise it due to an ASN.1 error. Worse yet, it would be bad if there
>was an error and two implementors did different things to get around it.
>
>Anyone who plans to get around to checking the ASN.1 after part 1 becomes
>an RFC: could you do it now instead? This would be a great help to us all.
>Thanks!
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Mon, 14 Sep 1998 10:09:39 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Andreas Berger <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: OCSP ASN.1 comments
Sender: [email-masked]

Hi Andreas,
    Thanks for the comment - it has already been fixed.

Regards,
Ambarish

Andreas Berger wrote:
> 
> Hi,
> 
> I am forwarding here parts of a comment of Mr. Thomas Garnatz, Security
> Networks GmbH:
> 
> There is a context sensitive coding in ResponseData and ResponderID
> 
> ResponseData          ::= SEQUENCE {
>       version                 [0]     EXPLICIT Version DEFAULT v1,
>       reponderID                      ResponderID,
>       ...
> }
> 
> ResponderID                   ::=     CHOICE {
>       byName          [0]     Name,
>       byKey                   [1]     KeyHash
> }
> 
> Since the version field is optional (i.e. not present for version 1) it
> is not very easy to distinguish between version (explicit [0]) and
> byName [0]. The suggested idea is to either remove the DEFAULT or not to
> use [0] for byName.
> 
> I hope I got the translation right and made some sense to the ASN.1
> gurus (myself not being one).
> 
> Andreas Berger
> --
> Fifty-three percent of Fortune 1000 executives think the
> Arch Deluxe is something that helps to run a computer.
> -- Jericho Communications

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

Date: Mon, 14 Sep 1998 08:36:12 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Testing the ASN.1 in Part 1
Sender: [email-masked]

Greetings, all. I know that all this discussion of LDAP is fascinating, but
I'd like to come back to draft-ietf-pkix-ipki-part1 for a second. It is in
IESG last call, almost ready (we hope) to become an RFC. Tim has just made
minor tweaks to it (it is now -10.txt), and we're almost there.

Has anyone tested the full ASN.1 in part 1 lately? Given the anti-ASN.1
sentiment in the IETF, it would be Very Embarassing if we got an RFC and
had to revise it due to an ASN.1 error. Worse yet, it would be bad if there
was an error and two implementors did different things to get around it.

Anyone who plans to get around to checking the ASN.1 after part 1 becomes
an RFC: could you do it now instead? This would be a great help to us all.
Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 14 Sep 1998 15:01:43 +0200
From: Andreas Berger <[email-masked]>
To: pkix <[email-masked]>
Subject: OCSP ASN.1 comments
Sender: [email-masked]

Hi,

I am forwarding here parts of a comment of Mr. Thomas Garnatz, Security
Networks GmbH:

There is a context sensitive coding in ResponseData and ResponderID

ResponseData          ::= SEQUENCE {
      version                 [0]     EXPLICIT Version DEFAULT v1,
      reponderID                      ResponderID,
      ...
}

ResponderID                   ::=     CHOICE {
      byName          [0]     Name,
      byKey                   [1]     KeyHash
}

Since the version field is optional (i.e. not present for version 1) it
is not very easy to distinguish between version (explicit [0]) and
byName [0]. The suggested idea is to either remove the DEFAULT or not to
use [0] for byName.

I hope I got the translation right and made some sense to the ASN.1
gurus (myself not being one).

Andreas Berger
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

Date: Sun, 13 Sep 1998 00:25:48 +0200
To: Mike Smith <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Mike,

First of all. I truly hope that I didn't offend you with my remark.
I certainly didn't want that.

Yes, the problem you raise is both real and relevant. I just don't share
the same belief in automation through policy definition codings in
certificate extensions.

I do believe that it MAY work sufficient in a fairly closed environment
where one organization has the control over interpretations and
implementations. But international standard, no way. 

Actually I believe that the policy OID in certificates may serve automation
just fine in real life. If trust automation is developing to be an
competitive edge in a certain community, then CA:s will try to adopt to
well known policies and indicate them in the certificates. So in that case
there will just be a limited space of policy OID:s to consider. Whether
this will happen or not is up to the market but the market sure has the
tools needed if there is money to be made through interoperability.

Over specifying things before the true need has emerged is always
dangerous. And I'm sorry to say that we Europeans have some quite extensive
experiences along that line.

/Stefan

At 10:11 AM 9/11/98 -0600, Mike Smith wrote:
>OK, the quagmire consensus is taken for what it is.  I first proposed
enhancing automating some trust decisions using a new extension, then using
the existing policy qualifier.  The overwhelming response from people whose
comments I respect is that we should consider the policy OID sufficient.
>
>If this is to be technological solution for automated processing, then we
need to step backwards a few years and look at the definition of "to
process" with regard to the actual CPS that the OID points towards.
>
>Maybe the old PKIX 1 needs to be restructured to retain its contents and
menaing, but to specify a parsable structure and standardize (define
rigidly) the terms used in the policies and practices or concept of
operations (whatever people are using the OID to point towards).
>
>The goal here is not to reopen old wounds or pull people into yet another
quagmire (my cletic genetics may predispose me to jumping inot bogs,
however).  The question that folks seem to be attemoting to address is the
automation of trust domains.  
>
>The feedback I get is not really "you are off track", but that "the
problem is too big to solve", or that this group is incapable of solving
this problem in a timely manner.
>
>I disagree.  This group is comprised of the most experienced and, IMO,
brightest technologists in the industry.  
>
>So, I pose the question to the best and brightest:  How do you suggest,
then that we automate domain or trust processing?
>
>I think I know how we are going to operate across domains of trust  in the
finanical industry.  I suggest that we in the IETF apply our great
resources building AUTOMATED systems that have a high assurance of working
together across the Internet.
>
>If, as some have suggested , I need to write a draft covering these
issues, I am up for that (if Warwick and Stephen think it is worth the
group's time).
>
>Michael
>
>>>> Stefan Santesson <[email-masked]> 09/11 8:44 AM >>>
>******************  InterScan Message (on zbc2)
>
>noname is scanned and no virus found
>*********************************************************
>

    !
>!

From: Charles Moore <[email-masked]>
To: "'Peter Lipp'" <[email-masked]>, Paul Koning <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Sun, 13 Sep 1998 07:31:56 +1000
Sender: [email-masked]

All, we ( Australian National Standards Group) have been working on a
simular problem. 
I.e how does a relying party know what evidence of Identity that the
RA/CA makes a statement about when performing the registration process.
There are assocaited issues, but lets start with this one.

We have a working draft that proposes the use of a policy qualifier as
below:

pkaf-policy-Identification CERT-POLICY-QUALIFIER ::= {
	POLICY-QUALIFIER-ID	id-pkaf-policy-Identification
	QUALIFIER-TYPE		Identification }

Identification ::= BIT STRING {
	driversLicense	(0),
	passport	(1),
	creditCard	(2),
	organisationIDBadge	(3),
	governmentIDBadge	(4),
	articlesOfIncorp	(5),
	companySeal	(6),
	notarizedDoc	(7),
	biometricThumb	(8),
	biometricVoice	(9),
	biometricFace	(10),
	biometricRetina	(11) }

We have not used A CP ( or any reference to a CPS) alone to do this as
experience is that within a given policy there is no direct mapping to
the level of identification needed. Identification is not the driver for
a CP or CPS, but rather a qualifier of these. 

Hope this assists the discussion.

Regards
Charles Moore
SPYRUS Pty Ltd
Phone: +61 73 256 7465, Extension 101

From: "Peter Lipp" <[email-masked]>
To: "Paul Koning" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Fri, 11 Sep 1998 21:59:08 +0200
Importance: Normal
Sender: [email-masked]

> I very much doubt that a mapping from natural language legal
> terminology to formal logic will be defined anytime in the next 10
> years.  Come to think of it, thinking of Goedel makes me wonder if
> it's even theoretically possible.

But that would not be necessary. I could well imagine defining a set of
attributes describing the most important elements of such statements like

... passport needed ....
... anything that looks like an ID with photo sufficient ...
... we don't check anything at all ....

or things like that. The problem I see is in all cases the trust into 
the truthfulness of such statements - it does not help anybody if my
machine can verify that indeed the CA claims to having seen a passport
if I don't trust the CA not to lie in the first place. This needs checks
by myself or trusted representatives in any case, and no formal logic will
help.

Peter

Date: Fri, 11 Sep 1998 12:33:22 -0600
From: Mike Smith <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

I think you've got it.  

As far as being ahead of state of the art, I've been in meetings with many of the folks on this list several years ago when the same issues of parsing the CPS in order to automate were brought up.

By the way, I was not suggesting parsing a free-form CPS, but structuring the CPS for automated processing, which might need then both a human and machine readable form or sections of the same CPS.

The saying goes (Warren Miller, Ski Film producer):  "If you don't do it now, You'll only be another year older when you do".

Michael

>>> Paul Koning <[email-masked]> 09/11 12:07 PM >>>
>>>>> "Mike" == Mike Smith <[email-masked]> writes:

 Mike> ...Maybe the old PKIX 1 needs to be restructured to retain its
 Mike> contents and menaing, but to specify a parsable structure and
 Mike> standardize (define rigidly) the terms used in the policies and
 Mike> practices or concept of operations (whatever people are using
 Mike> the OID to point towards).

 Mike> ...The feedback I get is not really "you are off track", but that
 Mike> "the problem is too big to solve", or that this group is
 Mike> incapable of solving this problem in a timely manner.

 Mike> I disagree.  This group is comprised of the most experienced
 Mike> and, IMO, brightest technologists in the industry.

 Mike> So, I pose the question to the best and brightest: How do you
 Mike> suggest, then that we automate domain or trust processing?

I think the question you pose is not a little, but vastly beyond the
state of the art.

As I understand it, the goal you're posing is: define a way for the CA 
to encode into the cert information that the relying party can use to
decide whether the subject of that cert was authenticated by means
strong enough to be satisfactory to the relying party.

A somewhat analogous question (though not applicable to a particular
cert) is whether the CA's CPS is strong enough for the relying party.

It seems to me that this latter question is one you drop onto your
company's lawyer to settle.  It involves parsing natural language
(well, anyway, legal language) to see what it means, and whether that
meaning is satisfactory to your corporate requirements.

I very much doubt that a mapping from natural language legal
terminology to formal logic will be defined anytime in the next 10
years.  Come to think of it, thinking of Goedel makes me wonder if
it's even theoretically possible.

The above would seem to be just as applicable to the cert subject
authentication statement as it is to the CPS.  After all, the
authentication used in creating a particular cert is basically just
the application of the CPS to that particular subject.

 paul

Date: Fri, 11 Sep 1998 14:07:42 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

>>>>> "Mike" == Mike Smith <[email-masked]> writes:

 Mike> ...Maybe the old PKIX 1 needs to be restructured to retain its
 Mike> contents and menaing, but to specify a parsable structure and
 Mike> standardize (define rigidly) the terms used in the policies and
 Mike> practices or concept of operations (whatever people are using
 Mike> the OID to point towards).

 Mike> ...The feedback I get is not really "you are off track", but that
 Mike> "the problem is too big to solve", or that this group is
 Mike> incapable of solving this problem in a timely manner.

 Mike> I disagree.  This group is comprised of the most experienced
 Mike> and, IMO, brightest technologists in the industry.

 Mike> So, I pose the question to the best and brightest: How do you
 Mike> suggest, then that we automate domain or trust processing?

I think the question you pose is not a little, but vastly beyond the
state of the art.

As I understand it, the goal you're posing is: define a way for the CA 
to encode into the cert information that the relying party can use to
decide whether the subject of that cert was authenticated by means
strong enough to be satisfactory to the relying party.

A somewhat analogous question (though not applicable to a particular
cert) is whether the CA's CPS is strong enough for the relying party.

It seems to me that this latter question is one you drop onto your
company's lawyer to settle.  It involves parsing natural language
(well, anyway, legal language) to see what it means, and whether that
meaning is satisfactory to your corporate requirements.

I very much doubt that a mapping from natural language legal
terminology to formal logic will be defined anytime in the next 10
years.  Come to think of it, thinking of Goedel makes me wonder if
it's even theoretically possible.

The above would seem to be just as applicable to the cert subject
authentication statement as it is to the CPS.  After all, the
authentication used in creating a particular cert is basically just
the application of the CPS to that particular subject.

	paul

Date: Fri, 11 Sep 1998 10:16:37 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

OK, the quagmire consensus is taken for what it is.  I first proposed automating some trust decisions using a new extension, then using the existing policy qualifier.  The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient.

If this is to be the technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards.

Maybe the old PKIX 1 needs to be restructured to retain its contents and meaning, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies ,  practices or concept of operations (whatever people are using the OID to point towards).

The goal here is not to reopen old wounds or pull people into yet another quagmire (my Celtic genetics may predispose me to jumping inot bogs, however).  The question that folks seem to be attempting to address is the automation of trust domains.  

The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner.

I disagree.  This group is comprised of the most experienced and, IMO, brightest technologists in the industry.  

So, I pose the question to the best and brightest:  How do you suggest, then, that we automate domain or trust processing?

I think I know how we are going to operate across domains of trust  in the finanical industry.  I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet.

If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time).

Michael

>>> Stefan Santesson <[email-masked]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************

Date: Fri, 11 Sep 1998 10:11:04 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

OK, the quagmire consensus is taken for what it is.  I first proposed enhancing automating some trust decisions using a new extension, then using the existing policy qualifier.  The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient.

If this is to be technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards.

Maybe the old PKIX 1 needs to be restructured to retain its contents and menaing, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies and practices or concept of operations (whatever people are using the OID to point towards).

The goal here is not to reopen old wounds or pull people into yet another quagmire (my cletic genetics may predispose me to jumping inot bogs, however).  The question that folks seem to be attemoting to address is the automation of trust domains.  

The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner.

I disagree.  This group is comprised of the most experienced and, IMO, brightest technologists in the industry.  

So, I pose the question to the best and brightest:  How do you suggest, then that we automate domain or trust processing?

I think I know how we are going to operate across domains of trust  in the finanical industry.  I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet.

If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time).

Michael

>>> Stefan Santesson <[email-masked]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************

Date: Fri, 11 Sep 1998 11:06:33 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: [email-masked]
CC: Santosh Chokhani <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: forward & reverse elements - population
Sender: [email-masked]

Dennis,
	
	See comments below.

Denis Pinkas wrote:
> 
> Santosh,
> 
> Here is my answer to your question.
> 
> > Denis:
> 
> > I agree with you.  Clarification of the text is easy.
> 
> ???
> 
> > However, I have a
> > question.  Must a certificate issued to a CA appear in the forward
> > element, caCertificate or can it be missing altogether?
> 
> "MUST" is the wrong verb. A certificate issued by another CA is not
> mandated to be present at all. It MAY be present.
> 
> Let me now re-phrase your question: May a certificate issued to a CA by
> another CA appear in the forward element, caCertificate or can it be
> missing altogether?
> 
> My answer is the following: It may only appear in the forward element of
> a crossCertificatePair.
> 
> I was quite happy (and still am I !) with the original text. I still
> wonder with the rational of the two buckets.
> 

	The problem with the original text is that it breaks the
implementations
that used the certificationAuthority-V2 object class.  That object class
stated
the caCertificate was mandatory.  

	This has been established and accepted, therefore the original text
is not an option anymore.

	We have heard arguments from both sides for option 1 and option 2. Each
of which have their own pros and cons.  I suggest we stick with those
two options
and move forward.

	Furthermore, Santosh has submitted strong technical arguments for
the two bucket approach.  The two bucket approach allows you to
logically
distinguish between two types of CA Certs without mandating that a CA
define
its policies with respect to bucket population.  If the CA publishes it
in 
the "wrong" bucket it will NOT compromise security and it will NOT cause
a 
denial of service, as long as clients look at both attributes.  It lead 
to inefficient path construction in the worst case, but that's a given
if you
have a one bucket approach.  

	Another issue is the duplication of certificates.  After profiling
at least one directory server we know that performance degrades after an
entry reaches a certain size.  In other words you can usually get
excellent
sub second response time out of a server ( in fact many responses per
second )
if the entry stays small.  As the entry grows in size, the response gets
slower.
We have tested with entries up to several megabytes in size and have
proved this.  Additionally, many companies still use small pipes for
their network infrastructure, and those pipes can be easily saturated. 
We should make a conscious decision to
attempt to minimize the amount of data a client will retrieve from a
single entry
while satisfying both option 1 and option 2 proponents.

> Up to now, none of the arguments about the notion of "local domain" has
> proven to be non-controversy. If the notion of local domain is important
> (I still wonder about it), there might be a different way to look at the
> issue. LDAPv2 allows to query any server that offers that interface, so
> different set of queries could be considered:
> 
>   1) Queries made to one or more local domain servers,
>   2) Queries made to one or more public domain servers.
> 
> As the name indicates it, local domain servers may not be publicly
> accessible, e.g. protected by firewalls or some other access control
> methods. Local domain servers would publish only what is relevant for
> their notion of local domain. They must publish everything that is
> relevant.
> 
> Public domain servers would have no notion of "local domain". They must
> publish everything certificate that is pertinent to a CA entry that they
> publish. If entries for CA1, CA4 and CA5 are present, then all
> certificates issued by these CAs must be present and all
> cross-certificates, if any, between these CAs must also be present.
> However, a cross-certificate issued by the CA 7 for the CA 1 would not
> need to be present.

	Are you saying the schema/or the DIT structure will be different
for a CA in a public directory vs a private directory?  If so, I think
we are going down a dangerous path.  Given a globally unique DN why
would you want to do this?

Dave Horvath

> 
> Denis
> 
> > I think the text in terms of saying that the forward element need not be
> > present in all cases is easy.
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [SMTP:[email-masked]]
> > > Sent: Wednesday, September 09, 1998 8:44 PM
> > > To:   Santosh Chokhani
> > > Cc:   'Sharon Boeyen'; [email-masked]'
> > > Subject:      Re: forward & reverse elements - population
> > >
> > > Santosh,
> > >
> > > Your new proposed text does not address my concern correctly.
> > >
> > > For a crossCertificatePair Attribute, either the forward element only
> > > MAY be present, or the reverse element only MAY be present, or the
> > > reverse and the forward elements may be both present.
> > >
> > > Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward
> > > element
> > > shall not be mandated to be present in a crossCertificatePair
> > > Attribute.
> > >
> > > Denis
> > >
> > > > Sharon:
> > >
> > > > I can agree to the following text for the two option instead.
> > > Please
> > > > note that I have further clarified cross-certificate by tying the DN
> > > and
> > > > public keys.
> > > >
> > > > I think the following texts are consistent with and further
> > > > clarifications of the two options.
> > > >
> > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > >
> > > > NEW PROPOSED TEXT FOR OPTION 1
> > > >
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in the
> > > same
> > > > domain as this CA.
> > > >
> > > > The forward element of the crossCertificatePair attribute, held in a
> > > > particular CA's directory entry, shall be used to store certificates
> > > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > > element of the crossCertificatePair attribute, held in a particular
> > > CA's
> > > > directory entry, may contain a subset of certificates issued by this
> > > CA
> > > > to other CAs.  When both the forward and the reverse elements are
> > > > present, issuer name in one certificate shall match the subject name
> > > in
> > > > the other and vice versa, and the subject public key in one
> > > certificate
> > > > shall be capable of verifying the digital signature on the other
> > > > certificate and vice versa.
> > > >
> > > > In the case of V3 certificates, none of the above CA certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to FALSE.
> > > >
> > > > The definition of domain is purely a matter of local policy.
> > > >
> > > > NEW PROPOSED TEXT FOR OPTION 2
> > > >
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in the
> > > same
> > > > domain as this CA.
> > > >
> > > > The forward element of the crossCertificatePair attribute, held in a
> > > > particular CA's directory entry, shall be used to store all
> > > certificates
> > > > issued to this CA.  Optionally, the reverse element of the
> > > > crossCertificatePair attribute, held in a particular CA's directory
> > > > entry, may contain a subset of certificates issued by this CA to
> > > other
> > > > CAs.  When both the forward and the reverse elements are present,
> > > issuer
> > > > name in one certificate shall match the subject name in the other
> > > and
> > > > vice versa, and the subject public key in one certificate shall be
> > > > capable of verifying the digital signature on the other certificate
> > > and
> > > > vice versa.
> > > >
> > > > In the case of V3 certificates, none of the above CA certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to FALSE.
> > > >
> > > > The definition of domain is purely a matter of local policy.
> > > >
> > > > > -----Original Message-----
> > > > > From: Sharon Boeyen [SMTP:[email-masked]]
> > > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > > To:   [email-masked]'; 'Santosh Chokhani'
> > > > > Subject:      RE: forward & reverse elements - population
> > > > >
> > > > >
> > > > >
> > > > > > ----------
> > > > > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > > > > Sent:       September 8, 1998 10:05 AM
> > > > > > To:         'Sharon Boeyen'; [email-masked]'
> > > > > > Subject:    RE: forward & reverse elements - population
> > > > > >
> > > > >       --stuff deleted
> > > > > > >
> > > > > >     []  I agree.  I do not have problem with the following
> > > language.
> > > > > > " A certificate issued to a CA by another shall be stored either
> > > in
> > > > > the
> > > > > > caCertificate or forward component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the subject CA.  Optionally, a subset of certificates issued by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA."
> > > > > >
> > > > > >     Please note that to me subset includes none, some, or all.
> > > If
> > > > > > folks want further clarification, it is ok by me.
> > > > > >
> > > > > Santosh, the only issue I have with this text is that (at least
> > > with
> > > > > the
> > > > > rationale behind option 2) any cert that appears in the
> > > cACertificate
> > > > > attribute of a given CA
> > > > > entry, should also appear in the crossCertificatePair attribute in
> > > the
> > > > > same
> > > > > CA entry.
> > > > >  What about deleting the reference to the cACertificate attribute
> > > from
> > > > > your
> > > > > text and proposing this as new text just for the
> > > crossCertificatePair
> > > > > attribute?
> > > > >
> > > > > Both Jan and David have indicated reasons to keep the "pair"
> > > together
> > > > > in the
> > > > > mutual case, so we should also consider adding the last paragraph
> > > of
> > > > > the
> > > > > text David proposed for that.
> > > > >
> > > > > Here's what the resulting text proposal would look like:
> > > > >
> > > > > > " A certificate issued to a CA by another shall be stored in the
> > > > > > forward component of crossCertificatePair attribute of
> > > > > > the subject CA.  Optionally, a subset of certificates issued by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA. When both elements are present in the same
> > > value,
> > > > > the
> > > > > > value shall represent a mutual cross-certification of the two
> > > CAs. "
> > > > > >
> > > > > If we can come to consensus on that attribute, then let's see what
> > > we
> > > > > can do
> > > > > with the cACertificate attribute text.
> > > > >
> > > > > I agree with your view on what a subset is and I think that same
> > > > > definition
> > > > > would apply to the contents of the cACertificate attribute as a
> > > subset
> > > > > of
> > > > > the crossCertificatePair forward elements in option 2.
> > >
> > > --
> > >       Denis Pinkas     Bull S.A.          mailto:[email-masked]
> > >       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
> > >       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> 
> --
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Fri, 11 Sep 1998 16:44:21 +0200
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

This is really fascinating.

When I read the proposal for a new extension I said to my self:
Good this man i brave. I wonder how many seconds he will live before he is
gunned down.
Not because the idea is stupid. Just because of the obvious "quagmire"
syndrome.

I have recently studied one extensive trial to specify such extensions and
I just want to join to the consensus here. 

- This is a quagmire and not suited for standardization (at least not
within PKIX).
- The policy OID solves the problem as far needed.

And according to changing CPS:es. One CPS may change many times as long as it
reflects the same policy. If security drops below policy requirements then
a new
policy OID has to be identified. So minimum security level is defined by
policy 
and not by CPS.

/Stefan

At 01:48 PM 9/10/98 -0400, Phillip M Hallam-Baker wrote:
>
>> If we have standard identifiers, one byte each, provides 0 to 255 
>> specific categories, with say, ten as internet standards.
>> 
>> With initial authentication method, maybe we start with (decimal):
>>     0 as anonymous, 
>>     1 as self-authenticated, 
>>     2 as driver license or government ID card
>>     3 as passport
>>     4 as military
>
>This is heading straight into the quagmire I spoke about...
>
>Decimal numbers is just about the worst approach since it means that 
>a central registry has to be kept - yet another task for IANA! and
>the arbitrary limit of 255 sounds guaranteed to ensure that the
>namespace will quickly become cluttered with ad hoc private 
>definitions being used on an 'experimental' basis.
>
>I don't see any value in the taxonomy presented. What is a 'military'
>identification method? Is identification by the US army equivalent to
>that of the Taleban in Afghanistan?
>
>The drivers license is particularly dubious. My UK drivers license
>has no photograph and is valid until sometime after 2020.
>
>Are there CAs who actually want to specify their exact authorization 
>processes? Are such processes objectively definable? A commercial
>CA does not define authorization procedures for every concievable
>document they might accept in their CPS. The first time a US CA
>decides on acceptable forms of authentication for a Monaco 
>corporation is likely to be when they get a purchase request.
>
>
>If you want to take the matter further I suggest you write an
>Internet Draft and see if the working group chairs want to 
>make it a work item.
>
>		Phill
>
>

Date: Fri, 11 Sep 1998 11:23:10 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Santosh Chokhani <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: forward & reverse elements - population
Sender: [email-masked]

Santosh,

Here is my answer to your question.

> Denis:

> I agree with you.  Clarification of the text is easy.  

???

> However, I have a
> question.  Must a certificate issued to a CA appear in the forward
> element, caCertificate or can it be missing altogether?

"MUST" is the wrong verb. A certificate issued by another CA is not
mandated to be present at all. It MAY be present. 

Let me now re-phrase your question: May a certificate issued to a CA by
another CA appear in the forward element, caCertificate or can it be
missing altogether?

My answer is the following: It may only appear in the forward element of
a crossCertificatePair.

I was quite happy (and still am I !) with the original text. I still
wonder with the rational of the two buckets.

Up to now, none of the arguments about the notion of "local domain" has
proven to be non-controversy. If the notion of local domain is important
(I still wonder about it), there might be a different way to look at the
issue. LDAPv2 allows to query any server that offers that interface, so
different set of queries could be considered:

  1) Queries made to one or more local domain servers,
  2) Queries made to one or more public domain servers.

As the name indicates it, local domain servers may not be publicly
accessible, e.g. protected by firewalls or some other access control
methods. Local domain servers would publish only what is relevant for
their notion of local domain. They must publish everything that is
relevant. 

Public domain servers would have no notion of "local domain". They must
publish everything certificate that is pertinent to a CA entry that they
publish. If entries for CA1, CA4 and CA5 are present, then all
certificates issued by these CAs must be present and all
cross-certificates, if any, between these CAs must also be present.
However, a cross-certificate issued by the CA 7 for the CA 1 would not
need to be present.

Denis
 
> I think the text in terms of saying that the forward element need not be
> present in all cases is easy.
> 
> > -----Original Message-----
> > From: Denis Pinkas [SMTP:[email-masked]]
> > Sent: Wednesday, September 09, 1998 8:44 PM
> > To:   Santosh Chokhani
> > Cc:   'Sharon Boeyen'; [email-masked]'
> > Subject:      Re: forward & reverse elements - population
> >
> > Santosh,
> >
> > Your new proposed text does not address my concern correctly.
> >
> > For a crossCertificatePair Attribute, either the forward element only
> > MAY be present, or the reverse element only MAY be present, or the
> > reverse and the forward elements may be both present.
> >
> > Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward
> > element
> > shall not be mandated to be present in a crossCertificatePair
> > Attribute.
> >
> > Denis
> >
> > > Sharon:
> >
> > > I can agree to the following text for the two option instead.
> > Please
> > > note that I have further clarified cross-certificate by tying the DN
> > and
> > > public keys.
> > >
> > > I think the following texts are consistent with and further
> > > clarifications of the two options.
> > >
> > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > >
> > > NEW PROPOSED TEXT FOR OPTION 1
> > >
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > >
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store certificates
> > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > element of the crossCertificatePair attribute, held in a particular
> > CA's
> > > directory entry, may contain a subset of certificates issued by this
> > CA
> > > to other CAs.  When both the forward and the reverse elements are
> > > present, issuer name in one certificate shall match the subject name
> > in
> > > the other and vice versa, and the subject public key in one
> > certificate
> > > shall be capable of verifying the digital signature on the other
> > > certificate and vice versa.
> > >
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > >
> > > The definition of domain is purely a matter of local policy.
> > >
> > > NEW PROPOSED TEXT FOR OPTION 2
> > >
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > >
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store all
> > certificates
> > > issued to this CA.  Optionally, the reverse element of the
> > > crossCertificatePair attribute, held in a particular CA's directory
> > > entry, may contain a subset of certificates issued by this CA to
> > other
> > > CAs.  When both the forward and the reverse elements are present,
> > issuer
> > > name in one certificate shall match the subject name in the other
> > and
> > > vice versa, and the subject public key in one certificate shall be
> > > capable of verifying the digital signature on the other certificate
> > and
> > > vice versa.
> > >
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > >
> > > The definition of domain is purely a matter of local policy.
> > >
> > > > -----Original Message-----
> > > > From: Sharon Boeyen [SMTP:[email-masked]]
> > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > To:   [email-masked]'; 'Santosh Chokhani'
> > > > Subject:      RE: forward & reverse elements - population
> > > >
> > > >
> > > >
> > > > > ----------
> > > > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > > > Sent:       September 8, 1998 10:05 AM
> > > > > To:         'Sharon Boeyen'; [email-masked]'
> > > > > Subject:    RE: forward & reverse elements - population
> > > > >
> > > >       --stuff deleted
> > > > > >
> > > > >     []  I agree.  I do not have problem with the following
> > language.
> > > > > " A certificate issued to a CA by another shall be stored either
> > in
> > > > the
> > > > > caCertificate or forward component of crossCertificatePair
> > attribute
> > > > of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA."
> > > > >
> > > > >     Please note that to me subset includes none, some, or all.
> > If
> > > > > folks want further clarification, it is ok by me.
> > > > >
> > > > Santosh, the only issue I have with this text is that (at least
> > with
> > > > the
> > > > rationale behind option 2) any cert that appears in the
> > cACertificate
> > > > attribute of a given CA
> > > > entry, should also appear in the crossCertificatePair attribute in
> > the
> > > > same
> > > > CA entry.
> > > >  What about deleting the reference to the cACertificate attribute
> > from
> > > > your
> > > > text and proposing this as new text just for the
> > crossCertificatePair
> > > > attribute?
> > > >
> > > > Both Jan and David have indicated reasons to keep the "pair"
> > together
> > > > in the
> > > > mutual case, so we should also consider adding the last paragraph
> > of
> > > > the
> > > > text David proposed for that.
> > > >
> > > > Here's what the resulting text proposal would look like:
> > > >
> > > > > " A certificate issued to a CA by another shall be stored in the
> > > > > forward component of crossCertificatePair attribute of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA. When both elements are present in the same
> > value,
> > > > the
> > > > > value shall represent a mutual cross-certification of the two
> > CAs. "
> > > > >
> > > > If we can come to consensus on that attribute, then let's see what
> > we
> > > > can do
> > > > with the cACertificate attribute text.
> > > >
> > > > I agree with your view on what a subset is and I think that same
> > > > definition
> > > > would apply to the contents of the cACertificate attribute as a
> > subset
> > > > of
> > > > the crossCertificatePair forward elements in option 2.
> >
> > --
> >       Denis Pinkas     Bull S.A.          mailto:[email-masked]
> >       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
> >       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Graham Bland <[email-masked]>
Date: Fri, 11 Sep 1998 8:49:49 +0000
To: [email-masked]
Subject: RE: RE: New Extension Proposed: Method O
Sender: [email-masked]

I think this is impossible to achieve for the following reasons

1. 255 categories would be far too few, in practice they would expand to 
thousands.

2. With each category there are wide variations, drivers licences for example 
contain different details, have different validity periods, some have photos, 
some don't and they are issued by Governments (some of whom I would not 
trust). Are photocopies acceptable? Must the driving licence be presented in 
person or can it be posted? Need it be current?  All these have a substantial 
bearing on the degree of trust I can place in a certificate.

3. It would take us years to agree on the categories and the meanings

For these reasons this could not replace a CPS.

Graham Bland

> -----Original Message-----
> From: [email-masked]
> Sent: 10 September 1998 18:06
> To: Ian Roberts; Graham Bland; Chris Wright; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: RE: New Extension Proposed: Method O
>
>
> --------------------------------------------------------------
> --------------
> Maybe "new" extension is too strong a phrase.  How about
> defining the policy
> qulifiers to have some standard" meanings, then:
>
>    reliance limit
>    licensure, licensing body
>    authentication method
>    etc.
>
> If we have standard identifiers, one byte each, provides 0 to
> 255 specific
> categories, with say, ten as internet standards.
>
> With initial authentication method, maybe we start with (decimal):
>     0 as anonymous,
>     1 as self-authenticated,
>     2 as driver license or government ID card
>     3 as passport
>     4 as military
>
> then start with combinations including common attributes,
> such as credit
> bureau rating as of issuance, etc.
>
> I do understand that, while policy OIDs may be supported some largely
> deployed systems do not support the policy qualifiers, but
> the standards do,
> so why don't we use them to improve our automation needs.
> Any time we need
> to rely on individ
> uals obtaining, reading and being held accountable to a two
> hundred page
> contract (CPS), we limit its usability.
>
> Having standard definitions for the most common usages and
> having these
> signed as part of the cert by the issuer should facilitate
> automatic policy
> acceptance across those domains with multiple policies (if I
> have accepted
> all of the Verisig
> n roots, then all of the categories of authentication are
> accepted.  If each
> cert has the main characteristics of trust (initial authentication, CA
> licensure, reliance liits, CPS location/OID, etc.), then I
> should be able to
> set my acceptanc
> e on user selected criteria,
> without re-reading the two hundred pages of each of the CAs
> my company does
> business with.
>
> Michael
>
> >>> Santosh Chokhani <[email-masked]> 09/09 1:25 PM >>>
> The certificate policy is supposed to the represented in the
> certificate
> as an object identifier.  The amendment to X.509 defines how the
> applications process that field to determine if a certificate is
> acceptable, including certificate policy and associated authentication
> mechanism.
>
> X.509 amendment offer a rich set of capabilities in this area in terms
> of what goes in a certificate, and how applications perform path
> validation.
>
> > -----Original Message-----
> > From: Tony Bartoletti [SMTP:[email-masked]]
> > Sent: Wednesday, September 09, 1998 3:12 PM
> > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: New Extension Proposed: Method Of Authentication
> >
> > At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
> > >The subscriber authentication at the various stages (such
> as initial
> > >registration, registration after revocation, revocation request,
> > normal
> > >rekey, etc.) is supposed to be described in the certificate policy.
> > >Thus, the certificate policy asserted points to the authentication
> > >method.
> >
> > True, but this certainly places a limit upon the degree of
> automation
> > that can be employed in the future, at least until we have software
> > that can read a CPS and base decisions upon it.  No time soon.
> >
> > Granted, some 20 bits describing authentication method(s) would be
> > contentious, but the very exercise would reveal much about where and
> > how trust is really anchored, and the degree to which
> automated agents
> > could evolve.
> >
> > >There is NO need for another extension.
> >
> > Have enough work already? ;)
> >
> > ___tony___
> >
> > >> -----Original Message-----
> > >> From: Phillip M Hallam-Baker [SMTP:[email-masked]]
> > >> Sent: Wednesday, September 09, 1998 1:16 PM
> > >> To: Mike Smith; [email-masked]; [email-masked]
> > >> Cc: [email-masked]
> > >> Subject: RE: New Extension Proposed: Method Of Authentication
> > >>
> > >> > In using certificates, it is useful to know what form of
> > >> > authentication is used by a CA to identify a new certificate
> > >> > requester.  A certificate extension seems the best
> place to store
> >
> > >> > this information.
> > >>
> > >> This sounds to me like a trip into a quagmire. I don't think that
> > >> it is possible to charaterize authentication mechanisms usefully
> > >> in a set of binary flags.
> > >>
> > >> For example two CAs may be requiring presentation of a driving
> > >> license for authentication, only one CA may be using a state of
> > >> MA license with photo ID and another a UK driving license without
> > >> photo ID.
> > >>
> > >> Even with documents such as passports there is considerable
> > >> variation between countries in the strictness of their
> proceedures.
> > >>
> > >> Then there are proceedural variations, is the applicant present
> > >> in person or were the credentials merely faxed...
> > >>
> > >>
> > >> Nor is the mechanism of authentication by itself particularly
> > >> usefull unless there is an evaluation of the reliability of the
> > >> party performing it.
> > >>
> > >> Of course one can start to characterise these characteristics
> > >> as well but to do so merely throws up yet more information which
> > >> might be relevant, factors which become increasingly subjective.
> > >>
> > >>
> > >> This is a hard AI problem - establishing a shared vocabulary of
> > >> terms which permits exchange of concepts whose semantics are
> > >> not embedded in the communication mechanism or indeed any
> > >> mechanism for which a formal description is available.
> > >>
> > >>   Phill
> > >
> > >
> >
> > 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: 510-422-3881             LLLLLLLL
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

From: "Fillingham,  David W." <[email-masked]>
To: "'Mike Smith'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 15:21:09 -0400
Sender: [email-masked]

I agree with Phillip.

My folder containing the debate on the meaning of the non-repudiation
key usage bit contains 97 messages from people trying to define what
that one bit is supposed to mean.  Trying to convey security policies
via a similar method strikes me as doomed from the start.

Dave Fillingham

>----------
>From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent: 	Thursday, September 10, 1998 1:48 PM
>To: 	Mike Smith; [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Cc: 	[email-masked]
>Subject: 	RE: RE: New Extension Proposed: Method Of Authentication
>
>
>> If we have standard identifiers, one byte each, provides 0 to 255 
>> specific categories, with say, ten as internet standards.
>> 
>> With initial authentication method, maybe we start with (decimal):
>>     0 as anonymous, 
>>     1 as self-authenticated, 
>>     2 as driver license or government ID card
>>     3 as passport
>>     4 as military
>
>This is heading straight into the quagmire I spoke about...
>
>Decimal numbers is just about the worst approach since it means that 
>a central registry has to be kept - yet another task for IANA! and
>the arbitrary limit of 255 sounds guaranteed to ensure that the
>namespace will quickly become cluttered with ad hoc private 
>definitions being used on an 'experimental' basis.
>
>I don't see any value in the taxonomy presented. What is a 'military'
>identification method? Is identification by the US army equivalent to
>that of the Taleban in Afghanistan?
>
>The drivers license is particularly dubious. My UK drivers license
>has no photograph and is valid until sometime after 2020.
>
>Are there CAs who actually want to specify their exact authorization 
>processes? Are such processes objectively definable? A commercial
>CA does not define authorization procedures for every concievable
>document they might accept in their CPS. The first time a US CA
>decides on acceptable forms of authentication for a Monaco 
>corporation is likely to be when they get a purchase request.
>
>
>If you want to take the matter further I suggest you write an
>Internet Draft and see if the working group chairs want to 
>make it a work item.
>
>		Phill
>

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 13:48:20 -0400
Importance: Normal
Sender: [email-masked]

> If we have standard identifiers, one byte each, provides 0 to 255 
> specific categories, with say, ten as internet standards.
> 
> With initial authentication method, maybe we start with (decimal):
>     0 as anonymous, 
>     1 as self-authenticated, 
>     2 as driver license or government ID card
>     3 as passport
>     4 as military

This is heading straight into the quagmire I spoke about...

Decimal numbers is just about the worst approach since it means that 
a central registry has to be kept - yet another task for IANA! and
the arbitrary limit of 255 sounds guaranteed to ensure that the
namespace will quickly become cluttered with ad hoc private 
definitions being used on an 'experimental' basis.

I don't see any value in the taxonomy presented. What is a 'military'
identification method? Is identification by the US army equivalent to
that of the Taleban in Afghanistan?

The drivers license is particularly dubious. My UK drivers license
has no photograph and is valid until sometime after 2020.

Are there CAs who actually want to specify their exact authorization 
processes? Are such processes objectively definable? A commercial
CA does not define authorization procedures for every concievable
document they might accept in their CPS. The first time a US CA
decides on acceptable forms of authentication for a Monaco 
corporation is likely to be when they get a purchase request.

If you want to take the matter further I suggest you write an
Internet Draft and see if the working group chairs want to 
make it a work item.

		Phill

Date: Thu, 10 Sep 1998 09:59:21 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Maybe "new" extension is too strong a phrase.  How about defining the policy qulifiers to have some standard" meanings, then:

   reliance limit
   licensure, licensing body
   authentication method
   etc.

If we have standard identifiers, one byte each, provides 0 to 255 specific categories, with say, ten as internet standards.

With initial authentication method, maybe we start with (decimal):
    0 as anonymous, 
    1 as self-authenticated, 
    2 as driver license or government ID card
    3 as passport
    4 as military

then start with combinations including common attributes, such as credit bureau rating as of issuance, etc.

I do understand that, while policy OIDs may be supported some largely deployed systems do not support the policy qualifiers, but the standards do, so why don't we use them to improve our automation needs.  Any time we need to rely on individuals obtaining, reading and being held accountable to a two hundred page contract (CPS), we limit its usability.

Having standard definitions for the most common usages and having these signed as part of the cert by the issuer should facilitate automatic policy acceptance across those domains with multiple policies (if I have accepted all of the Verisign roots, then all of the categories of authentication are accepted.  If each cert has the main characteristics of trust (initial authentication, CA licensure, reliance liits, CPS location/OID, etc.), then I should be able to set my acceptance on user selected criteria, without re-reading the two hundred pages of each of the CAs my company does business with.

Michael

>>> Santosh Chokhani <[email-masked]> 09/09 1:25 PM >>>
The certificate policy is supposed to the represented in the certificate
as an object identifier.  The amendment to X.509 defines how the
applications process that field to determine if a certificate is
acceptable, including certificate policy and associated authentication
mechanism.

X.509 amendment offer a rich set of capabilities in this area in terms
of what goes in a certificate, and how applications perform path
validation.

> -----Original Message-----
> From: Tony Bartoletti [SMTP:[email-masked]] 
> Sent: Wednesday, September 09, 1998 3:12 PM
> To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [email-masked]; [email-masked] 
> Cc: [email-masked] 
> Subject: RE: New Extension Proposed: Method Of Authentication
> 
> At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
> >The subscriber authentication at the various stages (such as initial
> >registration, registration after revocation, revocation request,
> normal
> >rekey, etc.) is supposed to be described in the certificate policy.
> >Thus, the certificate policy asserted points to the authentication
> >method.
> 
> True, but this certainly places a limit upon the degree of automation
> that can be employed in the future, at least until we have software
> that can read a CPS and base decisions upon it.  No time soon.
> 
> Granted, some 20 bits describing authentication method(s) would be
> contentious, but the very exercise would reveal much about where and
> how trust is really anchored, and the degree to which automated agents
> could evolve.
> 
> >There is NO need for another extension.
> 
> Have enough work already? ;)
> 
> ___tony___
> 
> >> -----Original Message-----
> >> From: Phillip M Hallam-Baker [SMTP:[email-masked]] 
> >> Sent: Wednesday, September 09, 1998 1:16 PM
> >> To: Mike Smith; [email-masked]; [email-masked] 
> >> Cc: [email-masked] 
> >> Subject: RE: New Extension Proposed: Method Of Authentication
> >> 
> >> > In using certificates, it is useful to know what form of 
> >> > authentication is used by a CA to identify a new certificate 
> >> > requester.  A certificate extension seems the best place to store
> 
> >> > this information.
> >> 
> >> This sounds to me like a trip into a quagmire. I don't think that
> >> it is possible to charaterize authentication mechanisms usefully
> >> in a set of binary flags.
> >> 
> >> For example two CAs may be requiring presentation of a driving
> >> license for authentication, only one CA may be using a state of
> >> MA license with photo ID and another a UK driving license without
> >> photo ID.
> >> 
> >> Even with documents such as passports there is considerable 
> >> variation between countries in the strictness of their proceedures.
> >> 
> >> Then there are proceedural variations, is the applicant present
> >> in person or were the credentials merely faxed...
> >> 
> >> 
> >> Nor is the mechanism of authentication by itself particularly 
> >> usefull unless there is an evaluation of the reliability of the
> >> party performing it. 
> >> 
> >> Of course one can start to characterise these characteristics
> >> as well but to do so merely throws up yet more information which
> >> might be relevant, factors which become increasingly subjective.
> >> 
> >> 
> >> This is a hard AI problem - establishing a shared vocabulary of
> >> terms which permits exchange of concepts whose semantics are
> >> not embedded in the communication mechanism or indeed any 
> >> mechanism for which a formal description is available.
> >> 
> >>   Phill
> >
> >
> 
> 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: 510-422-3881             LLLLLLLL

Date: Thu, 10 Sep 1998 08:49:00 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
Sender: [email-masked]

This draft may interest people in the PKIX group. It is also available from
<http://www.imc.org/draft-ietf-ipsec-pki-req>.

--Paul Hoffman, Director
--Internet Mail Consortium

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
>Date: Thu, 10 Sep 1998 10:34:19 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the IP Security Protocol Working Group of the
IETF.
>
>	Title		: PKI Requirements for IP Security
>	Author(s)	: R. Thayer
>	Filename	: draft-ietf-ipsec-pki-req-00.txt
>	Pages		: 22
>	Date		: 09-Sep-98
>	
>          The IP Security (IPSec) protocol set now being defined in the
>          IETF uses public key cryptography for authentication in it's key
>          management protocol.  This document defines the requirements that
>          IPSec has for Public Key Infrastructure (PKI) protocols, formats,
>          and services.
> 
>          The key words 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and
>          'MAY' in this document are to be interpreted as described in RFC
>          2119.
> 
>          Please send comments on this document to the [email-masked]
>          mailing list.
>
>Internet-Drafts are 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-ipsec-pki-req-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-00.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nis.garr.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[email-masked].  In the body type:
>	"FILE /internet-drafts/draft-ietf-ipsec-pki-req-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.
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ipsec-pki-req-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-00.txt>
> 

From: Eric Murray <[email-masked]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [email-masked] (Paul Koning)
Date: Thu, 10 Sep 1998 08:19:49 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Paul Koning writes:
 
> 
> Incidentally, as an aside -- this discussion made me worry about the
> potential for unrestrained growth of certificates.  As someone
> involved in building diskless (embedded) systems, megabyte-sized certs 
> worry me a lot.

Me too.  Our company also does embedded systems which need to
accept and verify certs.
Please keep your certs small if you really want
them to be ubiquitous.  I'd much rather see a URI and perhaps
a hash in the cert instead of the entire CPS.

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

Date: Thu, 10 Sep 1998 09:21:30 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

>>>>> "Tony" == Tony Bartoletti <[email-masked]> writes:
>...
 Tony> Still, suppose the certificate did contain the CPS hash.
 Tony> Imagine that a client system, in the course of validating
 Tony> certificates, determines that a particular CPS has changed.
 Tony> That is, some of the certs point to the older CPS, and some to
 Tony> a brand new CPS.  Assume further that it can (securely)
 Tony> retrieve both the older and newer CPS at will.  It can still
 Tony> validate the older certs, but it can do nothing with the newer
 Tony> ones until a human steps in to read the new CPS, and then
 Tony> determine its sufficiency for the purpose(s) at hand.

 Tony> In terms of automation, "the bits stop here."

I think that's as it should be.  Whether a new CPS is sufficient for
the purposes at hand, in any situation where someone cares enough to
look at the CPS at all, is a question that undoubtedly involves
lawyers, or even people involved in still less formal processes.

Until and unless someone comes up with a mapping from legal english to 
formal logic (unlikely given Goedel's theorem) I believe the bits HAVE 
to stop where you said.

Incidentally, as an aside -- this discussion made me worry about the
potential for unrestrained growth of certificates.  As someone
involved in building diskless (embedded) systems, megabyte-sized certs 
worry me a lot.

	paul

From: "Shailesh" <[email-masked]>
To: <[email-masked]>
Subject: PKIX transports using HTTP
Date: Thu, 10 Sep 1998 18:38:54 +0530
Sender: [email-masked]

1. What is more standard way of communicating PKIX
messages on HTTP : 

Put them as a part of URL
OR Put them in the "Entity (optional) part of the request and response"

2. What extensions of the HTTP or part of the core protocol
talks about polling? How does one poll using HTTP?

Thanks with best regards

Shailesh

Date: Thu, 10 Sep 1998 14:53:26 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Eric Murray <[email-masked]>
CC: [email-masked]
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Eric Murray wrote:
 
> Santosh Chokhani writes:

> > The subscriber authentication at the various stages (such as initial
> > registration, registration after revocation, revocation request, normal
> > rekey, etc.) is supposed to be described in the certificate policy.
> > Thus, the certificate policy asserted points to the authentication
> > method.

> > There is NO need for another extension.
 
> I agree that putting the policy into an extension is a quagmire.
 
> However, given that most CPSs will be on web sites, and those
> CPSs can be changed at any time, should there be a way to
> indicate which CPS is in effect at any given time during
> the certificate's life?
 
> Say Fred is issued a cert by Carl the CA.  Carl signs Fred's
> cert under the then-current CPS 1.2, which required Carl
> to verify Fred's identity using dental charts.   Sometime
> later, Carl changes his CPS to version 1.3, which no longer requires
> dental charts as a form of identification, but instead
> accepts a state driver's license.
 
> Fred would like to sign a contract to purchase a house.  The lender
> requires a high-quality signature, and a cert with only a state
> driver's license as identification isn't good enough.  How does Fred
> indicate that his cert was issued under the older, more rigorous CPS?

You are adressing an important issue. When you sign a contract, you
usually look at the back of the page where there is either the full
terms of the contract or a short form of them with a pointer to a full
form. It is thus important to know whether you agree or not with these:
if yes, you sign, if not you don't. 

The equivalent in electronic terms is to point to a security policy and
sign it (i.e. add the security policy to the core of the signed message
and sign the whole). Different pointers may be used. Here are two
examples: an OID, a URL address. If the policy changes, the pointer must
change. A hash of the policy has to be used to make sure which terms you
were agreeing with. 

These terms will indicate which CAs are adequate to be used by the
signers and which security policies from that CA will be adequate to be
used, relative to these terms.

> One way to deal with this is to revoke all certs issued under a
> given CPS when it is changed.  I'm not sure that that provides any assurance
> that a given cert was issued under the current CPS though- a receiving
> party would have to depend on the current CPS stating that such
> is the policy.  And it's obviously very undesireable from a CA standpoint.

Indeed !

> Another way would be to require the CA to sign their CPSs and include
> version numbers, and to include in the cert extension which points to
> the CPS, the version number of the CPS which was in effect when the cert
> was issued.  This will prevent CAs from updating CPSs "out from
> underneath" existing certs.  That may or may not be a desired effect.

:-(

> I did a very quick read of the draft and didn't see anything that
> handles this problem.  But I have not been following the discussion very
> much and have not studied the draft, so I could well have missed it.  If
> there's already something in the draft to deal with this, or this
> subject has already been discussed on the list, please accept my
> apologies.

You did not missed it, the draft is silent on this kind of topic, but it
would not be the right place anyway to place it. At the Chicago meeting,
we talked about expanding the work to handle non repudiation in more
details. If such an extension of the work happens, then we could
possibly deal with this kind of topic.

Denis
 
> --
> Eric Murray          N*Able Technologies                    www.nabletech.com
> (email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Thu, 10 Sep 1998 14:25:40 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Mike Smith <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Mike Smith wrote:
> 
> In using certificates, it is useful to know what form of 
> authentication is used by a CA to identify a new certificate 
> requester.  A certificate extension seems the best place to store 
> this information.
> 
> At one time, Bob Jeuneman prepared a paper proposing this extension 
> and detailing many categories, from anonymous, self-authenticated, 
> self authenticated with data verifired (or with credit account, etc.),
> authenticated in person, in person with governement-issued picture ID, 
> multiple forms of government picture IDs with current credit reports 
> and corporate D&B, etc.
 
> The current practice, I beleive, is to embed the authentication 
> mechanism in a CA operations or policy statement tha may or may not 
> be online for someone to peruse and make their own judgement.  
> Putting a clear indicator in the signed cert would help.
 
> Comments?  Bob?

If we were going in that direction then we might need to indicate
whether one or more of the following has been presented: a driving
license, a passport, an ID card, a bill from an Electricity supplier, a
bill from a Telephone company, a bill from a Water supplier, etc ... We
already have (too) many extensions. The policy statement is enough.
There is no need for a verifier to understand the details of the policy,
but only to know whether the policy is acceptable for the application. 

Denis
 
> Michael
-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Abhay Kulkarni" <[email-masked]>
To: <[email-masked]>
Subject: PKIX Certificate Management Protocols
Date: Thu, 10 Sep 1998 17:54:53 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01BDDCE4.1D99E100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello everybody,
Where do we find extra information about how to use HTTP protocol as the =
lower layer in the PKI certificate management protocol ?
Thanks in advance.
Regards.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Abhay Kulkarni
Systems Engineer
Frontier Computers Pvt. Ltd.
EMail:  [email-masked]
Web: http://www.fcpl.co.in
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

------=_NextPart_000_0028_01BDDCE4.1D99E100
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.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT color=3D#000000 size=3D2>Hello everybody,</FONT></DIV>
<DIV><FONT size=3D2>Where do we find extra information about how to use =
HTTP=20
protocol as the lower layer in the PKI certificate management protocol=20
?</FONT></DIV>
<DIV><FONT size=3D2>Thanks in advance.</FONT></DIV>
<DIV><FONT size=3D2>Regards.</FONT></DIV>
<DIV><FONT color=3D#000000 =
size=3D2>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<BR>Abhay=20
Kulkarni<BR>Systems Engineer<BR>Frontier Computers Pvt. =
Ltd.<BR>EMail:&nbsp; <A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR>Web: <A=20
href=3D"http://www.fcpl.co.in">http://www.fcpl.co.in</A><BR>%%%%%%%%%%%%%=
%%%%%%%%%%%%%%%%%%%%%</FONT></DIV></BODY></HTML>

------=_NextPart_000_0028_01BDDCE4.1D99E100--

Date: Thu, 10 Sep 1998 08:07:16 -0400
From: William Dziadyk <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

---------------------------------------------------------------------------------
   William Dziadyk, PEng
   IT Security Services, DOMUS Software, Ottawa, Ontario, Canada 
   (613) 230-6285  ext 342  ----   [email-masked] 
 ---------------------------------------------------------------------------------

Date: Thu, 10 Sep 1998 12:27:57 +0530
From: Narayan Raghu <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Hello, 

Ultimately, it is the verifier of a certificate who decides if a
certification authority is to be trusted. Hence, the onus is on him to
verify the policies of the CA and decide whether to designate that CA as
the trusted root. 

IF a CA changes it's policy, it could simply generate another keypair,
which signes certificates verifed by the new method.  That way, the
verifier can decide whether to designate the new CA certificate as
trusted root or not, depending upon the new policy of the CA. The
verifier can thus choose to trust all those certified by the old CA
Certificate/Keypair, since the old policy was acceptable. 
The key here is that we link a new CA policy with a mandatory new CA
signing keypair.

I dont think it's required to mention the verifying method in the
certificate, since it's the certificate verifier's responsibility.

narayan 
ibm bangalore
india

Paul Hoffman / IMC wrote:
> 
> At 04:20 PM 9/9/98 -0700, Tony Bartoletti wrote:
> >There are two significant shortcomings with the existing situation,
> >nonetheless.  First, as pointed out by Eric Murray, is that this
> >"pointer to the certificate policy" is a weak link in a critical
> >chain to the foundation of trust.
> 
> Then don't validate certs with CPSs; only validate ones with OIDs that
> you
> understand.
> 
> Remember, these policies are for CAs who you have already decided you
> trust
> to sign someone else's key. If you don't trust them not to change
> their
> CPS, why do you trust that they are even following the CPS you looked
> up
> once? Any reasonable CA who changes their CPS will keep the old one at
> the
> original URL and create a new CPS with a new URL, and put the new URL
> in
> certs that conform to the new policy.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: Santosh Chokhani <[email-masked]>
To: "'Tony Bartoletti'" <[email-masked]>, Phillip M Hallam-Baker <[email-masked]>, Santosh Chokhani <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked], Eric Murray <[email-masked]>
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 20:00:00 -0400
Sender: [email-masked]

Tony:

I think certificate policies are supposed to take care of this.  Clients
need not read CP or CPS.  One may put CPS digest in an already defined
extension in the certificate.

> -----Original Message-----
> From:	Tony Bartoletti [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 7:20 PM
> To:	Phillip M Hallam-Baker; Santosh Chokhani; Mike Smith;
> [email-masked]; [email-masked]; Eric Murray
> Cc:	[email-masked]
> Subject:	RE: New Extension Proposed: Method Of Authentication
> 
> At 03:39 PM 9/9/98 -0400, Phillip M Hallam-Baker wrote:
> >
> >> The subscriber authentication at the various stages (such as
> initial
> >> registration, registration after revocation, revocation request,
> normal
> >> rekey, etc.) is supposed to be described in the certificate policy.
> >> Thus, the certificate policy asserted points to the authentication
> >> method.
> >
> >True. What I interpreted the proposal to be however was an abstract
> >syntax for describing certificate policy in a form that would allow
> >automated evaluation. There is a big difference between putting a 
> >pointer to the certificate policy into a cert and attempting to
> encode 
> >the certificate policy within the certificate itself.
> >
> >While such a facility would be 'nice to have' my experience is that
> >it is a very hard AI problem, at least as hard as the problem of
> >natural language understanding.
> 
> Phill,
> 
> I do understand, and would expect any attempt to address the stated
> shortcomings via an extension (or any other method) to be a multi-year
> effort:)
> 
> There are two significant shortcomings with the existing situation,
> nonetheless.  First, as pointed out by Eric Murray, is that this
> "pointer to the certificate policy" is a weak link in a critical
> chain to the foundation of trust.  I recall (two years ago!) this
> very subject was debated on this list, with some calls to have the
> cert contain a hash of the CPS in effect at the time of certificate
> creation, so there could be no subtle (or not so subtle) rewording
> of the CPS after the fact.  Alas, no such provisions were included.
> 
> Still, suppose the certificate did contain the CPS hash.  Imagine
> that a client system, in the course of validating certificates,
> determines that a particular CPS has changed.  That is, some of the
> certs point to the older CPS, and some to a brand new CPS.  Assume
> further that it can (securely) retrieve both the older and newer CPS
> at will.  It can still validate the older certs, but it can do nothing
> with the newer ones until a human steps in to read the new CPS, and
> then determine its sufficiency for the purpose(s) at hand.
> 
> In terms of automation, "the bits stop here."
> 
> Its just an observation...
> 
> ___tony___
> 
> >There is a project in the International Chamber of Commerce called 
> >ETerms which addresses the problem of providing a CPS repository
> >and which has as a long term goal the establishment of a shared
> >vocabulary of contract terms.
> >
> >This enterprise is best described as 'chock full o' lawyers'. Many
> >of the issues being delt with involve subtle and obscure points
> >of international law - such as the fact that the criteria for
> >establishing constructive notice vary according to the jurisdiction.
> >
> >Significantly the E-Terms project is not attempting to establish a
> >taxonomy of trade terms in common use. I don't think such a 'top
> >down' approach is feasible. Instead what is being attempted is a 
> >convergence of the user community towards the use of a common 
> >vocabulary which is itself a product of the process. This is more
> >of a bottom-up, evolutionary approach.
> >
> >		Phill
> >
> >
> >
> >
> >
> 
> 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: 510-422-3881             LLLLLLLL

Date: Wed, 09 Sep 1998 16:58:57 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

At 04:20 PM 9/9/98 -0700, Tony Bartoletti wrote:
>There are two significant shortcomings with the existing situation,
>nonetheless.  First, as pointed out by Eric Murray, is that this
>"pointer to the certificate policy" is a weak link in a critical
>chain to the foundation of trust.

Then don't validate certs with CPSs; only validate ones with OIDs that you
understand.

Remember, these policies are for CAs who you have already decided you trust
to sign someone else's key. If you don't trust them not to change their
CPS, why do you trust that they are even following the CPS you looked up
once? Any reasonable CA who changes their CPS will keep the old one at the
original URL and create a new CPS with a new URL, and put the new URL in
certs that conform to the new policy.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 09 Sep 1998 16:20:25 -0700
To: "Phillip M Hallam-Baker" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>, Eric Murray <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: <[email-masked]>
Sender: [email-masked]

At 03:39 PM 9/9/98 -0400, Phillip M Hallam-Baker wrote:
>
>> The subscriber authentication at the various stages (such as initial
>> registration, registration after revocation, revocation request, normal
>> rekey, etc.) is supposed to be described in the certificate policy.
>> Thus, the certificate policy asserted points to the authentication
>> method.
>
>True. What I interpreted the proposal to be however was an abstract
>syntax for describing certificate policy in a form that would allow
>automated evaluation. There is a big difference between putting a 
>pointer to the certificate policy into a cert and attempting to encode 
>the certificate policy within the certificate itself.
>
>While such a facility would be 'nice to have' my experience is that
>it is a very hard AI problem, at least as hard as the problem of
>natural language understanding.

Phill,

I do understand, and would expect any attempt to address the stated
shortcomings via an extension (or any other method) to be a multi-year
effort:)

There are two significant shortcomings with the existing situation,
nonetheless.  First, as pointed out by Eric Murray, is that this
"pointer to the certificate policy" is a weak link in a critical
chain to the foundation of trust.  I recall (two years ago!) this
very subject was debated on this list, with some calls to have the
cert contain a hash of the CPS in effect at the time of certificate
creation, so there could be no subtle (or not so subtle) rewording
of the CPS after the fact.  Alas, no such provisions were included.

Still, suppose the certificate did contain the CPS hash.  Imagine
that a client system, in the course of validating certificates,
determines that a particular CPS has changed.  That is, some of the
certs point to the older CPS, and some to a brand new CPS.  Assume
further that it can (securely) retrieve both the older and newer CPS
at will.  It can still validate the older certs, but it can do nothing
with the newer ones until a human steps in to read the new CPS, and
then determine its sufficiency for the purpose(s) at hand.

In terms of automation, "the bits stop here."

Its just an observation...

___tony___

>There is a project in the International Chamber of Commerce called 
>ETerms which addresses the problem of providing a CPS repository
>and which has as a long term goal the establishment of a shared
>vocabulary of contract terms.
>
>This enterprise is best described as 'chock full o' lawyers'. Many
>of the issues being delt with involve subtle and obscure points
>of international law - such as the fact that the criteria for
>establishing constructive notice vary according to the jurisdiction.
>
>Significantly the E-Terms project is not attempting to establish a
>taxonomy of trade terms in common use. I don't think such a 'top
>down' approach is feasible. Instead what is being attempted is a 
>convergence of the user community towards the use of a common 
>vocabulary which is itself a product of the process. This is more
>of a bottom-up, evolutionary approach.
>
>		Phill
>
>
>
>
>

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: 510-422-3881             LLLLLLLL

From: "Corcoran, Dan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 9 Sep 1998 17:19:49 -0400 
Sender: [email-masked]

From: "Fillingham,  David W." <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, "'Mike Smith'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Tony Bartoletti'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:44:32 -0400
Sender: [email-masked]

Tony:

I agree with Santosh and Phillip on this matter - I don't think an
additional extension would help.

The method of verifying a subscriber's identity is one element of a
certificate policy that factors in the assurance of the binding between
an identity and a public key - but only one.  It seems we could go down
a path of defining another extension for liability limits, which may be
more important to many users, and another for technical security
mechanisms (e.g., is the private key protected using hardware, or
software), and another for "authorized certificate applications" (e.g.,
only good for Company X applications) and so on.

I see no need to automatically read CPS documents - X.509 already
specifies how the certificate policy extension should be processed.  If
a policy, including the subscriber I&A process, is acceptable to a
relying party for a specific application, then the certificate
processing application can accept the certificate asserting that policy.
 Some human being reads the policy, and makes this determination, based
on the entire policy, and then asserts the policy as one that is
"acceptable" for the application.  

If a public key system implementor wants to define a certificate policy
based exclusively on the initial subscriber registration identification
mechanism, they could do so.  I don't think this would be a good idea,
but it's certainly allowed by the standards, including the IETF
Certificate Policy and CPS Framework, and to my mind, is preferable to
defining another extension.

Dave Fillingham

>----------
>From: 	Tony Bartoletti[SMTP:[email-masked]]
>Sent: 	Wednesday, September 09, 1998 3:12 PM
>To: 	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
>[email-masked]; [email-masked]
>Cc: 	[email-masked]
>Subject: 	RE: New Extension Proposed: Method Of Authentication
>
>At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
>>The subscriber authentication at the various stages (such as initial
>>registration, registration after revocation, revocation request, normal
>>rekey, etc.) is supposed to be described in the certificate policy.
>>Thus, the certificate policy asserted points to the authentication
>>method.
>
>True, but this certainly places a limit upon the degree of automation
>that can be employed in the future, at least until we have software
>that can read a CPS and base decisions upon it.  No time soon.
>
>Granted, some 20 bits describing authentication method(s) would be
>contentious, but the very exercise would reveal much about where and
>how trust is really anchored, and the degree to which automated agents
>could evolve.
>
>>There is NO need for another extension.
>
>Have enough work already? ;)
>
>___tony___
>
>>> -----Original Message-----
>>> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
>>> Sent:	Wednesday, September 09, 1998 1:16 PM
>>> To:	Mike Smith; [email-masked]; [email-masked]
>>> Cc:	[email-masked]
>>> Subject:	RE: New Extension Proposed: Method Of Authentication
>>> 
>>> > In using certificates, it is useful to know what form of 
>>> > authentication is used by a CA to identify a new certificate 
>>> > requester.  A certificate extension seems the best place to store 
>>> > this information.
>>> 
>>> This sounds to me like a trip into a quagmire. I don't think that
>>> it is possible to charaterize authentication mechanisms usefully
>>> in a set of binary flags.
>>> 
>>> For example two CAs may be requiring presentation of a driving
>>> license for authentication, only one CA may be using a state of
>>> MA license with photo ID and another a UK driving license without
>>> photo ID.
>>> 
>>> Even with documents such as passports there is considerable 
>>> variation between countries in the strictness of their proceedures.
>>> 
>>> Then there are proceedural variations, is the applicant present
>>> in person or were the credentials merely faxed...
>>> 
>>> 
>>> Nor is the mechanism of authentication by itself particularly 
>>> usefull unless there is an evaluation of the reliability of the
>>> party performing it. 
>>> 
>>> Of course one can start to characterise these characteristics
>>> as well but to do so merely throws up yet more information which
>>> might be relevant, factors which become increasingly subjective.
>>> 
>>> 
>>> This is a hard AI problem - establishing a shared vocabulary of
>>> terms which permits exchange of concepts whose semantics are
>>> not embedded in the communication mechanism or indeed any 
>>> mechanism for which a formal description is available.
>>> 
>>> 		Phill
>>
>>
>
>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: 510-422-3881             LLLLLLLL
>

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:39:46 -0400
Importance: Normal
Sender: [email-masked]

> The subscriber authentication at the various stages (such as initial
> registration, registration after revocation, revocation request, normal
> rekey, etc.) is supposed to be described in the certificate policy.
> Thus, the certificate policy asserted points to the authentication
> method.

True. What I interpreted the proposal to be however was an abstract
syntax for describing certificate policy in a form that would allow
automated evaluation. There is a big difference between putting a 
pointer to the certificate policy into a cert and attempting to encode 
the certificate policy within the certificate itself.

While such a facility would be 'nice to have' my experience is that
it is a very hard AI problem, at least as hard as the problem of
natural language understanding.

There is a project in the International Chamber of Commerce called 
ETerms which addresses the problem of providing a CPS repository
and which has as a long term goal the establishment of a shared
vocabulary of contract terms.

This enterprise is best described as 'chock full o' lawyers'. Many
of the issues being delt with involve subtle and obscure points
of international law - such as the fact that the criteria for
establishing constructive notice vary according to the jurisdiction.

Significantly the E-Terms project is not attempting to establish a
taxonomy of trade terms in common use. I don't think such a 'top
down' approach is feasible. Instead what is being attempted is a 
convergence of the user community towards the use of a common 
vocabulary which is itself a product of the process. This is more
of a bottom-up, evolutionary approach.

		Phill

From: Santosh Chokhani <[email-masked]>
To: "'Tony Bartoletti'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:25:47 -0400
Sender: [email-masked]

The certificate policy is supposed to the represented in the certificate
as an object identifier.  The amendment to X.509 defines how the
applications process that field to determine if a certificate is
acceptable, including certificate policy and associated authentication
mechanism.

X.509 amendment offer a rich set of capabilities in this area in terms
of what goes in a certificate, and how applications perform path
validation.

> -----Original Message-----
> From:	Tony Bartoletti [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 3:12 PM
> To:	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: New Extension Proposed: Method Of Authentication
> 
> At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
> >The subscriber authentication at the various stages (such as initial
> >registration, registration after revocation, revocation request,
> normal
> >rekey, etc.) is supposed to be described in the certificate policy.
> >Thus, the certificate policy asserted points to the authentication
> >method.
> 
> True, but this certainly places a limit upon the degree of automation
> that can be employed in the future, at least until we have software
> that can read a CPS and base decisions upon it.  No time soon.
> 
> Granted, some 20 bits describing authentication method(s) would be
> contentious, but the very exercise would reveal much about where and
> how trust is really anchored, and the degree to which automated agents
> could evolve.
> 
> >There is NO need for another extension.
> 
> Have enough work already? ;)
> 
> ___tony___
> 
> >> -----Original Message-----
> >> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> >> Sent:	Wednesday, September 09, 1998 1:16 PM
> >> To:	Mike Smith; [email-masked]; [email-masked]
> >> Cc:	[email-masked]
> >> Subject:	RE: New Extension Proposed: Method Of Authentication
> >> 
> >> > In using certificates, it is useful to know what form of 
> >> > authentication is used by a CA to identify a new certificate 
> >> > requester.  A certificate extension seems the best place to store
> 
> >> > this information.
> >> 
> >> This sounds to me like a trip into a quagmire. I don't think that
> >> it is possible to charaterize authentication mechanisms usefully
> >> in a set of binary flags.
> >> 
> >> For example two CAs may be requiring presentation of a driving
> >> license for authentication, only one CA may be using a state of
> >> MA license with photo ID and another a UK driving license without
> >> photo ID.
> >> 
> >> Even with documents such as passports there is considerable 
> >> variation between countries in the strictness of their proceedures.
> >> 
> >> Then there are proceedural variations, is the applicant present
> >> in person or were the credentials merely faxed...
> >> 
> >> 
> >> Nor is the mechanism of authentication by itself particularly 
> >> usefull unless there is an evaluation of the reliability of the
> >> party performing it. 
> >> 
> >> Of course one can start to characterise these characteristics
> >> as well but to do so merely throws up yet more information which
> >> might be relevant, factors which become increasingly subjective.
> >> 
> >> 
> >> This is a hard AI problem - establishing a shared vocabulary of
> >> terms which permits exchange of concepts whose semantics are
> >> not embedded in the communication mechanism or indeed any 
> >> mechanism for which a formal description is available.
> >> 
> >> 		Phill
> >
> >
> 
> 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: 510-422-3881             LLLLLLLL

From: Eric Murray <[email-masked]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [email-masked] (Santosh Chokhani)
Date: Wed, 9 Sep 1998 12:24:18 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Santosh Chokhani writes:
> 
> The subscriber authentication at the various stages (such as initial
> registration, registration after revocation, revocation request, normal
> rekey, etc.) is supposed to be described in the certificate policy.
> Thus, the certificate policy asserted points to the authentication
> method.
> 
> There is NO need for another extension.

I agree that putting the policy into an extension is a quagmire.

However, given that most CPSs will be on web sites, and those
CPSs can be changed at any time, should there be a way to
indicate which CPS is in effect at any given time during
the certificate's life?

Say Fred is issued a cert by Carl the CA.  Carl signs Fred's
cert under the then-current CPS 1.2, which required Carl
to verify Fred's identity using dental charts.   Sometime
later, Carl changes his CPS to version 1.3, which no longer requires
dental charts as a form of identification, but instead
accepts a state driver's license.

Fred would like to sign a contract to purchase a house.  The lender
requires a high-quality signature, and a cert with only a state
driver's license as identification isn't good enough.  How does Fred
indicate that his cert was issued under the older, more rigorous CPS?

One way to deal with this is to revoke all certs issued under a
given CPS when it is changed.  I'm not sure that that provides any assurance
that a given cert was issued under the current CPS though- a receiving
party would have to depend on the current CPS stating that such
is the policy.  And it's obviously very undesireable from a CA standpoint.

Another way would be to require the CA to sign their CPSs and include
version numbers, and to include in the cert extension which points to
the CPS, the version number of the CPS which was in effect when the cert
was issued.  This will prevent CAs from updating CPSs "out from
underneath" existing certs.  That may or may not be a desired effect.

I did a very quick read of the draft and didn't see anything that
handles this problem.  But I have not been following the discussion very
much and have not studied the draft, so I could well have missed it.  If
there's already something in the draft to deal with this, or this
subject has already been discussed on the list, please accept my
apologies.

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

Date: Wed, 09 Sep 1998 12:12:19 -0700
To: Santosh Chokhani <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: [email-masked]
Sender: [email-masked]

At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
>The subscriber authentication at the various stages (such as initial
>registration, registration after revocation, revocation request, normal
>rekey, etc.) is supposed to be described in the certificate policy.
>Thus, the certificate policy asserted points to the authentication
>method.

True, but this certainly places a limit upon the degree of automation
that can be employed in the future, at least until we have software
that can read a CPS and base decisions upon it.  No time soon.

Granted, some 20 bits describing authentication method(s) would be
contentious, but the very exercise would reveal much about where and
how trust is really anchored, and the degree to which automated agents
could evolve.

>There is NO need for another extension.

Have enough work already? ;)

___tony___

>> -----Original Message-----
>> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
>> Sent:	Wednesday, September 09, 1998 1:16 PM
>> To:	Mike Smith; [email-masked]; [email-masked]
>> Cc:	[email-masked]
>> Subject:	RE: New Extension Proposed: Method Of Authentication
>> 
>> > In using certificates, it is useful to know what form of 
>> > authentication is used by a CA to identify a new certificate 
>> > requester.  A certificate extension seems the best place to store 
>> > this information.
>> 
>> This sounds to me like a trip into a quagmire. I don't think that
>> it is possible to charaterize authentication mechanisms usefully
>> in a set of binary flags.
>> 
>> For example two CAs may be requiring presentation of a driving
>> license for authentication, only one CA may be using a state of
>> MA license with photo ID and another a UK driving license without
>> photo ID.
>> 
>> Even with documents such as passports there is considerable 
>> variation between countries in the strictness of their proceedures.
>> 
>> Then there are proceedural variations, is the applicant present
>> in person or were the credentials merely faxed...
>> 
>> 
>> Nor is the mechanism of authentication by itself particularly 
>> usefull unless there is an evaluation of the reliability of the
>> party performing it. 
>> 
>> Of course one can start to characterise these characteristics
>> as well but to do so merely throws up yet more information which
>> might be relevant, factors which become increasingly subjective.
>> 
>> 
>> This is a hard AI problem - establishing a shared vocabulary of
>> terms which permits exchange of concepts whose semantics are
>> not embedded in the communication mechanism or indeed any 
>> mechanism for which a formal description is available.
>> 
>> 		Phill
>
>

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: 510-422-3881             LLLLLLLL

From: [email-masked]
To: [email-masked]
Date: Wed, 9 Sep 1998 14:51:15 -0500
Subject: For Option 2
Sender: [email-masked]

For Option 2

From: Santosh Chokhani <[email-masked]>
To: "'Kurn, David'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 14:04:50 -0400
Sender: [email-masked]

You seem to have captured the essence.

Please note that the preference could be reversed depending on the
application need and/or the environment.

You have to try a search to the end.  I do not think in graphs like this
there is an a priory way of encoding which links will lead to which
paths.  Depth first (or up to some depth) search is likely to be the PKI
path development strategy in combination with judicious use of AKID,
SKID, key usage, pathToName, and certificate policy matching rules.

> -----Original Message-----
> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 1:51 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Santosh
> 
> Hmm.... I think I see.  Perhaps the problem arises because of your use
> of
> the word domain.  Consider your 2nd and 3rd paragraph rewritten to
> omit the
> word "domain", such as:
> 
> 	The relying party will start with the assumption that the
> 	subscriber with whom it is trying to form a key management
> certificate
> 	path or digital signature certificate verification path is
> reachable
> by starting with the entries in the caCertificate Attribute.
> 
> 	If the above search fails, the
> 	relying party will continue with the assumption that the
> subscriber
> with
> 	whom it is trying to form a key management certificate path or
> digital
> 	signature certificate verification path is reachable by using
> the
> forward element of the crossCertificatePair attribute under
> 	option 1 and forward element of the (crossCertificatePair -
> 	caCertificate) under option 2 first.
> 
> 
> 
> Does this capture your intent and avoid the word "domain"?
> 
> Of course, I don't like my algorithm,  because it appears to imply a
> search
> to the end before trying the other branch.
> 
> David Kurn
> 
> 
> > -----Original Message-----
> > From:	Santosh Chokhani [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 10:32 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> [email-masked]'
> > Subject:	RE: forward & reverse elements - population
> > 
> > Let us say an application requires more communication within a
> domain.
> > 
> > Then the relying party will start with the assumption that the
> > subscriber with whom it is trying to form a key management
> certificate
> > path or digital signature certificate verification path is also in
> the
> > same domain and hence will follow the caCertificate attribute link
> > first.
> > 
> > If the application requires more communication across the domain,
> the
> > relying party will start with the assumption that the subscriber
> with
> > whom it is trying to form a key management certificate path or
> digital
> > signature certificate verification path is in another domain and
> hence
> > will use forward element of the crossCertificatePair attribute under
> > option 1 and forward element of the (crossCertificatePair -
> > caCertificate) under option 2 first.
> > 
> > If there is no bias in communication intra or inter domain, the
> relying
> > party has lost nothing and will always find a trust path, if there
> is
> > one.
> > 
> 	<SNIP>

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:50:42 -0700 
Sender: [email-masked]

Santosh

Hmm.... I think I see.  Perhaps the problem arises because of your use of
the word domain.  Consider your 2nd and 3rd paragraph rewritten to omit the
word "domain", such as:

	The relying party will start with the assumption that the
	subscriber with whom it is trying to form a key management
certificate
	path or digital signature certificate verification path is reachable
by starting with the entries in the caCertificate Attribute.

	If the above search fails, the
	relying party will continue with the assumption that the subscriber
with
	whom it is trying to form a key management certificate path or
digital
	signature certificate verification path is reachable by using the
forward element of the crossCertificatePair attribute under
	option 1 and forward element of the (crossCertificatePair -
	caCertificate) under option 2 first.

Does this capture your intent and avoid the word "domain"?

Of course, I don't like my algorithm,  because it appears to imply a search
to the end before trying the other branch.

David Kurn

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 10:32 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Let us say an application requires more communication within a domain.
> 
> Then the relying party will start with the assumption that the
> subscriber with whom it is trying to form a key management certificate
> path or digital signature certificate verification path is also in the
> same domain and hence will follow the caCertificate attribute link
> first.
> 
> If the application requires more communication across the domain, the
> relying party will start with the assumption that the subscriber with
> whom it is trying to form a key management certificate path or digital
> signature certificate verification path is in another domain and hence
> will use forward element of the crossCertificatePair attribute under
> option 1 and forward element of the (crossCertificatePair -
> caCertificate) under option 2 first.
> 
> If there is no bias in communication intra or inter domain, the relying
> party has lost nothing and will always find a trust path, if there is
> one.
> 
	<SNIP>

From: Santosh Chokhani <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:44:32 -0400
Sender: [email-masked]

The subscriber authentication at the various stages (such as initial
registration, registration after revocation, revocation request, normal
rekey, etc.) is supposed to be described in the certificate policy.
Thus, the certificate policy asserted points to the authentication
method.

There is NO need for another extension.

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 1:16 PM
> To:	Mike Smith; [email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: New Extension Proposed: Method Of Authentication
> 
> > In using certificates, it is useful to know what form of 
> > authentication is used by a CA to identify a new certificate 
> > requester.  A certificate extension seems the best place to store 
> > this information.
> 
> This sounds to me like a trip into a quagmire. I don't think that
> it is possible to charaterize authentication mechanisms usefully
> in a set of binary flags.
> 
> For example two CAs may be requiring presentation of a driving
> license for authentication, only one CA may be using a state of
> MA license with photo ID and another a UK driving license without
> photo ID.
> 
> Even with documents such as passports there is considerable 
> variation between countries in the strictness of their proceedures.
> 
> Then there are proceedural variations, is the applicant present
> in person or were the credentials merely faxed...
> 
> 
> Nor is the mechanism of authentication by itself particularly 
> usefull unless there is an evaluation of the reliability of the
> party performing it. 
> 
> Of course one can start to characterise these characteristics
> as well but to do so merely throws up yet more information which
> might be relevant, factors which become increasingly subjective.
> 
> 
> This is a hard AI problem - establishing a shared vocabulary of
> terms which permits exchange of concepts whose semantics are
> not embedded in the communication mechanism or indeed any 
> mechanism for which a formal description is available.
> 
> 		Phill

From: Santosh Chokhani <[email-masked]>
To: "'Kurn, David'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 13:32:28 -0400
Sender: [email-masked]

Let us say an application requires more communication within a domain.

Then the relying party will start with the assumption that the
subscriber with whom it is trying to form a key management certificate
path or digital signature certificate verification path is also in the
same domain and hence will follow the caCertificate attribute link
first.

If the application requires more communication across the domain, the
relying party will start with the assumption that the subscriber with
whom it is trying to form a key management certificate path or digital
signature certificate verification path is in another domain and hence
will use forward element of the crossCertificatePair attribute under
option 1 and forward element of the (crossCertificatePair -
caCertificate) under option 2 first.

If there is no bias in communication intra or inter domain, the relying
party has lost nothing and will always find a trust path, if there is
one.

> -----Original Message-----
> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 1:12 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Santosh
> 
> I seem to sense a circularity of definition.   If I interpret your
> comment
> correctly, you place a cert in the caCertificate attribute if it
> belongs to
> the same domain, and you can determine that it's in the same domain by
> seeing if it's in the caCertificate attribute.  Exactly how I would
> use this
> in a computer program is unclear.   Perhaps you could sketch out some
> program logic one would use.
> 
> David
> 
> > -----Original Message-----
> > From:	Santosh Chokhani [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 9:53 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> [email-masked]'
> > Subject:	RE: forward & reverse elements - population
> > 
> > David:
> > 
> > In both options 1 and 2, a relying party can determine which issuing
> CAs
> > are considered in the domain of the subject CA by looking at
> > caCertificate attribute and the forward element of the
> > crossCertificatePair attribute.
> > 
> > In option 1, it is straightforward.
> > 
> > In option 2, you have to subtract the caCertificate from the
> > crossCertificatePair to get the two sets.
> > 
> > These two domains are from the subject CA's perspective.  It may or
> may
> > not be in the domain of the relying party.
> > 
> > > -----Original Message-----
> > > From:	Kurn, David [SMTP:[email-masked]]
> > > Sent:	Wednesday, September 09, 1998 12:16 PM
> > > To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > Santosh
> > > 
> > > Sorry to ask what must be a very naive question.  If, as you
> suggest,
> > > the
> > > "definition of a domain is purely a matter of local policy", then
> I
> > > think
> > > that the term "domain" is undefined for the purposes of a
> standard.
> > > If so,
> > > then I find it difficult to define any algorhithm (not necessarily
> > > computer
> > > based) or any process by which anyone could determine whether a CA
> is
> > > in the
> > > same or a different domain.
> > > 
> > > Think, for example, of a general purpose application program (like
> a
> > > mail
> > > client) trying to answer the question "is that CA inside or
> outside of
> > > my
> > > domain".  
> > > 
> > > Back in my college days, my math professors made it painfully
> clear
> > > that if
> > > you define a set, you must also provide a rule whereby you can
> > > determine
> > > whether a given element is inside or outside of that set.  Without
> > > such a
> > > rule, the set is undefined.
> > > 
> > > It may be that the definition of "domain" is elsewhere in the
> > > document, but
> > > I cannot find it.
> > > 
> > > David Kurn
> > > Compaq Computer Corp
> > > Electronic Commerce Stuff
> > > 
> > > > -----Original Message-----
> > > > From:	Santosh Chokhani [SMTP:[email-masked]]
> > > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > > To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > Yes. I agree.  The following is the revised text.
> > > > 
> > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.  If there are any self-issued certificates
> and
> > > they
> > > > require publication, the caCertificate attribute shall be used
> to
> > > store
> > > > them.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store
> certificates
> > > > issued to this CA by CAs in other domains.  Optionally, the
> reverse
> > > > element of the crossCertificatePair attribute, held in a
> particular
> > > CA's
> > > > directory entry, may contain a subset of certificates issued by
> this
> > > CA
> > > > to other CAs.  When both the forward and the reverse elements
> are
> > > > present, issuer name in one certificate shall match the subject
> name
> > > in
> > > > the other and vice versa, and the subject public key in one
> > > certificate
> > > > shall be capable of verifying the digital signature on the other
> > > > certificate and vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.  If there are any self-issued certificates
> and
> > > they
> > > > require publication, the caCertificate attribute shall be used
> to
> > > store
> > > > them.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store all
> > > certificates
> > > > issued to this CA.  Optionally, the reverse element of the
> > > > crossCertificatePair attribute, held in a particular CA's
> directory
> > > > entry, may contain a subset of certificates issued by this CA to
> > > other
> > > > CAs.  When both the forward and the reverse elements are
> present,
> > > issuer
> > > > name in one certificate shall match the subject name in the
> other
> > > and
> > > > vice versa, and the subject public key in one certificate shall
> be
> > > > capable of verifying the digital signature on the other
> certificate
> > > and
> > > > vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > > -----Original Message-----
> > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > Subject:	RE: forward & reverse elements - population
> > > > > 
> > > > > I agree that the texts below are consistent with the original
> > > intent
> > > > > of the
> > > > > 2 options and I also agree that they are clearer than the
> original
> > > > > texts
> > > > > except, possibly for coverage of self issued certificates.
> > > Shouldn't
> > > > > we also
> > > > > state explicitly that self issued certs are stored only in the
> > > > > cACertificate
> > > > > attribute for both options? 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh
> Chokhani
> > > > > > Subject: 	RE: forward & reverse elements - population
> > > > > > 
> > > > > > Sharon:
> > > > > > 
> > > > > > I can agree to the following text for the two option
> instead.
> > > > > Please
> > > > > > note that I have further clarified cross-certificate by
> tying
> > > the DN
> > > > > and
> > > > > > public keys.
> > > > > > 
> > > > > > I think the following texts are consistent with and further
> > > > > > clarifications of the two options.
> > > > > > 
> > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > > > > 
> > > > > And I option 2 :-)
> > > > > 
> > > > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > > > 
> > > > > > The cACertificate attribute, held in a particular CA's
> directory
> > > > > entry,
> > > > > > shall be used to store certificates issued to this CA by CAs
> in
> > > the
> > > > > same
> > > > > > domain as this CA.
> > > > > > 
> > > > > > The forward element of the crossCertificatePair attribute,
> held
> > > in a
> > > > > > particular CA's directory entry, shall be used to store
> > > certificates
> > > > > > issued to this CA by CAs in other domains.  Optionally, the
> > > reverse
> > > > > > element of the crossCertificatePair attribute, held in a
> > > particular
> > > > > CA's
> > > > > > directory entry, may contain a subset of certificates issued
> by
> > > this
> > > > > CA
> > > > > > to other CAs.  When both the forward and the reverse
> elements
> > > are
> > > > > > present, issuer name in one certificate shall match the
> subject
> > > name
> > > > > in
> > > > > > the other and vice versa, and the subject public key in one
> > > > > certificate
> > > > > > shall be capable of verifying the digital signature on the
> other
> > > > > > certificate and vice versa.
> > > > > > 
> > > > > > In the case of V3 certificates, none of the above CA
> > > certificates
> > > > > shall
> > > > > > include a basicConstraints extension with the cA value set
> to
> > > FALSE.
> > > > > > 
> > > > > > The definition of domain is purely a matter of local policy.
> > > > > > 
> > > > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > > > 
> > > > > > The cACertificate attribute, held in a particular CA's
> directory
> > > > > entry,
> > > > > > shall be used to store certificates issued to this CA by CAs
> in
> > > the
> > > > > same
> > > > > > domain as this CA.
> > > > > > 
> > > > > > The forward element of the crossCertificatePair attribute,
> held
> > > in a
> > > > > > particular CA's directory entry, shall be used to store all
> > > > > certificates
> > > > > > issued to this CA.  Optionally, the reverse element of the
> > > > > > crossCertificatePair attribute, held in a particular CA's
> > > directory
> > > > > > entry, may contain a subset of certificates issued by this
> CA to
> > > > > other
> > > > > > CAs.  When both the forward and the reverse elements are
> > > present,
> > > > > issuer
> > > > > > name in one certificate shall match the subject name in the
> > > other
> > > > > and
> > > > > > vice versa, and the subject public key in one certificate
> shall
> > > be
> > > > > > capable of verifying the digital signature on the other
> > > certificate
> > > > > and
> > > > > > vice versa.
> > > > > > 
> > > > > > In the case of V3 certificates, none of the above CA
> > > certificates
> > > > > shall
> > > > > > include a basicConstraints extension with the cA value set
> to
> > > FALSE.
> > > > > > 
> > > > > > The definition of domain is purely a matter of local policy.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > ----------
> > > > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > > > > Subject: 	RE: forward & reverse elements -
> population
> > > > > > > > 
> > > > > > > 	--stuff deleted
> > > > > > > > > 
> > > > > > > > 	[]  I agree.  I do not have problem with the
> following
> > > > > language.
> > > > > > > > " A certificate issued to a CA by another shall be
> stored
> > > either
> > > > > in
> > > > > > > the
> > > > > > > > caCertificate or forward component of
> crossCertificatePair
> > > > > attribute
> > > > > > > of
> > > > > > > > the subject CA.  Optionally, a subset of certificates
> issued
> > > by
> > > > > a CA
> > > > > > > can
> > > > > > > > be stored in the reverse component of
> crossCertificatePair
> > > > > attribute
> > > > > > > of
> > > > > > > > the issuing CA."
> > > > > > > > 
> > > > > > > > 	Please note that to me subset includes none,
> some, or
> > > > > all.  If
> > > > > > > > folks want further clarification, it is ok by me.
> > > > > > > > 
> > > > > > > Santosh, the only issue I have with this text is that (at
> > > least
> > > > > with
> > > > > > > the
> > > > > > > rationale behind option 2) any cert that appears in the
> > > > > cACertificate
> > > > > > > attribute of a given CA
> > > > > > > entry, should also appear in the crossCertificatePair
> > > attribute in
> > > > > the
> > > > > > > same
> > > > > > > CA entry.
> > > > > > >  What about deleting the reference to the cACertificate
> > > attribute
> > > > > from
> > > > > > > your
> > > > > > > text and proposing this as new text just for the
> > > > > crossCertificatePair
> > > > > > > attribute? 
> > > > > > > 
> > > > > > > Both Jan and David have indicated reasons to keep the
> "pair"
> > > > > together
> > > > > > > in the
> > > > > > > mutual case, so we should also consider adding the last
> > > paragraph
> > > > > of
> > > > > > > the
> > > > > > > text David proposed for that.  
> > > > > > > 
> > > > > > > Here's what the resulting text proposal would look like:
> > > > > > > 
> > > > > > > > " A certificate issued to a CA by another shall be
> stored in
> > > the
> > > > > > > > forward component of crossCertificatePair attribute of
> > > > > > > > the subject CA.  Optionally, a subset of certificates
> issued
> > > by
> > > > > a CA
> > > > > > > can
> > > > > > > > be stored in the reverse component of
> crossCertificatePair
> > > > > attribute
> > > > > > > of
> > > > > > > > the issuing CA. When both elements are present in the
> same
> > > > > value,
> > > > > > > the
> > > > > > > > value shall represent a mutual cross-certification of
> the
> > > two
> > > > > CAs. "
> > > > > > > > 
> > > > > > > If we can come to consensus on that attribute, then let's
> see
> > > what
> > > > > we
> > > > > > > can do
> > > > > > > with the cACertificate attribute text.
> > > > > > > 
> > > > > > > I agree with your view on what a subset is and I think
> that
> > > same
> > > > > > > definition
> > > > > > > would apply to the contents of the cACertificate attribute
> as
> > > a
> > > > > subset
> > > > > > > of
> > > > > > > the crossCertificatePair forward elements in option 2.
> > > > > > 

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:15:46 -0400
Importance: Normal
Sender: [email-masked]

> In using certificates, it is useful to know what form of 
> authentication is used by a CA to identify a new certificate 
> requester.  A certificate extension seems the best place to store 
> this information.

This sounds to me like a trip into a quagmire. I don't think that
it is possible to charaterize authentication mechanisms usefully
in a set of binary flags.

For example two CAs may be requiring presentation of a driving
license for authentication, only one CA may be using a state of
MA license with photo ID and another a UK driving license without
photo ID.

Even with documents such as passports there is considerable 
variation between countries in the strictness of their proceedures.

Then there are proceedural variations, is the applicant present
in person or were the credentials merely faxed...

Nor is the mechanism of authentication by itself particularly 
usefull unless there is an evaluation of the reliability of the
party performing it. 

Of course one can start to characterise these characteristics
as well but to do so merely throws up yet more information which
might be relevant, factors which become increasingly subjective.

This is a hard AI problem - establishing a shared vocabulary of
terms which permits exchange of concepts whose semantics are
not embedded in the communication mechanism or indeed any 
mechanism for which a formal description is available.

		Phill

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:12:22 -0700 
Sender: [email-masked]

Santosh

I seem to sense a circularity of definition.   If I interpret your comment
correctly, you place a cert in the caCertificate attribute if it belongs to
the same domain, and you can determine that it's in the same domain by
seeing if it's in the caCertificate attribute.  Exactly how I would use this
in a computer program is unclear.   Perhaps you could sketch out some
program logic one would use.

David

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 9:53 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> David:
> 
> In both options 1 and 2, a relying party can determine which issuing CAs
> are considered in the domain of the subject CA by looking at
> caCertificate attribute and the forward element of the
> crossCertificatePair attribute.
> 
> In option 1, it is straightforward.
> 
> In option 2, you have to subtract the caCertificate from the
> crossCertificatePair to get the two sets.
> 
> These two domains are from the subject CA's perspective.  It may or may
> not be in the domain of the relying party.
> 
> > -----Original Message-----
> > From:	Kurn, David [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 12:16 PM
> > To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> > Subject:	RE: forward & reverse elements - population
> > 
> > Santosh
> > 
> > Sorry to ask what must be a very naive question.  If, as you suggest,
> > the
> > "definition of a domain is purely a matter of local policy", then I
> > think
> > that the term "domain" is undefined for the purposes of a standard.
> > If so,
> > then I find it difficult to define any algorhithm (not necessarily
> > computer
> > based) or any process by which anyone could determine whether a CA is
> > in the
> > same or a different domain.
> > 
> > Think, for example, of a general purpose application program (like a
> > mail
> > client) trying to answer the question "is that CA inside or outside of
> > my
> > domain".  
> > 
> > Back in my college days, my math professors made it painfully clear
> > that if
> > you define a set, you must also provide a rule whereby you can
> > determine
> > whether a given element is inside or outside of that set.  Without
> > such a
> > rule, the set is undefined.
> > 
> > It may be that the definition of "domain" is elsewhere in the
> > document, but
> > I cannot find it.
> > 
> > David Kurn
> > Compaq Computer Corp
> > Electronic Commerce Stuff
> > 
> > > -----Original Message-----
> > > From:	Santosh Chokhani [SMTP:[email-masked]]
> > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > Yes. I agree.  The following is the revised text.
> > > 
> > > NEW PROPOSED TEXT FOR OPTION 1
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.  If there are any self-issued certificates and
> > they
> > > require publication, the caCertificate attribute shall be used to
> > store
> > > them.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store certificates
> > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > element of the crossCertificatePair attribute, held in a particular
> > CA's
> > > directory entry, may contain a subset of certificates issued by this
> > CA
> > > to other CAs.  When both the forward and the reverse elements are
> > > present, issuer name in one certificate shall match the subject name
> > in
> > > the other and vice versa, and the subject public key in one
> > certificate
> > > shall be capable of verifying the digital signature on the other
> > > certificate and vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > NEW PROPOSED TEXT FOR OPTION 2
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.  If there are any self-issued certificates and
> > they
> > > require publication, the caCertificate attribute shall be used to
> > store
> > > them.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store all
> > certificates
> > > issued to this CA.  Optionally, the reverse element of the
> > > crossCertificatePair attribute, held in a particular CA's directory
> > > entry, may contain a subset of certificates issued by this CA to
> > other
> > > CAs.  When both the forward and the reverse elements are present,
> > issuer
> > > name in one certificate shall match the subject name in the other
> > and
> > > vice versa, and the subject public key in one certificate shall be
> > > capable of verifying the digital signature on the other certificate
> > and
> > > vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > > -----Original Message-----
> > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > I agree that the texts below are consistent with the original
> > intent
> > > > of the
> > > > 2 options and I also agree that they are clearer than the original
> > > > texts
> > > > except, possibly for coverage of self issued certificates.
> > Shouldn't
> > > > we also
> > > > state explicitly that self issued certs are stored only in the
> > > > cACertificate
> > > > attribute for both options? 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > > > Subject: 	RE: forward & reverse elements - population
> > > > > 
> > > > > Sharon:
> > > > > 
> > > > > I can agree to the following text for the two option instead.
> > > > Please
> > > > > note that I have further clarified cross-certificate by tying
> > the DN
> > > > and
> > > > > public keys.
> > > > > 
> > > > > I think the following texts are consistent with and further
> > > > > clarifications of the two options.
> > > > > 
> > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > > > 
> > > > And I option 2 :-)
> > > > 
> > > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > > 
> > > > > The cACertificate attribute, held in a particular CA's directory
> > > > entry,
> > > > > shall be used to store certificates issued to this CA by CAs in
> > the
> > > > same
> > > > > domain as this CA.
> > > > > 
> > > > > The forward element of the crossCertificatePair attribute, held
> > in a
> > > > > particular CA's directory entry, shall be used to store
> > certificates
> > > > > issued to this CA by CAs in other domains.  Optionally, the
> > reverse
> > > > > element of the crossCertificatePair attribute, held in a
> > particular
> > > > CA's
> > > > > directory entry, may contain a subset of certificates issued by
> > this
> > > > CA
> > > > > to other CAs.  When both the forward and the reverse elements
> > are
> > > > > present, issuer name in one certificate shall match the subject
> > name
> > > > in
> > > > > the other and vice versa, and the subject public key in one
> > > > certificate
> > > > > shall be capable of verifying the digital signature on the other
> > > > > certificate and vice versa.
> > > > > 
> > > > > In the case of V3 certificates, none of the above CA
> > certificates
> > > > shall
> > > > > include a basicConstraints extension with the cA value set to
> > FALSE.
> > > > > 
> > > > > The definition of domain is purely a matter of local policy.
> > > > > 
> > > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > > 
> > > > > The cACertificate attribute, held in a particular CA's directory
> > > > entry,
> > > > > shall be used to store certificates issued to this CA by CAs in
> > the
> > > > same
> > > > > domain as this CA.
> > > > > 
> > > > > The forward element of the crossCertificatePair attribute, held
> > in a
> > > > > particular CA's directory entry, shall be used to store all
> > > > certificates
> > > > > issued to this CA.  Optionally, the reverse element of the
> > > > > crossCertificatePair attribute, held in a particular CA's
> > directory
> > > > > entry, may contain a subset of certificates issued by this CA to
> > > > other
> > > > > CAs.  When both the forward and the reverse elements are
> > present,
> > > > issuer
> > > > > name in one certificate shall match the subject name in the
> > other
> > > > and
> > > > > vice versa, and the subject public key in one certificate shall
> > be
> > > > > capable of verifying the digital signature on the other
> > certificate
> > > > and
> > > > > vice versa.
> > > > > 
> > > > > In the case of V3 certificates, none of the above CA
> > certificates
> > > > shall
> > > > > include a basicConstraints extension with the cA value set to
> > FALSE.
> > > > > 
> > > > > The definition of domain is purely a matter of local policy.
> > > > > 
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > ----------
> > > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > > > Subject: 	RE: forward & reverse elements - population
> > > > > > > 
> > > > > > 	--stuff deleted
> > > > > > > > 
> > > > > > > 	[]  I agree.  I do not have problem with the following
> > > > language.
> > > > > > > " A certificate issued to a CA by another shall be stored
> > either
> > > > in
> > > > > > the
> > > > > > > caCertificate or forward component of crossCertificatePair
> > > > attribute
> > > > > > of
> > > > > > > the subject CA.  Optionally, a subset of certificates issued
> > by
> > > > a CA
> > > > > > can
> > > > > > > be stored in the reverse component of crossCertificatePair
> > > > attribute
> > > > > > of
> > > > > > > the issuing CA."
> > > > > > > 
> > > > > > > 	Please note that to me subset includes none, some, or
> > > > all.  If
> > > > > > > folks want further clarification, it is ok by me.
> > > > > > > 
> > > > > > Santosh, the only issue I have with this text is that (at
> > least
> > > > with
> > > > > > the
> > > > > > rationale behind option 2) any cert that appears in the
> > > > cACertificate
> > > > > > attribute of a given CA
> > > > > > entry, should also appear in the crossCertificatePair
> > attribute in
> > > > the
> > > > > > same
> > > > > > CA entry.
> > > > > >  What about deleting the reference to the cACertificate
> > attribute
> > > > from
> > > > > > your
> > > > > > text and proposing this as new text just for the
> > > > crossCertificatePair
> > > > > > attribute? 
> > > > > > 
> > > > > > Both Jan and David have indicated reasons to keep the "pair"
> > > > together
> > > > > > in the
> > > > > > mutual case, so we should also consider adding the last
> > paragraph
> > > > of
> > > > > > the
> > > > > > text David proposed for that.  
> > > > > > 
> > > > > > Here's what the resulting text proposal would look like:
> > > > > > 
> > > > > > > " A certificate issued to a CA by another shall be stored in
> > the
> > > > > > > forward component of crossCertificatePair attribute of
> > > > > > > the subject CA.  Optionally, a subset of certificates issued
> > by
> > > > a CA
> > > > > > can
> > > > > > > be stored in the reverse component of crossCertificatePair
> > > > attribute
> > > > > > of
> > > > > > > the issuing CA. When both elements are present in the same
> > > > value,
> > > > > > the
> > > > > > > value shall represent a mutual cross-certification of the
> > two
> > > > CAs. "
> > > > > > > 
> > > > > > If we can come to consensus on that attribute, then let's see
> > what
> > > > we
> > > > > > can do
> > > > > > with the cACertificate attribute text.
> > > > > > 
> > > > > > I agree with your view on what a subset is and I think that
> > same
> > > > > > definition
> > > > > > would apply to the contents of the cACertificate attribute as
> > a
> > > > subset
> > > > > > of
> > > > > > the crossCertificatePair forward elements in option 2.
> > > > > 

From: Santosh Chokhani <[email-masked]>
To: "'Kurn, David'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:53:12 -0400
Sender: [email-masked]

David:

In both options 1 and 2, a relying party can determine which issuing CAs
are considered in the domain of the subject CA by looking at
caCertificate attribute and the forward element of the
crossCertificatePair attribute.

In option 1, it is straightforward.

In option 2, you have to subtract the caCertificate from the
crossCertificatePair to get the two sets.

These two domains are from the subject CA's perspective.  It may or may
not be in the domain of the relying party.

> -----Original Message-----
> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 12:16 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Santosh
> 
> Sorry to ask what must be a very naive question.  If, as you suggest,
> the
> "definition of a domain is purely a matter of local policy", then I
> think
> that the term "domain" is undefined for the purposes of a standard.
> If so,
> then I find it difficult to define any algorhithm (not necessarily
> computer
> based) or any process by which anyone could determine whether a CA is
> in the
> same or a different domain.
> 
> Think, for example, of a general purpose application program (like a
> mail
> client) trying to answer the question "is that CA inside or outside of
> my
> domain".  
> 
> Back in my college days, my math professors made it painfully clear
> that if
> you define a set, you must also provide a rule whereby you can
> determine
> whether a given element is inside or outside of that set.  Without
> such a
> rule, the set is undefined.
> 
> It may be that the definition of "domain" is elsewhere in the
> document, but
> I cannot find it.
> 
> David Kurn
> Compaq Computer Corp
> Electronic Commerce Stuff
> 
> > -----Original Message-----
> > From:	Santosh Chokhani [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 8:27 AM
> > To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > Subject:	RE: forward & reverse elements - population
> > 
> > Yes. I agree.  The following is the revised text.
> > 
> > NEW PROPOSED TEXT FOR OPTION 1
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.  If there are any self-issued certificates and
> they
> > require publication, the caCertificate attribute shall be used to
> store
> > them.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store certificates
> > issued to this CA by CAs in other domains.  Optionally, the reverse
> > element of the crossCertificatePair attribute, held in a particular
> CA's
> > directory entry, may contain a subset of certificates issued by this
> CA
> > to other CAs.  When both the forward and the reverse elements are
> > present, issuer name in one certificate shall match the subject name
> in
> > the other and vice versa, and the subject public key in one
> certificate
> > shall be capable of verifying the digital signature on the other
> > certificate and vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > NEW PROPOSED TEXT FOR OPTION 2
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.  If there are any self-issued certificates and
> they
> > require publication, the caCertificate attribute shall be used to
> store
> > them.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store all
> certificates
> > issued to this CA.  Optionally, the reverse element of the
> > crossCertificatePair attribute, held in a particular CA's directory
> > entry, may contain a subset of certificates issued by this CA to
> other
> > CAs.  When both the forward and the reverse elements are present,
> issuer
> > name in one certificate shall match the subject name in the other
> and
> > vice versa, and the subject public key in one certificate shall be
> > capable of verifying the digital signature on the other certificate
> and
> > vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > > -----Original Message-----
> > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > To:	[email-masked]'; 'Santosh Chokhani'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > I agree that the texts below are consistent with the original
> intent
> > > of the
> > > 2 options and I also agree that they are clearer than the original
> > > texts
> > > except, possibly for coverage of self issued certificates.
> Shouldn't
> > > we also
> > > state explicitly that self issued certs are stored only in the
> > > cACertificate
> > > attribute for both options? 
> > > 
> > > 
> > > > ----------
> > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > Sent: 	September 9, 1998 9:08 AM
> > > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > > Subject: 	RE: forward & reverse elements - population
> > > > 
> > > > Sharon:
> > > > 
> > > > I can agree to the following text for the two option instead.
> > > Please
> > > > note that I have further clarified cross-certificate by tying
> the DN
> > > and
> > > > public keys.
> > > > 
> > > > I think the following texts are consistent with and further
> > > > clarifications of the two options.
> > > > 
> > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > > 
> > > And I option 2 :-)
> > > 
> > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store
> certificates
> > > > issued to this CA by CAs in other domains.  Optionally, the
> reverse
> > > > element of the crossCertificatePair attribute, held in a
> particular
> > > CA's
> > > > directory entry, may contain a subset of certificates issued by
> this
> > > CA
> > > > to other CAs.  When both the forward and the reverse elements
> are
> > > > present, issuer name in one certificate shall match the subject
> name
> > > in
> > > > the other and vice versa, and the subject public key in one
> > > certificate
> > > > shall be capable of verifying the digital signature on the other
> > > > certificate and vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store all
> > > certificates
> > > > issued to this CA.  Optionally, the reverse element of the
> > > > crossCertificatePair attribute, held in a particular CA's
> directory
> > > > entry, may contain a subset of certificates issued by this CA to
> > > other
> > > > CAs.  When both the forward and the reverse elements are
> present,
> > > issuer
> > > > name in one certificate shall match the subject name in the
> other
> > > and
> > > > vice versa, and the subject public key in one certificate shall
> be
> > > > capable of verifying the digital signature on the other
> certificate
> > > and
> > > > vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > Subject:	RE: forward & reverse elements - population
> > > > > 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > > Subject: 	RE: forward & reverse elements - population
> > > > > > 
> > > > > 	--stuff deleted
> > > > > > > 
> > > > > > 	[]  I agree.  I do not have problem with the following
> > > language.
> > > > > > " A certificate issued to a CA by another shall be stored
> either
> > > in
> > > > > the
> > > > > > caCertificate or forward component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the subject CA.  Optionally, a subset of certificates issued
> by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA."
> > > > > > 
> > > > > > 	Please note that to me subset includes none, some, or
> > > all.  If
> > > > > > folks want further clarification, it is ok by me.
> > > > > > 
> > > > > Santosh, the only issue I have with this text is that (at
> least
> > > with
> > > > > the
> > > > > rationale behind option 2) any cert that appears in the
> > > cACertificate
> > > > > attribute of a given CA
> > > > > entry, should also appear in the crossCertificatePair
> attribute in
> > > the
> > > > > same
> > > > > CA entry.
> > > > >  What about deleting the reference to the cACertificate
> attribute
> > > from
> > > > > your
> > > > > text and proposing this as new text just for the
> > > crossCertificatePair
> > > > > attribute? 
> > > > > 
> > > > > Both Jan and David have indicated reasons to keep the "pair"
> > > together
> > > > > in the
> > > > > mutual case, so we should also consider adding the last
> paragraph
> > > of
> > > > > the
> > > > > text David proposed for that.  
> > > > > 
> > > > > Here's what the resulting text proposal would look like:
> > > > > 
> > > > > > " A certificate issued to a CA by another shall be stored in
> the
> > > > > > forward component of crossCertificatePair attribute of
> > > > > > the subject CA.  Optionally, a subset of certificates issued
> by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA. When both elements are present in the same
> > > value,
> > > > > the
> > > > > > value shall represent a mutual cross-certification of the
> two
> > > CAs. "
> > > > > > 
> > > > > If we can come to consensus on that attribute, then let's see
> what
> > > we
> > > > > can do
> > > > > with the cACertificate attribute text.
> > > > > 
> > > > > I agree with your view on what a subset is and I think that
> same
> > > > > definition
> > > > > would apply to the contents of the cACertificate attribute as
> a
> > > subset
> > > > > of
> > > > > the crossCertificatePair forward elements in option 2.
> > > > 

To: [email-masked]
Subject: For Option 2
Date: Wed, 09 Sep 1998 17:38:35 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

Date: Wed, 09 Sep 1998 09:36:53 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

It seems to me that the certificate policies (section 4.2.1.5) is still the
proper place for this. If we create a set of bits that says how the CA is
authenticating, unless the statement in the new bits is *exactly* what the
CA is using, they should not commit to those bits because someone later can
say "but you said you were doing such-and-so". The CPS is under their control.

Can you be specific about the advantage of what you are proposing versus
the certificate policy?

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: [email-masked]
Date: Wed, 9 Sep 1998 12:23:30 -0400
Subject: For Option 2
Sender: [email-masked]

Alan Buffett
09/09/98 12:23 PM

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:15:34 -0700 
Sender: [email-masked]

Santosh

Sorry to ask what must be a very naive question.  If, as you suggest, the
"definition of a domain is purely a matter of local policy", then I think
that the term "domain" is undefined for the purposes of a standard.  If so,
then I find it difficult to define any algorhithm (not necessarily computer
based) or any process by which anyone could determine whether a CA is in the
same or a different domain.

Think, for example, of a general purpose application program (like a mail
client) trying to answer the question "is that CA inside or outside of my
domain".  

Back in my college days, my math professors made it painfully clear that if
you define a set, you must also provide a rule whereby you can determine
whether a given element is inside or outside of that set.  Without such a
rule, the set is undefined.

It may be that the definition of "domain" is elsewhere in the document, but
I cannot find it.

David Kurn
Compaq Computer Corp
Electronic Commerce Stuff

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 8:27 AM
> To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> Subject:	RE: forward & reverse elements - population
> 
> Yes. I agree.  The following is the revised text.
> 
> NEW PROPOSED TEXT FOR OPTION 1
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.  If there are any self-issued certificates and they
> require publication, the caCertificate attribute shall be used to store
> them.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  Optionally, the reverse
> element of the crossCertificatePair attribute, held in a particular CA's
> directory entry, may contain a subset of certificates issued by this CA
> to other CAs.  When both the forward and the reverse elements are
> present, issuer name in one certificate shall match the subject name in
> the other and vice versa, and the subject public key in one certificate
> shall be capable of verifying the digital signature on the other
> certificate and vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> NEW PROPOSED TEXT FOR OPTION 2
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.  If there are any self-issued certificates and they
> require publication, the caCertificate attribute shall be used to store
> them.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store all certificates
> issued to this CA.  Optionally, the reverse element of the
> crossCertificatePair attribute, held in a particular CA's directory
> entry, may contain a subset of certificates issued by this CA to other
> CAs.  When both the forward and the reverse elements are present, issuer
> name in one certificate shall match the subject name in the other and
> vice versa, and the subject public key in one certificate shall be
> capable of verifying the digital signature on the other certificate and
> vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> > -----Original Message-----
> > From:	Sharon Boeyen [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 11:02 AM
> > To:	[email-masked]'; 'Santosh Chokhani'
> > Subject:	RE: forward & reverse elements - population
> > 
> > I agree that the texts below are consistent with the original intent
> > of the
> > 2 options and I also agree that they are clearer than the original
> > texts
> > except, possibly for coverage of self issued certificates. Shouldn't
> > we also
> > state explicitly that self issued certs are stored only in the
> > cACertificate
> > attribute for both options? 
> > 
> > 
> > > ----------
> > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > Sent: 	September 9, 1998 9:08 AM
> > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > Subject: 	RE: forward & reverse elements - population
> > > 
> > > Sharon:
> > > 
> > > I can agree to the following text for the two option instead.
> > Please
> > > note that I have further clarified cross-certificate by tying the DN
> > and
> > > public keys.
> > > 
> > > I think the following texts are consistent with and further
> > > clarifications of the two options.
> > > 
> > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > 
> > And I option 2 :-)
> > 
> > > NEW PROPOSED TEXT FOR OPTION 1
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store certificates
> > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > element of the crossCertificatePair attribute, held in a particular
> > CA's
> > > directory entry, may contain a subset of certificates issued by this
> > CA
> > > to other CAs.  When both the forward and the reverse elements are
> > > present, issuer name in one certificate shall match the subject name
> > in
> > > the other and vice versa, and the subject public key in one
> > certificate
> > > shall be capable of verifying the digital signature on the other
> > > certificate and vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > NEW PROPOSED TEXT FOR OPTION 2
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store all
> > certificates
> > > issued to this CA.  Optionally, the reverse element of the
> > > crossCertificatePair attribute, held in a particular CA's directory
> > > entry, may contain a subset of certificates issued by this CA to
> > other
> > > CAs.  When both the forward and the reverse elements are present,
> > issuer
> > > name in one certificate shall match the subject name in the other
> > and
> > > vice versa, and the subject public key in one certificate shall be
> > > capable of verifying the digital signature on the other certificate
> > and
> > > vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > Subject: 	RE: forward & reverse elements - population
> > > > > 
> > > > 	--stuff deleted
> > > > > > 
> > > > > 	[]  I agree.  I do not have problem with the following
> > language.
> > > > > " A certificate issued to a CA by another shall be stored either
> > in
> > > > the
> > > > > caCertificate or forward component of crossCertificatePair
> > attribute
> > > > of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA."
> > > > > 
> > > > > 	Please note that to me subset includes none, some, or
> > all.  If
> > > > > folks want further clarification, it is ok by me.
> > > > > 
> > > > Santosh, the only issue I have with this text is that (at least
> > with
> > > > the
> > > > rationale behind option 2) any cert that appears in the
> > cACertificate
> > > > attribute of a given CA
> > > > entry, should also appear in the crossCertificatePair attribute in
> > the
> > > > same
> > > > CA entry.
> > > >  What about deleting the reference to the cACertificate attribute
> > from
> > > > your
> > > > text and proposing this as new text just for the
> > crossCertificatePair
> > > > attribute? 
> > > > 
> > > > Both Jan and David have indicated reasons to keep the "pair"
> > together
> > > > in the
> > > > mutual case, so we should also consider adding the last paragraph
> > of
> > > > the
> > > > text David proposed for that.  
> > > > 
> > > > Here's what the resulting text proposal would look like:
> > > > 
> > > > > " A certificate issued to a CA by another shall be stored in the
> > > > > forward component of crossCertificatePair attribute of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA. When both elements are present in the same
> > value,
> > > > the
> > > > > value shall represent a mutual cross-certification of the two
> > CAs. "
> > > > > 
> > > > If we can come to consensus on that attribute, then let's see what
> > we
> > > > can do
> > > > with the cACertificate attribute text.
> > > > 
> > > > I agree with your view on what a subset is and I think that same
> > > > definition
> > > > would apply to the contents of the cACertificate attribute as a
> > subset
> > > > of
> > > > the crossCertificatePair forward elements in option 2.
> > > 

Date: Wed, 09 Sep 1998 10:03:36 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

In using certificates, it is useful to know what form of authentication is used by a CA to identify a new certificate requester.  A certificate extension seems the best place to store this information.

At one time, Bob Jeuneman prepared a paper proposing this extension and detailing many categories, from anonymous, self-authenticated, self authenticated with data verifired (or with credit account, etc.), authenticated in person, in person with governement-issued picture ID, multiple forms of government picture IDs with current credit reports and corporate D&B, etc.

The current practice, I beleive, is to embed the authentication mechanism in a CA operations or policy statement tha may or may not be online for someone to peruse and make their own judgement.  Putting a clear indicator in the signed cert would help.

Comments?  Bob?

Michael

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:05:30 -0400
Sender: [email-masked]

Denis:

I agree with you.  Clarification of the text is easy.  However, I have a
question.  Must a certificate issued to a CA appear in the forward
element, caCertificate or can it be missing altogether?

I think the text in terms of saying that the forward element need not be
present in all cases is easy.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 8:44 PM
> To:	Santosh Chokhani
> Cc:	'Sharon Boeyen'; [email-masked]'
> Subject:	Re: forward & reverse elements - population
> 
> Santosh,
> 
> Your new proposed text does not address my concern correctly.
> 
> For a crossCertificatePair Attribute, either the forward element only
> MAY be present, or the reverse element only MAY be present, or the
> reverse and the forward elements may be both present.
>  
> Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward
> element
> shall not be mandated to be present in a crossCertificatePair
> Attribute.
> 
> Denis 
> 
> > Sharon:
> 
> > I can agree to the following text for the two option instead.
> Please
> > note that I have further clarified cross-certificate by tying the DN
> and
> > public keys.
> > 
> > I think the following texts are consistent with and further
> > clarifications of the two options.
> > 
> > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > 
> > NEW PROPOSED TEXT FOR OPTION 1
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store certificates
> > issued to this CA by CAs in other domains.  Optionally, the reverse
> > element of the crossCertificatePair attribute, held in a particular
> CA's
> > directory entry, may contain a subset of certificates issued by this
> CA
> > to other CAs.  When both the forward and the reverse elements are
> > present, issuer name in one certificate shall match the subject name
> in
> > the other and vice versa, and the subject public key in one
> certificate
> > shall be capable of verifying the digital signature on the other
> > certificate and vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > NEW PROPOSED TEXT FOR OPTION 2
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store all
> certificates
> > issued to this CA.  Optionally, the reverse element of the
> > crossCertificatePair attribute, held in a particular CA's directory
> > entry, may contain a subset of certificates issued by this CA to
> other
> > CAs.  When both the forward and the reverse elements are present,
> issuer
> > name in one certificate shall match the subject name in the other
> and
> > vice versa, and the subject public key in one certificate shall be
> > capable of verifying the digital signature on the other certificate
> and
> > vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > > -----Original Message-----
> > > From: Sharon Boeyen [SMTP:[email-masked]]
> > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > To:   [email-masked]'; 'Santosh Chokhani'
> > > Subject:      RE: forward & reverse elements - population
> > >
> > >
> > >
> > > > ----------
> > > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > > Sent:       September 8, 1998 10:05 AM
> > > > To:         'Sharon Boeyen'; [email-masked]'
> > > > Subject:    RE: forward & reverse elements - population
> > > >
> > >       --stuff deleted
> > > > >
> > > >     []  I agree.  I do not have problem with the following
> language.
> > > > " A certificate issued to a CA by another shall be stored either
> in
> > > the
> > > > caCertificate or forward component of crossCertificatePair
> attribute
> > > of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA."
> > > >
> > > >     Please note that to me subset includes none, some, or all.
> If
> > > > folks want further clarification, it is ok by me.
> > > >
> > > Santosh, the only issue I have with this text is that (at least
> with
> > > the
> > > rationale behind option 2) any cert that appears in the
> cACertificate
> > > attribute of a given CA
> > > entry, should also appear in the crossCertificatePair attribute in
> the
> > > same
> > > CA entry.
> > >  What about deleting the reference to the cACertificate attribute
> from
> > > your
> > > text and proposing this as new text just for the
> crossCertificatePair
> > > attribute?
> > >
> > > Both Jan and David have indicated reasons to keep the "pair"
> together
> > > in the
> > > mutual case, so we should also consider adding the last paragraph
> of
> > > the
> > > text David proposed for that.
> > >
> > > Here's what the resulting text proposal would look like:
> > >
> > > > " A certificate issued to a CA by another shall be stored in the
> > > > forward component of crossCertificatePair attribute of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA. When both elements are present in the same
> value,
> > > the
> > > > value shall represent a mutual cross-certification of the two
> CAs. "
> > > >
> > > If we can come to consensus on that attribute, then let's see what
> we
> > > can do
> > > with the cACertificate attribute text.
> > >
> > > I agree with your view on what a subset is and I think that same
> > > definition
> > > would apply to the contents of the cACertificate attribute as a
> subset
> > > of
> > > the crossCertificatePair forward elements in option 2.
> 
> -- 
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: [email-masked]
To: [email-masked]
Date: Wed, 9 Sep 1998 11:46:08 -0400
Subject: For Option 2
Sender: [email-masked]

09/09/98 11:46 AM
Ross Smith
Ross Smith
Ross Smith
09/09/98 11:46 AM
09/09/98 11:46 AM

Date: Wed, 09 Sep 1998 17:44:12 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Santosh Chokhani <[email-masked]>
CC: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: forward & reverse elements - population
Sender: [email-masked]

Santosh,

Your new proposed text does not address my concern correctly.

For a crossCertificatePair Attribute, either the forward element only
MAY be present, or the reverse element only MAY be present, or the
reverse and the forward elements may be both present.
 
Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward element
shall not be mandated to be present in a crossCertificatePair Attribute.

Denis 

> Sharon:

> I can agree to the following text for the two option instead.  Please
> note that I have further clarified cross-certificate by tying the DN and
> public keys.
> 
> I think the following texts are consistent with and further
> clarifications of the two options.
> 
> I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> 
> NEW PROPOSED TEXT FOR OPTION 1
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  Optionally, the reverse
> element of the crossCertificatePair attribute, held in a particular CA's
> directory entry, may contain a subset of certificates issued by this CA
> to other CAs.  When both the forward and the reverse elements are
> present, issuer name in one certificate shall match the subject name in
> the other and vice versa, and the subject public key in one certificate
> shall be capable of verifying the digital signature on the other
> certificate and vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> NEW PROPOSED TEXT FOR OPTION 2
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store all certificates
> issued to this CA.  Optionally, the reverse element of the
> crossCertificatePair attribute, held in a particular CA's directory
> entry, may contain a subset of certificates issued by this CA to other
> CAs.  When both the forward and the reverse elements are present, issuer
> name in one certificate shall match the subject name in the other and
> vice versa, and the subject public key in one certificate shall be
> capable of verifying the digital signature on the other certificate and
> vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> > -----Original Message-----
> > From: Sharon Boeyen [SMTP:[email-masked]]
> > Sent: Tuesday, September 08, 1998 5:46 PM
> > To:   [email-masked]'; 'Santosh Chokhani'
> > Subject:      RE: forward & reverse elements - population
> >
> >
> >
> > > ----------
> > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > Sent:       September 8, 1998 10:05 AM
> > > To:         'Sharon Boeyen'; [email-masked]'
> > > Subject:    RE: forward & reverse elements - population
> > >
> >       --stuff deleted
> > > >
> > >     []  I agree.  I do not have problem with the following language.
> > > " A certificate issued to a CA by another shall be stored either in
> > the
> > > caCertificate or forward component of crossCertificatePair attribute
> > of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA."
> > >
> > >     Please note that to me subset includes none, some, or all.  If
> > > folks want further clarification, it is ok by me.
> > >
> > Santosh, the only issue I have with this text is that (at least with
> > the
> > rationale behind option 2) any cert that appears in the cACertificate
> > attribute of a given CA
> > entry, should also appear in the crossCertificatePair attribute in the
> > same
> > CA entry.
> >  What about deleting the reference to the cACertificate attribute from
> > your
> > text and proposing this as new text just for the crossCertificatePair
> > attribute?
> >
> > Both Jan and David have indicated reasons to keep the "pair" together
> > in the
> > mutual case, so we should also consider adding the last paragraph of
> > the
> > text David proposed for that.
> >
> > Here's what the resulting text proposal would look like:
> >
> > > " A certificate issued to a CA by another shall be stored in the
> > > forward component of crossCertificatePair attribute of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA. When both elements are present in the same value,
> > the
> > > value shall represent a mutual cross-certification of the two CAs. "
> > >
> > If we can come to consensus on that attribute, then let's see what we
> > can do
> > with the cACertificate attribute text.
> >
> > I agree with your view on what a subset is and I think that same
> > definition
> > would apply to the contents of the cACertificate attribute as a subset
> > of
> > the crossCertificatePair forward elements in option 2.

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:26:42 -0400
Sender: [email-masked]

Yes. I agree.  The following is the revised text.

NEW PROPOSED TEXT FOR OPTION 1

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.  If there are any self-issued certificates and they
require publication, the caCertificate attribute shall be used to store
them.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates
issued to this CA by CAs in other domains.  Optionally, the reverse
element of the crossCertificatePair attribute, held in a particular CA's
directory entry, may contain a subset of certificates issued by this CA
to other CAs.  When both the forward and the reverse elements are
present, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

NEW PROPOSED TEXT FOR OPTION 2

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.  If there are any self-issued certificates and they
require publication, the caCertificate attribute shall be used to store
them.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store all certificates
issued to this CA.  Optionally, the reverse element of the
crossCertificatePair attribute, held in a particular CA's directory
entry, may contain a subset of certificates issued by this CA to other
CAs.  When both the forward and the reverse elements are present, issuer
name in one certificate shall match the subject name in the other and
vice versa, and the subject public key in one certificate shall be
capable of verifying the digital signature on the other certificate and
vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 11:02 AM
> To:	[email-masked]'; 'Santosh Chokhani'
> Subject:	RE: forward & reverse elements - population
> 
> I agree that the texts below are consistent with the original intent
> of the
> 2 options and I also agree that they are clearer than the original
> texts
> except, possibly for coverage of self issued certificates. Shouldn't
> we also
> state explicitly that self issued certs are stored only in the
> cACertificate
> attribute for both options? 
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > Sent: 	September 9, 1998 9:08 AM
> > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > Subject: 	RE: forward & reverse elements - population
> > 
> > Sharon:
> > 
> > I can agree to the following text for the two option instead.
> Please
> > note that I have further clarified cross-certificate by tying the DN
> and
> > public keys.
> > 
> > I think the following texts are consistent with and further
> > clarifications of the two options.
> > 
> > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > 
> And I option 2 :-)
> 
> > NEW PROPOSED TEXT FOR OPTION 1
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store certificates
> > issued to this CA by CAs in other domains.  Optionally, the reverse
> > element of the crossCertificatePair attribute, held in a particular
> CA's
> > directory entry, may contain a subset of certificates issued by this
> CA
> > to other CAs.  When both the forward and the reverse elements are
> > present, issuer name in one certificate shall match the subject name
> in
> > the other and vice versa, and the subject public key in one
> certificate
> > shall be capable of verifying the digital signature on the other
> > certificate and vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > NEW PROPOSED TEXT FOR OPTION 2
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store all
> certificates
> > issued to this CA.  Optionally, the reverse element of the
> > crossCertificatePair attribute, held in a particular CA's directory
> > entry, may contain a subset of certificates issued by this CA to
> other
> > CAs.  When both the forward and the reverse elements are present,
> issuer
> > name in one certificate shall match the subject name in the other
> and
> > vice versa, and the subject public key in one certificate shall be
> > capable of verifying the digital signature on the other certificate
> and
> > vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > To:	[email-masked]'; 'Santosh Chokhani'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > 
> > > 
> > > > ----------
> > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > Sent: 	September 8, 1998 10:05 AM
> > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > Subject: 	RE: forward & reverse elements - population
> > > > 
> > > 	--stuff deleted
> > > > > 
> > > > 	[]  I agree.  I do not have problem with the following
> language.
> > > > " A certificate issued to a CA by another shall be stored either
> in
> > > the
> > > > caCertificate or forward component of crossCertificatePair
> attribute
> > > of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA."
> > > > 
> > > > 	Please note that to me subset includes none, some, or
> all.  If
> > > > folks want further clarification, it is ok by me.
> > > > 
> > > Santosh, the only issue I have with this text is that (at least
> with
> > > the
> > > rationale behind option 2) any cert that appears in the
> cACertificate
> > > attribute of a given CA
> > > entry, should also appear in the crossCertificatePair attribute in
> the
> > > same
> > > CA entry.
> > >  What about deleting the reference to the cACertificate attribute
> from
> > > your
> > > text and proposing this as new text just for the
> crossCertificatePair
> > > attribute? 
> > > 
> > > Both Jan and David have indicated reasons to keep the "pair"
> together
> > > in the
> > > mutual case, so we should also consider adding the last paragraph
> of
> > > the
> > > text David proposed for that.  
> > > 
> > > Here's what the resulting text proposal would look like:
> > > 
> > > > " A certificate issued to a CA by another shall be stored in the
> > > > forward component of crossCertificatePair attribute of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA. When both elements are present in the same
> value,
> > > the
> > > > value shall represent a mutual cross-certification of the two
> CAs. "
> > > > 
> > > If we can come to consensus on that attribute, then let's see what
> we
> > > can do
> > > with the cACertificate attribute text.
> > > 
> > > I agree with your view on what a subset is and I think that same
> > > definition
> > > would apply to the contents of the cACertificate attribute as a
> subset
> > > of
> > > the crossCertificatePair forward elements in option 2.
> > 

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:01:32 -0400 
Sender: [email-masked]

I agree that the texts below are consistent with the original intent of the
2 options and I also agree that they are clearer than the original texts
except, possibly for coverage of self issued certificates. Shouldn't we also
state explicitly that self issued certs are stored only in the cACertificate
attribute for both options? 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 9, 1998 9:08 AM
> To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> Subject: 	RE: forward & reverse elements - population
> 
> Sharon:
> 
> I can agree to the following text for the two option instead.  Please
> note that I have further clarified cross-certificate by tying the DN and
> public keys.
> 
> I think the following texts are consistent with and further
> clarifications of the two options.
> 
> I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> 
And I option 2 :-)

> NEW PROPOSED TEXT FOR OPTION 1
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  Optionally, the reverse
> element of the crossCertificatePair attribute, held in a particular CA's
> directory entry, may contain a subset of certificates issued by this CA
> to other CAs.  When both the forward and the reverse elements are
> present, issuer name in one certificate shall match the subject name in
> the other and vice versa, and the subject public key in one certificate
> shall be capable of verifying the digital signature on the other
> certificate and vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> NEW PROPOSED TEXT FOR OPTION 2
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store all certificates
> issued to this CA.  Optionally, the reverse element of the
> crossCertificatePair attribute, held in a particular CA's directory
> entry, may contain a subset of certificates issued by this CA to other
> CAs.  When both the forward and the reverse elements are present, issuer
> name in one certificate shall match the subject name in the other and
> vice versa, and the subject public key in one certificate shall be
> capable of verifying the digital signature on the other certificate and
> vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> 
> 
> > -----Original Message-----
> > From:	Sharon Boeyen [SMTP:[email-masked]]
> > Sent:	Tuesday, September 08, 1998 5:46 PM
> > To:	[email-masked]'; 'Santosh Chokhani'
> > Subject:	RE: forward & reverse elements - population
> > 
> > 
> > 
> > > ----------
> > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > Sent: 	September 8, 1998 10:05 AM
> > > To: 	'Sharon Boeyen'; [email-masked]'
> > > Subject: 	RE: forward & reverse elements - population
> > > 
> > 	--stuff deleted
> > > > 
> > > 	[]  I agree.  I do not have problem with the following language.
> > > " A certificate issued to a CA by another shall be stored either in
> > the
> > > caCertificate or forward component of crossCertificatePair attribute
> > of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA."
> > > 
> > > 	Please note that to me subset includes none, some, or all.  If
> > > folks want further clarification, it is ok by me.
> > > 
> > Santosh, the only issue I have with this text is that (at least with
> > the
> > rationale behind option 2) any cert that appears in the cACertificate
> > attribute of a given CA
> > entry, should also appear in the crossCertificatePair attribute in the
> > same
> > CA entry.
> >  What about deleting the reference to the cACertificate attribute from
> > your
> > text and proposing this as new text just for the crossCertificatePair
> > attribute? 
> > 
> > Both Jan and David have indicated reasons to keep the "pair" together
> > in the
> > mutual case, so we should also consider adding the last paragraph of
> > the
> > text David proposed for that.  
> > 
> > Here's what the resulting text proposal would look like:
> > 
> > > " A certificate issued to a CA by another shall be stored in the
> > > forward component of crossCertificatePair attribute of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA. When both elements are present in the same value,
> > the
> > > value shall represent a mutual cross-certification of the two CAs. "
> > > 
> > If we can come to consensus on that attribute, then let's see what we
> > can do
> > with the cACertificate attribute text.
> > 
> > I agree with your view on what a subset is and I think that same
> > definition
> > would apply to the contents of the cACertificate attribute as a subset
> > of
> > the crossCertificatePair forward elements in option 2.
> 

Date: Wed, 09 Sep 1998 15:40:49 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: For Option none
Sender: [email-masked]

The straw poll is now obsolete since neither of the two original texts
is acceptable as it is. Anyway since it was not a "vote", it was
interresting to promote discussion on this topic and apparently that
discussion has not yet ended !

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:08:23 -0400
Sender: [email-masked]

Sharon:

I can agree to the following text for the two option instead.  Please
note that I have further clarified cross-certificate by tying the DN and
public keys.

I think the following texts are consistent with and further
clarifications of the two options.

I STILL AM STRONGLY IN FAVOR OF OPTION 1.

NEW PROPOSED TEXT FOR OPTION 1

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates
issued to this CA by CAs in other domains.  Optionally, the reverse
element of the crossCertificatePair attribute, held in a particular CA's
directory entry, may contain a subset of certificates issued by this CA
to other CAs.  When both the forward and the reverse elements are
present, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

NEW PROPOSED TEXT FOR OPTION 2

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store all certificates
issued to this CA.  Optionally, the reverse element of the
crossCertificatePair attribute, held in a particular CA's directory
entry, may contain a subset of certificates issued by this CA to other
CAs.  When both the forward and the reverse elements are present, issuer
name in one certificate shall match the subject name in the other and
vice versa, and the subject public key in one certificate shall be
capable of verifying the digital signature on the other certificate and
vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Tuesday, September 08, 1998 5:46 PM
> To:	[email-masked]'; 'Santosh Chokhani'
> Subject:	RE: forward & reverse elements - population
> 
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > Sent: 	September 8, 1998 10:05 AM
> > To: 	'Sharon Boeyen'; [email-masked]'
> > Subject: 	RE: forward & reverse elements - population
> > 
> 	--stuff deleted
> > > 
> > 	[]  I agree.  I do not have problem with the following language.
> > " A certificate issued to a CA by another shall be stored either in
> the
> > caCertificate or forward component of crossCertificatePair attribute
> of
> > the subject CA.  Optionally, a subset of certificates issued by a CA
> can
> > be stored in the reverse component of crossCertificatePair attribute
> of
> > the issuing CA."
> > 
> > 	Please note that to me subset includes none, some, or all.  If
> > folks want further clarification, it is ok by me.
> > 
> Santosh, the only issue I have with this text is that (at least with
> the
> rationale behind option 2) any cert that appears in the cACertificate
> attribute of a given CA
> entry, should also appear in the crossCertificatePair attribute in the
> same
> CA entry.
>  What about deleting the reference to the cACertificate attribute from
> your
> text and proposing this as new text just for the crossCertificatePair
> attribute? 
> 
> Both Jan and David have indicated reasons to keep the "pair" together
> in the
> mutual case, so we should also consider adding the last paragraph of
> the
> text David proposed for that.  
> 
> Here's what the resulting text proposal would look like:
> 
> > " A certificate issued to a CA by another shall be stored in the
> > forward component of crossCertificatePair attribute of
> > the subject CA.  Optionally, a subset of certificates issued by a CA
> can
> > be stored in the reverse component of crossCertificatePair attribute
> of
> > the issuing CA. When both elements are present in the same value,
> the
> > value shall represent a mutual cross-certification of the two CAs. "
> > 
> If we can come to consensus on that attribute, then let's see what we
> can do
> with the cACertificate attribute text.
> 
> I agree with your view on what a subset is and I think that same
> definition
> would apply to the contents of the cACertificate attribute as a subset
> of
> the crossCertificatePair forward elements in option 2.

From: Alan Lloyd <[email-masked]>
To: "'Mike Smith '" <[email-masked]>, "[email-masked] '" <[email-masked]>, Alan Lloyd <[email-masked]>, "'Phillip M Hallam-Baker '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OFF TOPIC ???? RE: Relational vs Directory Repository Models  (was RE: pathdevelopment complexity s)
Date: Wed, 9 Sep 1998 19:22:02 +1000
Sender: [email-masked]

Thanks for the reply - comments in line. 

----------
From: Phillip M Hallam-Baker
To: Mike Smith; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 9/9/98 1:50:46 AM
Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models
(was RE: pathdevelopment complexity s)

Ph: I'm having a lot of trouble following this discussion. It appears to
have begun a discussion of the relative merits of X.500 vs LDAP server
models.
This does not appear to be something which is relevant to PKIX.
LDAP is merely a protocol. It does not define a product. Arguments based
on the 'scalability' of a client-server protocol are almost without
exception irrelevant since scaling depends on server-server
communication. The idea that the same protocol should serve both
purposes is questionable at best.

alan: LDAP is just a protocol! That statement is curious given that
features in protocol impact the system services that are conveyed to
and available from " the protocol". eg. Replicated/Master certfificates
.. How does LDAP get the Master copy of a certficate when it needs that.
If the certficate happens to be outside the "domain of interest" how
does LDAP control the extent of a search re Chaining.. It can not. If
one is trying to build large scale certficate based systems supported by
directory services, then "the protocol" used will affect the trust and
performance of the system services applied.. LDAP does not deal with
distributed systems - it deals with client interfaces to seperate
servers. Cert Matching Rules and LDAP (non X.500)servers? - ask the
vendors.

Ph:I fail to see how improved search capabilities will greatly assist
for the purposes of PKIX unless the directories have the ability to
break open, readand understand attributes embedded in certificates. If
people believe that support for a specific (and specified) search
mechanism would lead to an improvement in efficiency that is important
to PKIX let us discuss thatspecific extension.

alan: See X.500/9 certficate matching rules, see the draft I posted last
week. Cert and CRL matching rules can, in fact are intended to assist
the management and validation of certificates. They should be applied to
this end. As said in my draft, it seems pointless trying to get a client
to understand all the information and revocation designs of any CA that
might exist on this planet.
X.509 is part of X.500 and the application of X.509 to be scaleable
depends on the use and features of a directory services. The emphasis to
date on CA design has been.. information objects for CA functions that
"may" use a directory.
OCSP is symptomatic of this approach ie. no directory service is
considered. This = special client software and special servers and
special CA databases. Hardly an approach for the large scale of the
internet, the use of distributed, scaleable EC services and simple
clients.

To build a generalised, efficient, scaleable certificate infrastructure,
X.500 directory systems (not LDAP servers) are fundamental. With added
matching rules and common CA information doctrines (as applied to their
DIBs) the PKIX problem is very solveable.

Ph: We need to remember that we are charterted as an IETF working group
and weare not in a position to endorse a particular directory strategy.

alan: Well if "we" are chartered to build a car and it wants to be used,
by definition should we not be making sure that the roads and wheels are
in place. (eg directory systems). ie. when anything is designed,
assumptions or statements about underlying (scaleable) services should
be made.

Ph: If we want to be able to offload client work to a server of some
kind we should first consider the requirements that motivate such an
architectural approach and the trust implications of doing so before
considering protocol extensions. Indeed a critical step would be
deciding which protocol to base an implementation on.

Alan: X.500 was designed to deal with this issue (see X.500 1993 cert
and CRL matching rules).
There is no direct extension to the protocol" its the addition of convey
service requirements and modified directory matching rule support.

As for trust - then there is no trust in multitudes of chaotic CA
information designs and complex clients that cannot verify certs for
specific application and originator/recipient contexts.

Finally - it seems a lot of the work on PKIX has been made so complex
because of the limitations in LDAP, LDAP servers and "non directory
system" application, eg OCSP, eg, . Taking X.500 infrastructure away
from X.509 is like taking the wheels off a car and then trying to fix
the car's resulting problems.

So IMHO - if the charter of this group is to build a certficate
infrastructure for the internet - should we not follow industry trends
with directories ie LDAP or DAP access to X.500 that incorporates X.509?

And extend this as per dir-cert-stat draft to make it scaleable and
efficient.

Thoughts are welcome.

regards alan

		Phill

Date: Tue, 08 Sep 1998 22:17:20 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Ed Posnak <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: OCSP in Chicago
Sender: [email-masked]

Hi Ed,
    Please take a look at section 4.4.4 (Archive Cutoff). See if
that addresses your concerns.

4.4.4 Archive Cutoff

An OCSP responder MAY choose to retain revocation information beyond a 
certificate’s expiration. The date obtained by subtracting this 
retention interval value from the producedAt time in a response is 
defined as the certificate’s “archive cutoff” date.

OCSP-enabled applications would use an OCSP archive cutoff date to 
contribute to a proof that a digital signature was (or was not) reliable 
on the date it was produced even if the certificate needed to validate 
the signature has long since expired.

OCSP servers that provide support for such historical reference SHOULD 
include an archive cutoff date extension in responses.  If included, 
this value SHALL be provided as an OCSP singleResponse extension  
identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime:

id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

archiveCutoff ::= GeneralizedTime

To illustrate, if a server is operated with a 7-year retention interval 
policy and status was produced at time t1 then the value for 
archiveCutoff in the response would be (t1 - 7 years).

Regards,
Ambarish

Ed Posnak wrote:
> 
> Does the following still apply to a "Good" status?
> 
> [from version 05] "... it is quite possible that an OCSP responder
> returns the notRevoked state if a certificate was revoked, but has since
> expired (equivalent to a serial number being dropped from the CRL). "
> 
> If so, perhaps the above sentence shouldn't have been dropped from the
> description?
> 
> ejp

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

Date: Tue, 08 Sep 1998 23:44:10 -0400
To: Pavel Krylov <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: depth
Cc: [email-masked]
Sender: [email-masked]

In researching this for IPSec, I've heard a depth of approximately four being used, and of course a single root, and sporadic use of deeper trees, as far as 8.

At 12:35 AM 9/8/98 +0400, you wrote:
>
>My question:
>        What depth of certificate tree is exist now?? Average value?
>
>Sharon, Santosh? 
>
>---------------------------------------
>Pavel V.Krylov          [email-masked]
> 

Date: Tue, 08 Sep 1998 18:27:51 -0700
From: Ed Posnak <[email-masked]>
Organization: Xetex Corporation
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: OCSP in Chicago
Sender: [email-masked]

Does the following still apply to a "Good" status?

[from version 05] "... it is quite possible that an OCSP responder
returns the notRevoked state if a certificate was revoked, but has since
expired (equivalent to a serial number being dropped from the CRL). "

If so, perhaps the above sentence shouldn't have been dropped from the
description?

ejp

Date: Tue, 08 Sep 1998 18:07:20 -0400
To: "[email-masked]'" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 08 Sep 1998 15:02:30 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: OCSP in Chicago
Sender: [email-masked]

Hi All,

For the benefit of those who were not in Chicago, it was resolved
that the symbol for notRevoked be changed to good. We have put
in the following explanation of the good state:

The "good" state indicates a positive response to the status inquiry. 
At a minimum, this positive response indicates that the certificate is
not revoked, but does not necessarily mean that the certificate was ever
issued or that the producedAt time is within the certificate's validity
interval. Response extensions may be used to convey additional
information on assertions made by the responder regarding the status of
the certificate such as positive statement about issuance, validity,
etc.).

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: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 17:46:01 -0400 
Sender: [email-masked]

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 8, 1998 10:05 AM
> To: 	'Sharon Boeyen'; [email-masked]'
> Subject: 	RE: forward & reverse elements - population
> 
	--stuff deleted
> > 
> 	[]  I agree.  I do not have problem with the following language.
> " A certificate issued to a CA by another shall be stored either in the
> caCertificate or forward component of crossCertificatePair attribute of
> the subject CA.  Optionally, a subset of certificates issued by a CA can
> be stored in the reverse component of crossCertificatePair attribute of
> the issuing CA."
> 
> 	Please note that to me subset includes none, some, or all.  If
> folks want further clarification, it is ok by me.
> 
Santosh, the only issue I have with this text is that (at least with the
rationale behind option 2) any cert that appears in the cACertificate
attribute of a given CA
entry, should also appear in the crossCertificatePair attribute in the same
CA entry.
 What about deleting the reference to the cACertificate attribute from your
text and proposing this as new text just for the crossCertificatePair
attribute? 

Both Jan and David have indicated reasons to keep the "pair" together in the
mutual case, so we should also consider adding the last paragraph of the
text David proposed for that.  

Here's what the resulting text proposal would look like:

> " A certificate issued to a CA by another shall be stored in the
> forward component of crossCertificatePair attribute of
> the subject CA.  Optionally, a subset of certificates issued by a CA can
> be stored in the reverse component of crossCertificatePair attribute of
> the issuing CA. When both elements are present in the same value, the
> value shall represent a mutual cross-certification of the two CAs. "
> 
If we can come to consensus on that attribute, then let's see what we can do
with the cACertificate attribute text.

I agree with your view on what a subset is and I think that same definition
would apply to the contents of the cACertificate attribute as a subset of
the crossCertificatePair forward elements in option 2.

From: "Fuerst, Neal" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FOR Option 2
Date: Tue, 8 Sep 1998 11:05:12 -0500 
Sender: [email-masked]

Thanks.

Neal Fuerst
Information Security Analyst
Compaq Computer Corporation
E-Mail: [email-masked]
Phone: 281.518.8072
Pager: 713.509.4586

Entrust validation string: OMCO-KGMF-KQZN
"No matter how paranoid you are, you're not paranoid enough."

From: "PACHL, Jan" <[email-masked]>
To: "'David Boyce'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population 
Date: Tue, 8 Sep 1998 12:37:04 -0700
Sender: [email-masked]

in response to:
>From: 	David Boyce[SMTP:[email-masked]]
>"PACHL, Jan" writes:
>>If the forward and the reverse element are never both present in the
>>same pair (=either one is present or the other, but never both, in any
>>given pair), what is the point of having the attribute defined as
>>"pair"?
>>In that case it would make better sense to have two separate attributes
>>instead -- "forward certificate" and "reverse certificate".
>
>Well, we are trying to work with the defined X.509 attributes, so
>creating new ones which duplicate existing definitions will just muddy
>things further.  I agree, though, that things might have been 
>different.
>
Yes, I agree we should work with the defined attributes.
Presumably the crossCertificationPair attribute was defined as a pair
(and not as two separate attributes) for a good reason.

Jan Pachl
>SHL Systemhouse

From: Daya Puls <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 15:36:23 -0400 
Sender: [email-masked]

Daya Puls, CISSP
Intelligent Infrastructure Security Architect
COMPAQ, IM Security 
40 Old Bolton Road, OGO1-2/V12, Stow, MA 01775-1299
Fon: 978-496-9560, Fax: 978-496-9191, Eml: [email-masked]

From: [email-masked]
Subject: For Option 2
To: [email-masked] (IETF PKIX)
Date: Tue, 8 Sep 1998 15:23:54 +0000 ()
Sender: [email-masked]

From: [email-masked]
To: ietf-pkiximcorg <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 12:09:50 -0500
Sender: [email-masked]

Date: Tue, 08 Sep 1998 12:20:47 -0400
To: [email-masked]
From: [email-masked] (David Giglio)
Subject: For option 2
Sender: [email-masked]

___________________________________________________________________
David Giglio - Senior Product Manager 
Bay Networks, Inc.                Access Server Div.
M/S BL8-05                        [email-masked]
5 Federal Street                  978-916-4234 Office
Billerica, MA 01821               978-916-4782 Fax		

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Date: Tue, 8 Sep 1998 11:50:46 -0400
Importance: Normal
Sender: [email-masked]

I'm having a lot of trouble following this discussion. It appears to have
begun a discussion of the relative merits of X.500 vs LDAP server models.
This does not appear to be something which is relevant to PKIX.

LDAP is merely a protocol. It does not define a product. Arguments based on
the 'scalability' of a client-server protocol are almost without exception
irrelevant since scaling depends on server-server communication. The idea
that the same protocol should serve both purposes is questionable at best.

I fail to see how improved search capabilities will greatly assist for the
purposes of PKIX unless the directories have the ability to break open, read
and understand attributes embedded in certificates. If people believe that
support for a specific (and specified) search mechanism would lead to an
improvement in efficiency that is important to PKIX let us discuss that
specific extension.

We need to remember that we are charterted as an IETF working group and we
are not in a position to endorse a particular directory strategy.

If we want to be able to offload client work to a server of some kind we
should first consider the requirements that motivate such an architectural
approach and the trust implications of doing so before considering protocol
extensions. Indeed a critical step would be deciding which protocol to base
an implementation on.

		Phill

From: [email-masked]
To: ietf-pkiximcorg <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 10:41:10 -0500
Sender: [email-masked]

To: "PACHL, Jan" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: forward & reverse elements - population 
Date: Tue, 08 Sep 1998 16:38:15 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

"PACHL, Jan" writes:
>If the forward and the reverse element are never both present in the
>same pair (=either one is present or the other, but never both, in any
>given pair), what is the point of having the attribute defined as
>"pair"?
>In that case it would make better sense to have two separate attributes
>instead -- "forward certificate" and "reverse certificate".

Well, we are trying to work with the defined X.509 attributes, so
creating new ones which duplicate existing definitions will just muddy
things further.  I agree, though, that things might have been 
different.

>I can see some (limited?) use for populating both forward and reverse 
in
>the same pair, to record mutual certification.  Not primarily for path
>discovery, but for answering other questions about certification
>relationships.

Yes.  What I was trying to do was begin to pin down what it means when
both elements are present in the same value, and conscious mutual
certification seems an appropriate use. 

I suppose PKIX could specify that conforming CAs should not populate
both elements in a value, but that applications processing the values
for path development should not assume only one element is present.

I note that the X.509 certificatePairExactMatch matching rule doesn't
appear to cater for specifying 'values matching a forward certificate
assertion which have no reverse certificate', or vice versa.
Consequently, it may not be possible (using that Matching Rule, at
least) to obtain ONLY the forward certificates.

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

To: Sharon Boeyen <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: forward & reverse elements - population 
Date: Tue, 08 Sep 1998 16:36:43 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

Sharon Boeyen writes:

>3 - One more issue raised by David Boyce's proposed text was 
population of
>the crossCertificatePair attribute in the case where certification 
between
>two CAs is mutual. The syntax of the crossCertificatePair attribute is 
such
>that a single value of the attribute is one of the following:
>- only a forward element
>- only a reverse element
>- both a forward and reverse.
>
>I wonder though when one would be interested in retrieving a value 
that had
>both forward and reverse present? Does anyone have an example of a
>requirement for this?

I can think of one example where population of both elements could be
helpful for path development: the case when a strong bind request is
received which contains just a signature, so that a certificate path has
to be developed locally in order to verify the signature.

If during this development, a mutual certificate pair is encountered, it
might act as a hint that this is a good way to develop a certification
path in the opposite direction for use when responding to the bind
(assuming the responder intends to supply a certificate path in its
response).  Without this hint, building this path would be harder.

> When doing path discovery, regardless of the
>algorithm, wouldn't you be interested in one of the forward or reverse 
only
>for a given operation? If that is true then wouldn't it be better not 
to
>populate both forward and reverse in a single value but even in the 
case of
>mutual certification, spread these certificates over different values 
of the
>attribute? The reason I'm wondering about this is that the smallest 
unit of
>information that LDAP can return is a whole attribute value (can't 
pull only
>a forward or only a reverse from a single value). I'm trying to come 
up any
>reason for wanting the two together in the mutual case and having 
trouble
>coming up with a requirement. Again, when we get to the point of using
>LDAPv3 and more complex filtering capabilities, we may get to a point 
where
>we can retrieve single certs from the crossCertificatePair attribute, 
but if
>both forward and reverse are populated in the same attribute value, 
you'll
>get both certs. Views?

I don't think that LDAPv3 will give you any finer-grained control over
what is returned either.  It would require transporting less than a
whole value of an attribute, and it's hard to see how this would be
something LDAPv3 would want to define.  For path development purposes, I
agree it's a pity to have to transport the reverse certificate with the
forward, only to discard it because it's of no interest;  but there it
is.

Some may feel that this bandwidth issue is enough to rule out populating
both elements.  It doesn't actively get in the way of path development,
however, and there may be a meaningful population of both elements.

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-10.txt
Date: Tue, 08 Sep 1998 11:02:09 -0400
Sender: [email-masked]

--NextPart

Note: This revision reflects comments received during the last call period.

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 Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, T. Polk, D. Solo 
	Filename	: draft-ietf-pkix-ipki-part1-10.txt
	Pages		: 129
	Date		: 04-Sep-98
	
   This is the tenth draft of the Internet Public Key Infrastructure
   X.509 Certificate and CRL Profile.  This draft is the result of
   Working Group Last Call, and includes modifications to reflect the
   group's final 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.

Internet-Drafts are 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-ipki-part1-10.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-10.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-part1-10.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-ipki-part1-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part1-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: [email-masked]
To: [email-masked]
Date: Tue, 8 Sep 1998 10:55:28 -0400
Subject: For Option 2
Sender: [email-masked]

Jean Bernatchez
09/08/98 10:55 AM

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 10:05:30 -0400
Sender: [email-masked]

comments in-line.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Monday, September 07, 1998 8:02 PM
> To:	[email-masked]'
> Subject:	forward & reverse elements - population
> 
> Three related  issues:
> 
> 1 - raised by Denis - need to clarify how one way certification of a
> CA to
> another CA is represented in the crossCertificationPair attribute (as
> opposed to bilateral)
> 
> Denis - would adding some text along the lines of that proposed by
> David
> Boyce (that at least one of the forward or reverse elements must be
> present
> in a value of the crossCertificatePair attribute) satisfy that?
> 
> 2 - raised by Santosh -  population of the reverse element of the
> crossCertificatePair attribute not to be mandated.
> 
> Santosh, I tend to agree with this. I'm curious whether you (and
> others)
> think we can mandate, especially in a schema spec, that the forward
> certificates be published by the subject CA either? Is a schema spec
> really
> the place to dictate CA behaviour? Or should the schema spec provide
> the
> tools to be used for publishing the certs, should the CA decide to
> publish
> them. 
> 
	[]  I agree.  I do not have problem with the following language.
" A certificate issued to a CA by another shall be stored either in the
caCertificate or forward component of crossCertificatePair attribute of
the subject CA.  Optionally, a subset of certificates issued by a CA can
be stored in the reverse component of crossCertificatePair attribute of
the issuing CA."

	Please note that to me subset includes none, some, or all.  If
folks want further clarification, it is ok by me.

> In the case of option 2, if we mandate neither, the
> crossCertificatePair
> attribute would contain all the certificates of the forward and
> reverse
> types that this CA has decided to publish. The content of the
> cACertificate
> attribute would still be a subset of the content of the
> crossCertificatePair
> attribute plus self issued certificates. This would result in a
> situation
> where some certificates would be published only in the issuing CAs
> entry,
> some only in the subject CAs entry and others in both. But in all
> cases a
> relying party would be able to find them in the crossCertificatePair
> attribute and if the relying party understood the CAs definition of
> domain
> they could take advantage of the subset published in that CAs
> cACertificate
> attribute.
> 
> Do you think this reflects the real business needs or do you think we
> need
> to mandate that the subject CA publish forward certificates issued for
> it? I
> lean toward not mandating either, but can go along with either
> approach on
> this one.
> 
> 3 - One more issue raised by David Boyce's proposed text was
> population of
> the crossCertificatePair attribute in the case where certification
> between
> two CAs is mutual. The syntax of the crossCertificatePair attribute is
> such
> that a single value of the attribute is one of the following:
> - only a forward element
> - only a reverse element
> - both a forward and reverse.
> 
> I wonder though when one would be interested in retrieving a value
> that had
> both forward and reverse present? Does anyone have an example of a
> requirement for this? When doing path discovery, regardless of the
> algorithm, wouldn't you be interested in one of the forward or reverse
> only
> for a given operation? If that is true then wouldn't it be better not
> to
> populate both forward and reverse in a single value but even in the
> case of
> mutual certification, spread these certificates over different values
> of the
> attribute? The reason I'm wondering about this is that the smallest
> unit of
> information that LDAP can return is a whole attribute value (can't
> pull only
> a forward or only a reverse from a single value). I'm trying to come
> up any
> reason for wanting the two together in the mutual case and having
> trouble
> coming up with a requirement. Again, when we get to the point of using
> LDAPv3 and more complex filtering capabilities, we may get to a point
> where
> we can retrieve single certs from the crossCertificatePair attribute,
> but if
> both forward and reverse are populated in the same attribute value,
> you'll
> get both certs. Views?
> 
> 
> 
> 
> ------------------
> Sharon Boeyen                  
> Entrust Technologies
> 
> mailto:[email-masked]  Tel: (613) 247-3181 
> http://www.entrust.com            Fax: (613) 247-3690 
>        

From: [email-masked]
To: [email-masked]
Subject: For Option 2
Date: Tue, 8 Sep 1998 10:03:01 -0400
Sender: [email-masked]

To whom it may concern, 

For Option 2. 

Regards, 

J.P. Lachance 
Senior Systems Engineer 
PMO GOC PKI 
Communications Security Establishement 
Tel: 613-991-7504 
Fax: 613-991-7455 
Internet: [email-masked]

From: "PACHL, Jan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 08:58:19 -0500
Sender: [email-masked]

If the forward and the reverse element are never both present in the
same pair (=either one is present or the other, but never both, in any
given pair), what is the point of having the attribute defined as
"pair"?
In that case it would make better sense to have two separate attributes
instead -- "forward certificate" and "reverse certificate".

I can see some (limited?) use for populating both forward and reverse in
the same pair, to record mutual certification.  Not primarily for path
discovery, but for answering other questions about certification
relationships.

Jan Pachl
SHL Systemhouse

>From: 	Sharon Boeyen[SMTP:[email-masked]]
>[ ... ]
>
>3 - One more issue raised by David Boyce's proposed text was population of
>the crossCertificatePair attribute in the case where certification between
>two CAs is mutual. The syntax of the crossCertificatePair attribute is such
>that a single value of the attribute is one of the following:
>- only a forward element
>- only a reverse element
>- both a forward and reverse.
>
>I wonder though when one would be interested in retrieving a value that had
>both forward and reverse present? Does anyone have an example of a
>requirement for this? When doing path discovery, regardless of the
>algorithm, wouldn't you be interested in one of the forward or reverse only
>for a given operation? If that is true then wouldn't it be better not to
>populate both forward and reverse in a single value but even in the case of
>mutual certification, spread these certificates over different values of the
>attribute? The reason I'm wondering about this is that the smallest unit of
>information that LDAP can return is a whole attribute value (can't pull only
>a forward or only a reverse from a single value). I'm trying to come up any
>reason for wanting the two together in the mutual case and having trouble
>coming up with a requirement. Again, when we get to the point of using
>LDAPv3 and more complex filtering capabilities, we may get to a point where
>we can retrieve single certs from the crossCertificatePair attribute, but if
>both forward and reverse are populated in the same attribute value, you'll
>get both certs. Views?
>
>

From: [email-masked]
To: [email-masked]
Subject: For Option 2
Date: Tue, 8 Sep 1998 09:07:44 -0400
Sender: [email-masked]

From: [email-masked]
To: [email-masked]
Subject: For option 2
Date: Mon, 7 Sep 1998 09:34:21 -0400
Sender: [email-masked]

Date: Tue, 08 Sep 1998 07:23:34 -0400
To: [email-masked]
From: "John A. DiDuro" <[email-masked]>
Subject: for Option 2
Sender: [email-masked]

From: Jeremy Bingham <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:12:07 -0400
Sender: [email-masked]

Date: Tue, 08 Sep 1998 10:26:20 +0200
From: Ton van Lieshout <[email-masked]>
Reply-To: [email-masked]
Organization: Point Information Systems B.V.
To: [email-masked]
Subject: FOR OPTION 2
Sender: [email-masked]

As an Entrust prtner, we vote for option 2.

Ton van Lieshout
Technical Director

From: =?iso-8859-1?Q?Svein_L=F8seth?= <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:05:31 +0100
Sender: [email-masked]

---------------------------------------------------------------------------------------------------------------------------
Svein Løseth						Tlf.:    +47-22 95 86 83
Network Security AS					Fax:    +47-22 60 44 27
Gaustadalléen 21				    Dir. Line:    +47-22 95 85 48
N-0371 OSLO						GSM: +47-91 77 09 63
NORWAY						http://www.security.no

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: forward & reverse elements - population
Date: Mon, 7 Sep 1998 20:01:30 -0400 
Sender: [email-masked]

Three related  issues:

1 - raised by Denis - need to clarify how one way certification of a CA to
another CA is represented in the crossCertificationPair attribute (as
opposed to bilateral)

Denis - would adding some text along the lines of that proposed by David
Boyce (that at least one of the forward or reverse elements must be present
in a value of the crossCertificatePair attribute) satisfy that?

2 - raised by Santosh -  population of the reverse element of the
crossCertificatePair attribute not to be mandated.

Santosh, I tend to agree with this. I'm curious whether you (and others)
think we can mandate, especially in a schema spec, that the forward
certificates be published by the subject CA either? Is a schema spec really
the place to dictate CA behaviour? Or should the schema spec provide the
tools to be used for publishing the certs, should the CA decide to publish
them. 

In the case of option 2, if we mandate neither, the crossCertificatePair
attribute would contain all the certificates of the forward and reverse
types that this CA has decided to publish. The content of the cACertificate
attribute would still be a subset of the content of the crossCertificatePair
attribute plus self issued certificates. This would result in a situation
where some certificates would be published only in the issuing CAs entry,
some only in the subject CAs entry and others in both. But in all cases a
relying party would be able to find them in the crossCertificatePair
attribute and if the relying party understood the CAs definition of domain
they could take advantage of the subset published in that CAs cACertificate
attribute.

Do you think this reflects the real business needs or do you think we need
to mandate that the subject CA publish forward certificates issued for it? I
lean toward not mandating either, but can go along with either approach on
this one.

3 - One more issue raised by David Boyce's proposed text was population of
the crossCertificatePair attribute in the case where certification between
two CAs is mutual. The syntax of the crossCertificatePair attribute is such
that a single value of the attribute is one of the following:
- only a forward element
- only a reverse element
- both a forward and reverse.

I wonder though when one would be interested in retrieving a value that had
both forward and reverse present? Does anyone have an example of a
requirement for this? When doing path discovery, regardless of the
algorithm, wouldn't you be interested in one of the forward or reverse only
for a given operation? If that is true then wouldn't it be better not to
populate both forward and reverse in a single value but even in the case of
mutual certification, spread these certificates over different values of the
attribute? The reason I'm wondering about this is that the smallest unit of
information that LDAP can return is a whole attribute value (can't pull only
a forward or only a reverse from a single value). I'm trying to come up any
reason for wanting the two together in the mutual case and having trouble
coming up with a requirement. Again, when we get to the point of using
LDAPv3 and more complex filtering capabilities, we may get to a point where
we can retrieve single certs from the crossCertificatePair attribute, but if
both forward and reverse are populated in the same attribute value, you'll
get both certs. Views?

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Mon, 07 Sep 1998 15:30:57 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: PKIX freeware library coming soon (fwd)
Sender: [email-masked]

At 12:49 AM 9/8/98 +0200, Monica Pietrosanu-Ene wrote:
>Any recent news related to that freeware library?
>I searched the MIT site and I didn't find anything related to that
implementation. It should be available by the end of August, isn't it?

There is a new mailing list to discuss the library. Please see
<http://www.imc.org/imc-pfl/> for more information on the mailing list and
the library. I've been told that the folks making the library are
almost-almost ready to release the first version (they can't turn the page
on their calendars to September until they do...). At that point, the new
mailing list for the library should become active.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: Mike Smith <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 7 Sep 1998 11:59:43 -0700
Subject: Re: Relational vs Directory Repository Models (was RE: path development complexity s)
Sender: [email-masked]

and with an intelligent repository, along with assumptions about knowing
every
use to contain risk/liability exposures and provide timely status ... and a
nudge in the protocol
here & there ... it becomes account authority instead of certification
authority
client gets even thinner ... and account authority provides enhanced value
transaction (most of the certificates are redundant/superfluous).

Date: Mon, 07 Sep 1998 21:35:28 +0400 (MSK DST)
From: Pavel Krylov <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: depth
Sender: [email-masked]

My question:
        What depth of certificate tree is exist now?? Average value?

Sharon, Santosh? 

---------------------------------------
Pavel V.Krylov          [email-masked]

Date: Mon, 07 Sep 1998 11:23:32 -0600
From: Mike Smith <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Re relational - and Dirs and all that
Sender: [email-masked]

Thanks for the remedial lesson.  We also tend towards business objects in design and implmentation.  

I too, think that these hybrid systems are the direction of the future.

michael

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re relational - and Dirs and all that
Date: Tue, 8 Sep 1998 03:01:12 +1000
Sender: [email-masked]

Alan: Mike the amazing thing is I am in Charlotte US and working remote
to Aus. I had to repaste the text as I got an error? in the long
distance server?
Comments in line marked Alan. 

Quick response from so far away, I am still amazed at this Internet
technology, even though I've been relying on it daily, since the early
'80s.  :)

Alan: I have been relying on since 9.00 AM this morning :-)

Mike: With an X500 model, then one would have to create the directory
service agents (DSA) to actually process the requests.  My limited
understanding of how these work makes it complex indeed to process
through multiple
layers from one DSA to another (using DAP to cahin to other
"directories").

Alan: Directories are distributed, object oriented, named based
transaction systems. They operate on distributed naming contexts with
objects such as  people (that have certs) and CAs that have certs.
Directories to us are the foundation for new forms distributed
information engineering. (However, LDAP servers (non X.500 ones) do not
do distribution - so watch out for the scaling issues with those
things).
Most think LDAP servers are the only forms of directories and because
they have distribution issues - it means that all directories have
distribution issues - X.500 (which can have LDAP access) does not have
these, therefore the information solution space is wider than LDAP
server only systems.

Mike: Server side logic, whether stored procedures, external routines or
objects from an Application Server, seems less complex for development
of client server applications with thin clients, since the variety of
tools and supporting technology is so available.  My "take" on X500
models is that the directory system was designed for thin servers and
thin cleints (thinner clients with the original LDAP, fatter clients
(almost DAP) with the current LDAP models).   Now, the discussion seems
to be on how fat (huge) and intelligent (brilliant) to make the clients.

Alan: Thin and fat seems can get mixed up these days. There is the
stacks - LDAP  is about 230kb and DAP which is about 130kb. LDAP on
bigger searches becomes less efficient and DAP has features that deal
with master/copy entries and controlling chaining ie. DAP has twice
(scaleable) the functionality than LDAP. 
In terms of "processing" above the stack - LDAP clients do more because
they have to chase referrals (no chaining in the servers) and with the
LDAP servers (non X.500 ones) if one wants to authenticate users one has
to replicate everything to everywhere. ie. what LDAP does not do that
X.500 does.. Humans have to.

Mike: As you have discovered, a relational DBMS can perform all of the
functions of the X.500 requirements and a whole lot more.  

Alan: But X.500 deals correctly with object oriented engineering,
distributed name based systems and scaling. There is a difference. DBMSs
deal with data management with integrity (as well as many other
things)they (RDBs) do not distribute or scale in the same way-   X.500
is about protected distributed object oriented engineering. We have put
the both together (RDBs and X.500) - in fact we have made commercial
RDBMs extremely fast and distributed object oriented system that is
conformant to X.500 (with LDAP access and provides LDAP server
interconnectivity).

Mike: As a business-focused technologist, I also like the easier
integration of an RDBMS-engined repository with the RDBMS' that are used
to run the business  (I know some Directory schemes output data to RDBMS
- some may even allow two-way communication).  I like the idea of
searching multiple RDBMS sources in one query instead of chaining DSA to
DSA - I also think the logic can be more comprehensive.  By
comprehensive, let's say against a rule set that can contain more than
one decision matrix, maybe with some knowledge-based intelligence
acquired from yet another DBMS.  I can envision a central-responder
repository model that "handles" simple requests for path building that
get as complex as necessary across hierarchical, cross-certified, policy
mapped, Web of trust, personal trust, bilaterally agreed relationships
AND others yet to be defined. 

Alan: I am a very business focussed technologist and believe that OO
distributed systems are required and that these will integrate with RDBs
where appropriate (eg. Legacy systems or where relational requirements
extend beyond those as affored with OO/RDB systems (like our directory).
We provide a range of tools for RDBs and LDIF interchange and
integration.

Mike: Relationship management becomes the central repository's concern,
not that of the relying party.  The relying party needs a business
relationship with the central repository, or their CA (issuer) does.
Contracts and agreements amongst the players need to exist for a central
system to work, but there are business models that can support highly
complex relationship structures.

Alan: Some - repeat some of this can be designed with directories and OO
structures.

Mike: I tend to think of how to incorporate a workable PKI into an
electronic commerce scenario that may involve business relationships
with thousands of companies, hundreds of financial institutions and
their millions of customers.  

Alan: We do - in fact we scale to these requirements.

Mike: In all probability, this means working with many PKI systems and
models and their varied implementations.  I do not see a system
accepting "all" certificates coming into it.  Having said that, though,
in business, its always risk vs. reward and if someone wishes to reward
(and indemnify) me enough to honor self-authenticated or other "weak"
certificates, maybe I'll need to incorporate that into my model as well.

Mike: I do not see basing a business solely on a directory, no matter
its integrity or "globalness".  I do not even see basing a directory
service business solely on an X.500 directory.

Alan: Some do now - the trend is to have distributed systems and basing
these on scaleable - mutually authenticated OO - X.500 technologies.
However, this does not mean that some centralised RDB applications wont
exist - they will in our view become "directory enabled" so they can
interwork with WEB/RDB/OO(X.500)business information infrastructures
that support a range of authenticated role based people and
applications.
This is the new approach to business information system modelling - and
this also includes multi - distributed CA/PKI functions.

I do find business uses for directory-structured systems, but find the
duplication of data and differing and costly development environment
(ASN.1 vs C++, ProC, SQL, Java, or whatever) annoying.  I look towards
enterprise services for customers and employees that incorporates PKI -
not to PKI as something totally separate.

Alan: Absolutely

So, that's the origin of my comments on relational "vs." directory.  I
really think that there should be a synthesis, not an opposition.

Since both LDAP and X.500 and X.509 (with version 3) are independent of
the directory model and technology,
 
Alan: Dont quite agree - X.509 will not go far without X.500.

if we think "outside the X.500 box", then we can use the strengths of
the X.500 directory model and add on some strenghts in logic processing
from the tools in the RDBMS world.

Alan: We did and we have and we do - see Integrated Information
Infrastructures.
I will send a paper off list.

 That way, one can support LDAP, DAP, Java Applets, integrated client
applications, or whatever development technology becomes available
across IP to meet constantly changing business requirements.

Alan: Agree

Alan: Regards alan

  Michael 

Snip..

Date: Mon, 07 Sep 1998 10:01:25 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Sender: [email-masked]

Quick response from so far away, I am still amazed at this Internet technology, even though I've been relying on it daily, since the early '80s.  :)

With an X500 model, then one would have to create the directory service agents (DSA) to actually process the requests.  My limited understanding of how these work makes it complex indeed to process through multiple layers from one DSA to another (using DAP to cahin to other "directories").

Server side logic, whether stored procedures, external routines or objects from an Application Server, seems less complex for development of client server applications with thin clients, since the variety of tools and supporting technology is so available.  My "take" on X500 models is that the directory system was designed for thin servers and thin cleints (thinner clients with the original LDAP, fatter clients (almost DAP) with the current LDAP models).   Now, the discussion seems to be on how fat (huge) and intelligent (brilliant) to make the clients.

As you have discovered, a relational DBMS can perform all of the functions of the X.500 requirements and a whole lot more.  As a business-focused technologist, I also like the easier integration of an RDBMS-engined repository with the RDBMS' that are used to run the business  (I know some Directory schemes output data to RDBMS - some may even allow two-way communication).  I like the idea of searching multiple RDBMS sources in one query instead of chaining DSA to DSA - I also think the logic can be more comprehensive.  By comprehensive, let's say against a rule set that can contain more than one decision matrix, maybe with some knowledge-based intelligence acquired from yet another DBMS.  I can envision a central-responder repository model that "handles" simple requests for path building that get as complex as necessary across hierarchical, cross-certified, policy mapped, Web of trust, personal trust, bilaterally agreed relationships AND others yet to be defined.  

Relationship management becomes the central repository's concern, not that of the relying party.  The relying party needs a business relationship with the central repository, or their CA (issuer) does.  Contracts and agreements amongst the players need to exist for a central system to work, but there are business models that can support highly complex relationship structures.

I tend to think of how to incorporate a workable PKI into an electronic commerce scenario that may involve business relationships with thousands of companies, hundreds of financial institutions and their millions of customers.  In all probability, this means working with many PKI systems and models and their varied implementations.  I do not see a system accepting "all" certificates coming into it.  Having said that, though, in business, its always risk vs. reward and if someone wishes to reward (and indemnify) me enough to honor self-authenticated or other "weak" certificates, maybe I'll need to incorporate that into my model as well.

I do not see basing a business solely on a directory, no matter its integrity or "globalness".  I do not even see basing a directory service business solely on an X.500 directory.

I do find business uses for directory-structured systems, but find the duplication of data and differing and costly development environment (ASN.1 vs C++, ProC, SQL, Java, or whatever) annoying.  I look towards enterprise services for customers and employees that incorporates PKI - not to PKI as something totally separate.

So, that's the origin of my comments on relational "vs." directory.  I really think that there should be a synthesis, not an opposition.

Since both LDAP and X.500 and X.509 (with version 3) are independent of the directory model and technology, if we think "outside the X.500 box", then we can use the strengths of the X.500 directory model and add on some strenghts in logic processing from the tools in the RDBMS world.

That way, one can support LDAP, DAP, Java Applets, integrated client applications, or whatever development technology becomes available across IP to meet constantly changing business requirements.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 9:15 AM >>>
 Mike - I am not sure if I understand your response as it mixes
technology statements.
So comments in line.

----------
From: Mike Smith
To: [email-masked]; [email-masked] 
Cc: [email-masked]; [email-masked] 
Sent: 9/8/98 12:27:08 AM
Subject: Relational vs Directory Repository Models (was RE:
pathdevelopment complexity s)

Some of you have heard this before from me and others, but, maybe it's
worth repeating at this time.

AL: Its new to me so thanks.

Complexity of the problem of path building requires a more
robust/intelligent repository. 

AL: Agree 

 Think out of the directory model and consider a relational database
behind the LDAP responder.  Per cert request times may be slower, but
the ability to work with multiple business (trust) models and supply ALL
of the necessary certs (in one query) for the most complex path
validation scenario outweighs (and maybe outperforms) a series of
client-side processing and LDAP requests.

AL: This is an implementation issue - we use a Patented SQL design under
our X.500 LDAP product and its fast including distributed (multi server)
operations.
One always scales the hardware, processing, process and DB and network
to do the job anyway.

The business logic for multiple trust models would reside on the host.
The LDAP request could be parsed, the business (trust) rules selected
according to either or both the relying party's and sender's trust
requirements.  

AL: Host - is this a server or a mainframe - this is a sizing issue? 
Perhaps a view of the system should be:

a)A distributed X.500 system with high performance (even though it uses
SQL RDBMS ) to give it industry strength and integrity.

b) LDAP or DAP (DAP is for the lucky few that want to control the scope
of directory chaining to get a cert path and getting Master cert from CA
entries:-)  ) access by the client software - with the presented cert
and the domain in which validation is required information.
Note: yet another weakness in LDAP will show up with trust/scope of cert
path processing...Somehow LDAP and LDAP servers just dont seem to mix
with X.509, certpath processing and CAs...

c) A CA that populates its portion of The interconnected DIB with CA
certs, CRLs, etc and validation information. 

d)Trusted CA utilities that run/execute on the CA "server" or "host" to
manage the CA's validation "environment".

The RDBMS and its server-side business logic can even chain requests to
other CA directories if necessary.

AL: Yes - there is nothing to stop a directory request to retrieve
something with a Search/Matching rule into subordinate objects below the
CA entry in question - via alias or cross referencing to other CAs DIBs
- but this is a bit messy re Search and Trust management. But very
achieveable with a few extensions to Results Correlation processing or
CA Utilities.

Of course, my perspective is that the business logic and trust
requirements come from the CA, not the end-user.  If the trust model
rule making is placed on the end user, then one would need to design a
pretty fat, customer customizable client software piece.

AL: Agree and totally agree. The way things were turning out with client
cert validation software is like LDAP clients have - more code in them
than in a DSA. Simply because they incorporated (lesser) distribution
handling functions - eg. referrals, replication management, etc - than
X.500 DSAs in fact do. Fat unwieldy clients are symptomatic of what
happens if one has no distributed (server) system, information and
service based model to work with.
regards alan
PS - the draft for dir cert stat will be formally circulated next week.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 7:55 AM >>>
 
Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked] 
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "'Mike Smith '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: Relational vs Directory Repository Models (was RE: pathdevelo pment complexity s)
Date: Tue, 8 Sep 1998 01:15:58 +1000
Sender: [email-masked]

 Mike - I am not sure if I understand your response as it mixes
technology statements.
So comments in line.

----------
From: Mike Smith
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 9/8/98 12:27:08 AM
Subject: Relational vs Directory Repository Models (was RE:
pathdevelopment complexity s)

Some of you have heard this before from me and others, but, maybe it's
worth repeating at this time.

AL: Its new to me so thanks.

Complexity of the problem of path building requires a more
robust/intelligent repository. 

AL: Agree 

 Think out of the directory model and consider a relational database
behind the LDAP responder.  Per cert request times may be slower, but
the ability to work with multiple business (trust) models and supply ALL
of the necessary certs (in one query) for the most complex path
validation scenario outweighs (and maybe outperforms) a series of
client-side processing and LDAP requests.

AL: This is an implementation issue - we use a Patented SQL design under
our X.500 LDAP product and its fast including distributed (multi server)
operations.
One always scales the hardware, processing, process and DB and network
to do the job anyway.

The business logic for multiple trust models would reside on the host.
The LDAP request could be parsed, the business (trust) rules selected
according to either or both the relying party's and sender's trust
requirements.  

AL: Host - is this a server or a mainframe - this is a sizing issue? 
Perhaps a view of the system should be:

a)A distributed X.500 system with high performance (even though it uses
SQL RDBMS ) to give it industry strength and integrity.

b) LDAP or DAP (DAP is for the lucky few that want to control the scope
of directory chaining to get a cert path and getting Master cert from CA
entries:-)  ) access by the client software - with the presented cert
and the domain in which validation is required information.
Note: yet another weakness in LDAP will show up with trust/scope of cert
path processing...Somehow LDAP and LDAP servers just dont seem to mix
with X.509, certpath processing and CAs...

c) A CA that populates its portion of The interconnected DIB with CA
certs, CRLs, etc and validation information. 

d)Trusted CA utilities that run/execute on the CA "server" or "host" to
manage the CA's validation "environment".

The RDBMS and its server-side business logic can even chain requests to
other CA directories if necessary.

AL: Yes - there is nothing to stop a directory request to retrieve
something with a Search/Matching rule into subordinate objects below the
CA entry in question - via alias or cross referencing to other CAs DIBs
- but this is a bit messy re Search and Trust management. But very
achieveable with a few extensions to Results Correlation processing or
CA Utilities.

Of course, my perspective is that the business logic and trust
requirements come from the CA, not the end-user.  If the trust model
rule making is placed on the end user, then one would need to design a
pretty fat, customer customizable client software piece.

AL: Agree and totally agree. The way things were turning out with client
cert validation software is like LDAP clients have - more code in them
than in a DSA. Simply because they incorporated (lesser) distribution
handling functions - eg. referrals, replication management, etc - than
X.500 DSAs in fact do. Fat unwieldy clients are symptomatic of what
happens if one has no distributed (server) system, information and
service based model to work with.
regards alan
PS - the draft for dir cert stat will be formally circulated next week.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 7:55 AM >>>
 
Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked] 
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Mon, 07 Sep 1998 08:27:08 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Relational vs Directory Repository Models (was RE: path development complexity s)
Sender: [email-masked]

Some of you have heard this before from me and others, but, maybe it's worth repeating at this time.

Complexity of the problem of path building requires a more robust/intelligent repository.  Think out of the directory model and consider a relational database behind the LDAP responder.  Per cert request times may be slower, but the ability to work with multiple business (trust) models and supply ALL of the necessary certs (in one query) for the most complex path validation scenario outweighs (and maybe outperforms) a series of client-side processing and LDAP requests.

The business logic for multiple trust models would reside on the host.  The LDAP request could be parsed, the business (trust) rules selected according to either or both the relying party's and sender's trust requirements.   

The RDBMS and its server-side business logic can even chain requests to other CA directories if necessary.

Of course, my perspective is that the business logic and trust requirements come from the CA, not the end-user.  If the trust model rule making is placed on the end user, then one would need to design a pretty fat, customer customizable client software piece.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 7:55 AM >>>
 
Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked] 
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Mon, 07 Sep 1998 15:58:39 +0200
To: "Aram Perez" <[email-masked]>, bob jueneman <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: [email-masked]
Sender: [email-masked]

Hi Aram,

Some comments follow.

At 10:17 AM 9/4/98 -0700, Aram Perez wrote:
>Bob and Stefan:
>
>>At 06:42 PM 9/2/98 -0600, Bob Jueneman wrote:
>><snip>
>>>>I suggest that we stick to the standardized definitions of the key usage
>>>>bits and leave
>>>>policy issues out of a common certificate profile.
>>>
>>>If there were any sense of the community as to what these definitions
really
>>>mean, or ought to mean, we would probably not be having this discussion.
>>>Otherwise I would agree with you.
>>>>
>>>>non-repudiation is according to standard selected by the NR bit, not NR in
>>>>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>>>>other than non-repudiation are allowed for the key.
>
>Is non-repudiation a mechanism or a service?

Sorry for my careless language. Non-repudiation is a service and that
service is not defined by the CA. However the CA may indicate that the
certificate is aimed to support that service.

>
>>>
>>>I believe that is exactly the issue. Are you suggesting that NR plus DS
>>should not
>>>be allowed?  Why?
>>
>>No I do not. I do suggest that such decision is up to local policy. But
>>there will be some policies where this combination will not be allowed, but
>>I think you agree to that.
>
>My problem with this is that to provide "digital" non-repudiation, you
have to
>"sign" something with a digital signature. I understand that the key usage
field
>is very overloaded, so I'll probably have to live with it, but I do not
agree or
>like it.

Yes and no. It is clear that X509 has mixed two levels. The mechanism level
and the service level. Looking back in the mirror that might have been a
bad mix. What's even worse is that the service bit NR in some cases is used
as an alternative to DS. To accomplish this the standard has been forced to
define both bits to a combined service/mechanism bit. I.e. NR is selecting
use of digital signatures and DS is selecting services other than
non-repudiation. This is causing the messy debate and could be used as an
argument for a defect report.

However considering the standard as it is, can we use it? Yes I think so,
even if it's not perfect. 

>
>>
>>The important thing is that I suggest that the NR bit and DS bit has
>>separate meaning and that they should be set independently to specify DS,
>>NR or both.
>>
>>The vague definition of the NR bit is a problem, I agree to that.
>
>YES!!
>
>>
>>If I were to define some distinguishing property of the NR bit that would
be:
>>
>>   Non repudiation denotes services constructed in such way that:
>>   1) The signature provides proof of the integrity and 
>>      origin of data - both in an unforgeable relationship - which can be 
>>      verified by any third party at any time.[X.509 / ISO 9594-8]
>>   2) The signature is applied to a message where the signatory is capable
>>      of, and required to, accept responsibility for the message content 
>>      before signing.
>
>But NR is set in the certificate (i.e. the public key) and does not tell you
>whether the signatory (who is using the private key) actually was capable of
>accepting responsibility.

Yes you are right, it doesn't. And it shouldn't. Since the CA isn't the
provider of that service the certificate will tell nothing about the
service in which the certificate is used. The key usage bit is a
requirement stated by the CA for staying with it's liabilities, not a
promise that the requirements will be met.

>
>>   3) The signatory's liability for signing the message can be concluded
>>      from the signed message itself, possibly within a well known and
agreed 
>>      context that can be verified by any third party at any time.
>>
>>This definitions rules out any signed logon ticket or other data
>>authentication mechanisms where the signature says "this message wasn't
>>changed" instead of "I take full responsibility for the message content".
>
>You do not need a digital signature to tell you "this message wasn't
changed".
>CRCs, LRCs, checksums, etc have been used for this longer that I've been
alive.
>You use digital signature when you want to know "this message wasn't changed"
>AND "this message came from the reported sender".
>

Agreed. I guess my point still stands.

>>
>>But since this is not defined by the bit (which I regret) the way to go
>>will be for the CA to include this in it's published certificate policy.
>
>I doubt whether a CA is going to take responsibility and liability for
something
>it has no control over. The CA does not know what applications and crypto
APIs
>the owner of the private key is using.
>

The CA will not assume responsibility for services utilizing the
certificates. It will only be liable for its issued certificates. Again,
the CA is not the provider of the NR service. Still, the CA will in some
cases state requirements on supported services. Don't forget the original
task for the CA. It is just to provide statements to be used as guidance by
certificate users.

>>
>>I can't see any other way for now when utilizing the existing standard. I
>>would not object though to a defect report to get this into the standard.
>
>And I am willing to help (or lead) in this effort.
>
>>
>>In the new proposed work item, however, regaring a profile for
>>non-repudiation certificates supporting legal acceptance of digital
>>signatures I will try to get this definition in.
>>
>>Would you support it?
>
>I would be glad to help and support it.
>
>Regard,
>Aram Perez
>Apple Computer, Inc.
>
>

/Stefan

From: Alan Lloyd <[email-masked]>
To: "'Frank O'Dwyer '" <[email-masked]>
Cc: "'Dave Horvath '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Mon, 7 Sep 1998 23:55:08 +1000
Sender: [email-masked]

Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked]
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean	s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Mon, 07 Sep 1998 14:53:16 +0200
To: Bill Brice <[email-masked]>, pkix <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Defining Non-Repudiation
Sender: [email-masked]

Bill,

Thank you for your very clarifying information. This is a very important
perspective to have when discussing standardized certificate profiles.

As you may have seen I have proposed a new work item for PKIX regarding a
specific certificate profile based on PKIX part 1 to be used in the context
you describe. The ONLY rationale for this profile is to create a common
profile for technical interoperability. Not to achieve a globally
harmonized legal framework.

The new work item, called profile for Qualified Certificates, addresses
some of your issues:
<snip>
>(2)	The certificate is considered trustworthy (i.e., an accurate 
>binding of a public key to a person's identity) because the certificate 
>was issued by a certification authority in accordance with standards, 
>procedures, and other requirements specified by the Secretary of State, 
>or the trier of fact independently finds that the certificate was issued
>in a trustworthy manner by a certification authority that properly 
>authenticated the subscriber and the subscriber's public key, or 
>otherwise finds that the material information set forth in the 
>certificate is true.

The qualified certificate will be a certificate which includes a statement
by the issuer that it meets all requirements imposed by the governing legal
framework, regardless of what that legal framework states, to support
"Secure electronic signatures" according to your definition. Further the
qualified certificate profile will enhance interoperability in naming and
other essential attributes.

It would be nice to have your view on this. The work item has primary been
raised as an answer to needs arising from the European legal framework
development. It is though conducted in a generic approach that should be
independent of any legal framework. I hope that I can count on your input
to ensure that the profile will be consistent with the American legal
approach.

/Stefan

At 03:22 PM 8/21/98 -0500, Bill Brice wrote:
>All,
>
>There has been considerable discussion and debate on these
>lists regarding the proper use of the DS and NR KeyUsage bits
>in X.509v3 certificates.
>
>Lets look at this from a legal perspective for a moment,
>since a large part of digital signatures is being able
>to place some reliance on the data that is digitally signed.
>
>In the US, private contract law is governed primarily by the
>laws of the various US states. Under the Uniform Commercial Code 
>(in effect for many years now), as enacted by US state laws, 
>a signature is defined as "any symbol executed or adopted by 
>a party with the present intention to authenticate a writing". 
>
>This means that my typed name at the bottom of this message
>constitutes a valid "signature" under the law. This is a practice
>many people use in their e-mails, and it has a binding effect
>today, under present law. Were this e-mail digitally signed, you
>"might" be able to consider it a signature, but only if it were
>consciously signed by me with the "present intention to authenticate"
>this message.
>
>As a relying party this digital signature carries no more legal
>weight that my typed signature below. In a dispute, you as the relier
>would have the burden of proof that the signature on this message,
>whether typed or digitally signed, was valid. The court and/or jury
>would have to decide whether your reliance was "reasonable under
>the facts and circumstances" of the matter. It would make no
>difference what KeyUsage bit was set.
>
>In determining "reasonable reliance" there is a broad continuum.
>In the case of the typed signature: Do you personally know me?
>What other information did you have about me? What other correspondence
>have you received from me? Do you know my address and phone
>numbers? etc. etc. In the case of the digital signature the same
>questions would apply, plus: Do you understand anything about PKI?
>Who issued the certificate? What application software did you use to
>receive and verify the message?
>
>In fact, most people outside of this mailing list would quite reasonably
>have less comfort with this message were it digitally signed as opposed
>to a typed closing signature.
>
>Woe on the first relying party to litigate a repudiated digital 
>signature. It will likely cost over US$100,000.
>
>Fortunately, there is a way out of this messy state of affairs. And
>it impacts the DS/NR question.
>
>The US State of Illinois, after 18 months of study by the Illinois
>Commission on Electronic Commerce and Crime, passed a new EC law
>(to take effect July 1, 1999) titled the "Electronic Commerce
>Security Act". This comprehensive law not only recognizes digital
>signatures as being equally valid as a UCC (above) signature, but it
>create a new class of signature called a "secure electronic signature"
>and a new class of data record called a "secure electronic record".
>
>To quote from the Commission's report: "Secure electronic records and 
>secure electronic signatures define categories of records and 
>signatures that are accorded heightened evidentiary presumptions 
>because of their enhanced reliability and trustworthiness, 
>just as notarized documents are accorded heightened evidentiary 
>presumptions for the same reason.  The concept of a secure electronic 
>record and a secure electronic signature is critical to enabling 
>electronic commerce.  Businesses will be much more willing to enter 
>into commercial transactions, extend credit, commit resources, 
>ship goods, or otherwise rely on messages from contracting parties 
>transmitted over public networks such as the Internet when they can 
>be assured that such records and signatures will be accorded the 
>heightened evidentiary presumptions necessary to effectively make 
>their transactions nonrepudiable."
>
>The effect of this is that a relying party may presume that a
>"secure electronic signature" is valid and in a dispute the burden
>of proof shifts to the signer to rebut the presumption.
>
>This is the quality we would all like in a non-repudiable 
>digital signature. It will be necessary for other jurisdictions to
>follow the Illinois lead in order to give us the PKI world we would
>want (at least as far as digisig is concerned). I would urge Petra
>to consider this approach in the German legislation.
>
>In order to achieve this GOLD CARD level of non-repudiation the law
>provides as follows:
>
>----START
>Section 10-110.  Secure electronic signature.
>
>(a)	If, through the use of a qualified security procedure, 
>it can be verified that an electronic signature is the signature of a 
>specific person, then such electronic signature shall be considered to 
>be a secure electronic signature at the time of verification, if the 
>relying party establishes that the qualified security procedure was: 
>
>      (1)	commercially reasonable under the circumstances, 
>
>      (2)	applied by the relying party in a trustworthy manner,
>and
>
>      (3)	reasonably and in good faith relied upon by the relying
>party.
>
>(b)	A qualified security procedure for purposes of this Section is a
>
>security procedure for identifying a person that is:
>
>	(1)	previously agreed to by the parties, or
>
>	(2)	certified by the Secretary of State in accordance with 
>Section 10-135 as being capable of creating, in a trustworthy manner, 
>an electronic signature that:
>
>      (A)	is unique to the signer within the context in which it
>is used;
>
>      (B)	can be used to objectively identify the person signing
>the 
>electronic record;
>
>      (C)	was reliably created by such identified person, (e.g., 
>because some aspect of the procedure involves the use of a signature 
>device or other means or method that is under the sole control of such 
>person), and that cannot be readily duplicated or compromised, and
>
>      (D)	is created, and is linked to the electronic record to
>which it relates, in a manner such that if the record or the signature
>is intentionally or unintentionally changed after signing the electronic
>signature is invalidated.
>
>----END
>
>So, what's a qualified security procedure in the case of digital
>signatures?
>The law provides:
>
>----START
>Section 15-105.  Secure electronic signature.  A digital signature that 
>is created using an asymmetric algorithm certified by the Secretary 
>of State under item (2) of subsection (b) of Section 10-110 shall be 
>considered to be a qualified security procedure for purposes of 
>identifying a person under Section 10-110 if:
>
>(1)	The digital signature was created during the operational period 
>of a valid certificate, was used within the scope of any other 
>restrictions specified or incorporated by reference in the certificate, 
>if any, and can be verified by reference to the public key listed in 
>the certificate; and
>
>(2)	The certificate is considered trustworthy (i.e., an accurate 
>binding of a public key to a person's identity) because the certificate 
>was issued by a certification authority in accordance with standards, 
>procedures, and other requirements specified by the Secretary of State, 
>or the trier of fact independently finds that the certificate was issued
>
>in a trustworthy manner by a certification authority that properly 
>authenticated the subscriber and the subscriber's public key, or 
>otherwise finds that the material information set forth in the 
>certificate is true.
>----END
>
>So, what are the implications for the PKIX draft and this debate
>about DS/NR keybits?
>
>I believe the Illinois ECS Act gives us strong guidance on the direction
>of the law (at least US law). The key issue for PKIX is expressed in
>paragraph 1 of Section 15-105 above. Namely, that the digital signature
>"was used within the scope of any other restrictions specified or 
>incorporated by reference in the certificate, if any...".
>
>IMHO, this says that it's really up to the CA and what they say in
>their CPS and any Certificate Policies adopted by the CA. If a CA
>adopts the PKIX profile, which they don't have to, then it would be
>up to the CA to further clarify the meaning of the NR bit in their
>certificates. To me, the NR bit is a requirement for any CA whose
>certificates will be used in an open environment, and whose certs
>are intended to establish the kind of non-repudiation contemplated
>by the Illinois law. The DS bit is irrelevant in this context.
>
>Of course it would be great if the application software would pay
>any attention at all to the v3 extensions in a certificate. But,
>that's another story.
>
>
>Bill Brice, Chief PKI Architect
>International DataTrust
>PO Box 670789
>Dallas, TX 75367-0789
>+1.214.706.9320 (direct), +1.214.706.9321 (fax) 
>
>P.S. I'm not an attorney. While I participate in the American Bar
>Association's Information Security Committee, these opinions are
>my own and you should conduct your own investigation and seek
>you own legal advice on these matters. :)
>
>

Date: Mon, 07 Sep 1998 09:35:36 +0100
From: Jorgen Moller <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: "CliveBetteridge" <[email-masked]>
To: <[email-masked]>
Subject: Internet Directory Consortium call for participation in DirConnect3
Date: Sun, 6 Sep 1998 17:48:12 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00D9_01BDD9BE.846D2140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,=20

The interest in LDAP, especially V3 and extensions remains strong. With =
this increase in popularity of the technology come even greater =
requirements for interoperability of different suppliers' =
implementations. To enable cooperative LDAP testing in an engineers-only =
environment the Internet Directory Consortium proposes to hold a =
Dirconnect3 Interoperability Testing event.=20

If you are implementing LDAP clients or servers you are urged to =
consider this opportunity of meeting your peers in other organizations =
for some serious testing.

The location will be in the San Jose area.=20

The program will be as below:=20

Day 1

8:30 - 9:30 Set up, get acquainted, muffins, fruit, coffee, sodas

9:30 - 12:00 Testing

12:00 - 1:00 Lunch (buffet, served away from the work room)

1:00 - 5:00 Testing

5:00 - 5:30 Recap and plan for Day 2=20

8:30 - 12:00 Testing (muffins, fruit, coffee, sodas at 8:30)

12:00 - 1:00 Lunch (buffet, served away from the work room)

1:00 - 4:00 Testing

4:00 - 5:00 Review and prepare preliminary report

5:00 - 6:00 Tear down

A quick straw-poll suggests most favored dates to be in the week =
commencing Monday 26th October.

Please can you give me the answers to the following questions:

Are you likely to attend?=20

What date(s) would you prefer?

What would you like to test?

Basic LDAP V2?

Basic LDAP V3?

LDAP V3 Extensions? (please list)

I look forward to hearing from you.

Best regards

Clive

Clive Betteridge, Operations Manager - Internet Directory Consortium

The Open Group

Apex Plaza, Forbury Road, Reading RG1 1AX, UK

Mailto:[email-masked] Ph: +44 1344 642153

http://www.opengroup.org/idc/ Fx: +44 118 950 0110=20

------=_NextPart_000_00D9_01BDD9BE.846D2140
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>
<DIV><FONT color=3D#000000 face=3DArial>
<P>Dear all,</FONT><FONT face=3DArial>&nbsp;</P></FONT><FONT =
color=3D#000000=20
face=3DArial>
<P>The interest in LDAP, especially V3 and extensions remains strong. =
With this=20
increase in popularity of the technology come even greater requirements =
for=20
interoperability of different suppliers' implementations. To enable =
cooperative=20
LDAP testing in an engineers-only environment the Internet Directory =
Consortium=20
proposes to hold a Dirconnect3 Interoperability Testing =
event.</FONT><FONT=20
face=3DArial>&nbsp;</P>
<P>If you are implementing LDAP clients or servers you are urged to =
consider=20
this opportunity of meeting your peers in other organizations for some =
serious=20
testing.</P></FONT><FONT color=3D#000000 face=3DArial>
<P>The location will be in the San Jose area.</FONT><FONT=20
face=3DArial>&nbsp;</P></FONT><FONT color=3D#000000 face=3DArial>
<P>The program will be as below:</FONT><FONT =
face=3DArial>&nbsp;</P></FONT><FONT=20
color=3D#000000 face=3DArial>
<P>Day 1</P>
<P>8:30 - 9:30 Set up, get acquainted, muffins, fruit, coffee, sodas</P>
<P>9:30 - 12:00 Testing</P>
<P>12:00 - 1:00 Lunch (buffet, served away from the work room)</P>
<P>1:00 - 5:00 Testing</P>
<P>5:00 - 5:30 Recap and plan for Day 2 </P>
<P>8:30 - 12:00 Testing (muffins, fruit, coffee, sodas at 8:30)</P>
<P>12:00 - 1:00 Lunch (buffet, served away from the work room)</P>
<P>1:00 - 4:00 Testing</P>
<P>4:00 - 5:00 Review and prepare preliminary report</P>
<P>5:00 - 6:00 Tear down</P>
<P></P>
<P></P>
<P>A quick straw-poll suggests most favored dates to be in the week =
commencing=20
Monday 26th October.</P>
<P></P>
<P>Please can you give me the answers to the following questions:</P>
<P>Are you likely to attend? </P>
<P>What date(s) would you prefer?</P>
<P></P>
<P>What would you like to test?</P>
<P>Basic LDAP V2?</P>
<P>Basic LDAP V3?</P>
<P>LDAP V3 Extensions? (please list)</P>
<P></P>
<P></P>
<P>I look forward to hearing from you.</P>
<P></P>
<P>Best regards</P>
<P></P>
<P>Clive</P>
<P></P>
<P>Clive Betteridge, Operations Manager - Internet Directory =
Consortium</P>
<P>The Open Group</P>
<P>Apex Plaza, Forbury Road, Reading RG1 1AX, UK</P></FONT><U><FONT=20
color=3D#0000ff face=3DArial>
<P>Mailto:[email-masked]</U></FONT><FONT color=3D#000000=20
face=3DArial>&nbsp;Ph: +44 1344 642153</P></FONT><U><FONT =
color=3D#0000ff=20
face=3DArial>
<P>http://www.opengroup.org/idc/</U></FONT><FONT color=3D#000000=20
face=3DArial>&nbsp;Fx: +44 118 950 0110 =
</FONT></P></DIV></DIV></BODY></HTML>

------=_NextPart_000_00D9_01BDD9BE.846D2140--

Date: Sat, 05 Sep 1998 21:20:16 +0100
From: "Frank O'Dwyer" <[email-masked]>
To: [email-masked]
Subject: Re: path development complexity
Sender: [email-masked]

Robert Klerer wrote:
> As a believer in the thinner client, a (local and possibly trusted) network
> based resource can perform this task more efficiently than locating it on
> the client. 

That sounds like it would help a lot (and it would be useful) but I
would still be concerned that it wouldn't be enough. For example,
people expected a lot of HTTP proxy caches (a similar solution to a
similar kind of problem), but I think those turned out not to
deliver as much as was expected. 

You also have the problem of arbitrary/roaming users connecting to
ISPs -- there is not much reason to suppose that a responder located
at an ISP would do a very good job of caching paths, since the users
could be connecting to just about anything. (Caching would still
help I guess.)

Lastly, you have the problem that certificates themselves run fairly
big, and that will doubtless get worse as people stuff more
extensions in there (mpegs of cats spring to mind:). So if
cross-certificates really take off, one of these responders could
potentially wind up like a backbone IP router, holding paths to
everywhere, and needing ridiculous quantities of main memory just to
avoid thrashing. (The router problem is also a similar problem with
similar causes.)

Another analogy is an internet search engine - take a look at the
spec of machine that altavista runs on.

So, if it is possible (and I don't know if it is), it would be much
better to design the PKI structure so that path discovery was easy
in the first place. 

> And we can argue whether it is more vulnerable to denial of
> service attacks or not.  But since the validation of the discovered path
> will always remain a client function, we would only be vulnerable to denial
> attacks.

Well if the responder was out of service the client could always
fall back on searching for itself. It could keep a local cache of
discovered paths also, and search there first (again like the
HTTP/proxy scenario).

Cheers,
Frank O'Dwyer.

From: "Robert Klerer" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: path development complexity 
Date: Sat, 5 Sep 1998 10:13:36 -0400
Sender: [email-masked]

Frank,

You have identified the problem.  By design the cross-certification
arrangements are driven by the business (and social) rules rather than the
design of pkix.  We have put in some generic restrictions that can be
applied, like name constraints and path length limitations, but I would
expect application specific extensions to proliferate.

To make the problem of path discovery harder, a cross certification
arrangement may be valid for one application but not another.  For example,
Citibank may decide that their employees can exchange signed and encrypted
email with employees of IBM.  The cross certification arrangement between
their CA's may be constructed to lack the critical extension to be valid for
exchanging financial trading information, while the arrangement with BoA
does and allows the trust relationship to be used for both email and
trading.

As a believer in the thinner client, a (local and possibly trusted) network
based resource can perform this task more efficiently than locating it on
the client.  And we can argue whether it is more vulnerable to denial of
service attacks or not.  But since the validation of the discovered path
will always remain a client function, we would only be vulnerable to denial
attacks.

-----Original Message-----
From: Frank O'Dwyer <[email-masked]>
To: Alan Lloyd <[email-masked]>
Cc: Dave Horvath <[email-masked]>; [email-masked] <[email-masked]>
Date: Saturday, September 05, 1998 9:12 AM
Subject: Re: path development complexity (was Re: What the straw poll mean
s)

>Alan Lloyd wrote:
>> I have a few views in that certs must be supported by mutually
>> authenticated distributed X.500 directory systems otherwise 509 based
>> systems just  wont scale and provide the commercial utilitity as
>> demanded by global EC directed organisations. Not having this foundation
>> - one just drops into all sorts of operational cost, scaling and
>> efficiency holes.
>
>What I am talking about is not the underlying retrieval efficiency,
>but rather the cost of total wrong-turns in the overall search, e.g:
>
> 10:15 Developing a path to verify certificate for "Joe's Server,
>NY"
> 10:15 Retrieving cross-certificates for "Keys R Us"
> 10:16 Retrieving cross-certificates for "Keys R Us Too"
> 10:17 Retrieving cross-certificates for "Barcelona CA"
> 10:18 Retrieving cross-certificates for "Spanish Bank"
> CARRIER LOST
>
>Users just love that browser "stop" button, and so any verification
>process that can't complete in a second or so is broken (my
>opinion).
>
>Throwing a meatier directory and/or caches (as someone else
>suggested) at it doesn't help if finding just one path involves
>trawling the world for hundreds of names. That is why I think it
>would be better if the certificates themselves contained positive
>guidance as to where to go next, or if cross-cert scenarios that
>lead to vague searches could be identified and discouraged. For
>example, maybe name constraints could be used as clues to guide path
>building. As things stand, content like basic constraints just tells
>you where *not* to search. That seems to leave building in
>heuristics, and hoping that working down from your trusted root(s)
>and/or up from the end-entity cert(s), you somehow meet in the
>middle and terminate in some reasonable time -- something that is by
>no means guaranteed.
>
>Maybe I have missed something obvious here - but I think this could,
>given time, turn out to be a showstopper scalability issue if it is
>not addressed early.
>
>Cheers,
>Frank O'Dwyer.
>

Date: Sat, 05 Sep 1998 12:44:06 +0100
From: "Frank O'Dwyer" <[email-masked]>
To: Alan Lloyd <[email-masked]>
CC: Dave Horvath <[email-masked]>, [email-masked]
Subject: Re: path development complexity (was Re: What the straw poll mean s)
Sender: [email-masked]

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Sat, 05 Sep 1998 13:32:45 +0200
To: WHenry <[email-masked]>
From: Patrik Nilsson <[email-masked]>
Subject: RE: Heads Up - Historic digital signing ceremony
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

The signed communiqué, the certificates, etc, are available at:
http://www.baltimore.ie/clintonvisit98/communique.html

Seems like there's a mime type problem on the web server though. The certs
are typed as ca-certs, leading to strange results when installing them in
Communicator.

Patrik

At 07:48 PM 98-09-04 , WHenry wrote:
> I wonder what President Clinton did with the smartcard afterwards...
>Can anyone add info on the nature of this PKI? Was there cross
>certification, or a single CA?
>
> Bill Henry
>> -----Original Message-----
>> From:	Kurn, David 
>> Sent:	Friday, September 04, 1998 12:43 PM
>> To:	[email-masked]
>> Subject:	RE: Heads Up - Historic digital signing ceremony
>> 
>> I wonder if the President obtained an export license for this technology.
>> I
>> think crypto devices (such as smart cards) could be subject to ITAR.
>> 
>> David Kurn
>> Compaq Computers
>> 
>> > -----Original Message-----
>> > From:	Bill Brice [SMTP:[email-masked]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[email-masked]
>> > Subject:	Heads Up - Historic digital signing ceremony
>> > 
>> > While the bits are flying on the LDAP debate, I 
>> > thought the list should know that a historic 
>> > milestone took place today (Friday 9/4) in the
>> > E-commerce/X.509 world.
>> > 
>> > President Clinton and the Irish Prime Minister
>> > signed a joint communiqué on E-commerce in Dublin.
>> > What was significant was not the communiqué but the
>> > fact that both heads of state signed the document
>> > digitally using X.509 technology. The private keys
>> > were held on smartcards issued to each head of
>> > state. This is the first instance of an 
>> > international agreement being digitally signed.
>> > 
>> > It's nice to see that this work 
>> > is actually showing up in the real
>> > world in a significant way.
>> > 
>> > OK - keep voting!
>> > 
>> > Bill Brice, Chief PKI Architect
>> > International DataTrust
>> > 
>> > P.S. Congratulations to Baltimore Technologies for
>> > pulling this off. It will move the PKIX world forward.
> 

Date: Fri, 4 Sep 1998 17:21:49 -0800
To: [email-masked]
From: Paul Ma <[email-masked]>
Subject: FOR Option2
Sender: [email-masked]

Hi,

I would put my 2 cents in for choosing option 2 in the latest straw poll on
certificate attributes used to store CA certificate.

Paul

From: "Surendra Reddy" <[email-masked]>
To: <[email-masked]>
Subject:  For option 2
Date: Fri, 4 Sep 1998 14:49:11 +0100
Importance: Normal
Sender: [email-masked]

From: "PACHL, Jan" <[email-masked]>
To: "'WHenry'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 16:22:33 -0500
Sender: [email-masked]

The press release about the event and the system used is at
http://www.baltimore.ie/news/press/pr980904.html

Jan Pachl

>----------
>From: 	WHenry[SMTP:[email-masked]]
>Sent: 	Friday, September 04, 1998 1:48 PM
>To: 	'Kurn, David'
>Cc: 	[email-masked]'
>Subject: 	RE: Heads Up - Historic digital signing ceremony
>
> I wonder what President Clinton did with the smartcard afterwards...
>Can anyone add info on the nature of this PKI? Was there cross
>certification, or a single CA?
>
> Bill Henry
>> -----Original Message-----
>> From:	Kurn, David 
>> Sent:	Friday, September 04, 1998 12:43 PM
>> To:	[email-masked]
>> Subject:	RE: Heads Up - Historic digital signing ceremony
>> 
>> I wonder if the President obtained an export license for this technology.
>> I
>> think crypto devices (such as smart cards) could be subject to ITAR.
>> 
>> David Kurn
>> Compaq Computers
>> 
>> > -----Original Message-----
>> > From:	Bill Brice [SMTP:[email-masked]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[email-masked]
>> > Subject:	Heads Up - Historic digital signing ceremony
>> > 
>> > While the bits are flying on the LDAP debate, I 
>> > thought the list should know that a historic 
>> > milestone took place today (Friday 9/4) in the
>> > E-commerce/X.509 world.
>> > 
>> > President Clinton and the Irish Prime Minister
>> > signed a joint communiqué on E-commerce in Dublin.
>> > What was significant was not the communiqué but the
>> > fact that both heads of state signed the document
>> > digitally using X.509 technology. The private keys
>> > were held on smartcards issued to each head of
>> > state. This is the first instance of an 
>> > international agreement being digitally signed.
>> > 
>> > It's nice to see that this work 
>> > is actually showing up in the real
>> > world in a significant way.
>> > 
>> > OK - keep voting!
>> > 
>> > Bill Brice, Chief PKI Architect
>> > International DataTrust
>> > 
>> > P.S. Congratulations to Baltimore Technologies for
>> > pulling this off. It will move the PKIX world forward.
>

From: "Salmond, Kent" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:57 -0700 
Sender: [email-masked]

From: "Smith, David" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 13:56:51 -0700 
Sender: [email-masked]

Date: Fri, 04 Sep 1998 20:24:15 +0100
To: "[email-masked]" <[email-masked]>
From: John Hughes <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

 -------------------------------------------------------------------
| John Hughes             [email-masked]                 |
| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |
|                         Home Fax No:           +44(0)1525 380161  |
|                         Main Office Tel:       +44(0)181 876 8666 |
| www.entegrity.com       Mobile:                +44(0)468 055070   |
 ------------------------------------------------------------------- 

From: Bill Brice <[email-masked]>
To: "'Kurn, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 14:16:44 -0500 
Sender: [email-masked]

That's very interesting. Being familiar with the product
used, I'd bet the keys were RSA-1024 bit implemented
with all non-US strong crypto technology (other than
RSA). Hmmm. Interesting precedent!

> -----Original Message-----
> From: Kurn, David [mailto:[email-masked]]
> Sent: Friday, September 04, 1998 11:43 AM
> To: [email-masked]
> Subject: RE: Heads Up - Historic digital signing ceremony
> 
> 
> I wonder if the President obtained an export license for this 
> technology.  I
> think crypto devices (such as smart cards) could be subject to ITAR.
> 
> David Kurn
> Compaq Computers

Reply-To: <[email-masked]>
From: "JF Sauriol" <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:31:02 -0400
Importance: Normal
Sender: [email-masked]

From: Larry Shomo <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:52 -0400
Sender: [email-masked]

Lawrence P. Shomo
Vice President

********************************
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia, 22102-3305
(703) 848-0883, x202 (Phone)
(703) 848-0960 (Fax)
[email-masked] (Email)

********************************

From: WHenry <[email-masked]>
To: "'Kurn, David'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 13:48:00 -0400 
Sender: [email-masked]

 I wonder what President Clinton did with the smartcard afterwards...
Can anyone add info on the nature of this PKI? Was there cross
certification, or a single CA?

 Bill Henry
> -----Original Message-----
> From:	Kurn, David 
> Sent:	Friday, September 04, 1998 12:43 PM
> To:	[email-masked]
> Subject:	RE: Heads Up - Historic digital signing ceremony
> 
> I wonder if the President obtained an export license for this technology.
> I
> think crypto devices (such as smart cards) could be subject to ITAR.
> 
> David Kurn
> Compaq Computers
> 
> > -----Original Message-----
> > From:	Bill Brice [SMTP:[email-masked]]
> > Sent:	Friday, September 04, 1998 9:12 AM
> > To:	[email-masked]
> > Subject:	Heads Up - Historic digital signing ceremony
> > 
> > While the bits are flying on the LDAP debate, I 
> > thought the list should know that a historic 
> > milestone took place today (Friday 9/4) in the
> > E-commerce/X.509 world.
> > 
> > President Clinton and the Irish Prime Minister
> > signed a joint communiqué on E-commerce in Dublin.
> > What was significant was not the communiqué but the
> > fact that both heads of state signed the document
> > digitally using X.509 technology. The private keys
> > were held on smartcards issued to each head of
> > state. This is the first instance of an 
> > international agreement being digitally signed.
> > 
> > It's nice to see that this work 
> > is actually showing up in the real
> > world in a significant way.
> > 
> > OK - keep voting!
> > 
> > Bill Brice, Chief PKI Architect
> > International DataTrust
> > 
> > P.S. Congratulations to Baltimore Technologies for
> > pulling this off. It will move the PKIX world forward.

Date: Fri, 04 Sep 1998 10:17:26 -0700
Subject: Re: Digital signature and non-repudiation key usage bits
From: "Aram Perez" <[email-masked]>
To: Stefan Santesson <[email-masked]>, bob jueneman <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Bob and Stefan:

>At 06:42 PM 9/2/98 -0600, Bob Jueneman wrote:
><snip>
>>>I suggest that we stick to the standardized definitions of the key usage
>>>bits and leave
>>>policy issues out of a common certificate profile.
>>
>>If there were any sense of the community as to what these definitions really
>>mean, or ought to mean, we would probably not be having this discussion.
>>Otherwise I would agree with you.
>>>
>>>non-repudiation is according to standard selected by the NR bit, not NR in
>>>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>>>other than non-repudiation are allowed for the key.

Is non-repudiation a mechanism or a service?

>>
>>I believe that is exactly the issue. Are you suggesting that NR plus DS
>should not
>>be allowed?  Why?
>
>No I do not. I do suggest that such decision is up to local policy. But
>there will be some policies where this combination will not be allowed, but
>I think you agree to that.

My problem with this is that to provide "digital" non-repudiation, you have to
"sign" something with a digital signature. I understand that the key usage field
is very overloaded, so I'll probably have to live with it, but I do not agree or
like it.

>
>The important thing is that I suggest that the NR bit and DS bit has
>separate meaning and that they should be set independently to specify DS,
>NR or both.
>
>The vague definition of the NR bit is a problem, I agree to that.

YES!!

>
>If I were to define some distinguishing property of the NR bit that would be:
>
>   Non repudiation denotes services constructed in such way that:
>   1) The signature provides proof of the integrity and 
>      origin of data - both in an unforgeable relationship - which can be 
>      verified by any third party at any time.[X.509 / ISO 9594-8]
>   2) The signature is applied to a message where the signatory is capable
>      of, and required to, accept responsibility for the message content 
>      before signing.

But NR is set in the certificate (i.e. the public key) and does not tell you
whether the signatory (who is using the private key) actually was capable of
accepting responsibility.

>   3) The signatory's liability for signing the message can be concluded
>      from the signed message itself, possibly within a well known and agreed 
>      context that can be verified by any third party at any time.
>
>This definitions rules out any signed logon ticket or other data
>authentication mechanisms where the signature says "this message wasn't
>changed" instead of "I take full responsibility for the message content".

You do not need a digital signature to tell you "this message wasn't changed".
CRCs, LRCs, checksums, etc have been used for this longer that I've been alive.
You use digital signature when you want to know "this message wasn't changed"
AND "this message came from the reported sender".

>
>But since this is not defined by the bit (which I regret) the way to go
>will be for the CA to include this in it's published certificate policy.

I doubt whether a CA is going to take responsibility and liability for something
it has no control over. The CA does not know what applications and crypto APIs
the owner of the private key is using.

>
>I can't see any other way for now when utilizing the existing standard. I
>would not object though to a defect report to get this into the standard.

And I am willing to help (or lead) in this effort.

>
>In the new proposed work item, however, regaring a profile for
>non-repudiation certificates supporting legal acceptance of digital
>signatures I will try to get this definition in.
>
>Would you support it?

I would be glad to help and support it.

Regard,
Aram Perez
Apple Computer, Inc.

From: "Kurn, David" <[email-masked]>
To: [email-masked]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 09:43:21 -0700 
Sender: [email-masked]

I wonder if the President obtained an export license for this technology.  I
think crypto devices (such as smart cards) could be subject to ITAR.

David Kurn
Compaq Computers

> -----Original Message-----
> From:	Bill Brice [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 9:12 AM
> To:	[email-masked]
> Subject:	Heads Up - Historic digital signing ceremony
> 
> While the bits are flying on the LDAP debate, I 
> thought the list should know that a historic 
> milestone took place today (Friday 9/4) in the
> E-commerce/X.509 world.
> 
> President Clinton and the Irish Prime Minister
> signed a joint communiqué on E-commerce in Dublin.
> What was significant was not the communiqué but the
> fact that both heads of state signed the document
> digitally using X.509 technology. The private keys
> were held on smartcards issued to each head of
> state. This is the first instance of an 
> international agreement being digitally signed.
> 
> It's nice to see that this work 
> is actually showing up in the real
> world in a significant way.
> 
> OK - keep voting!
> 
> Bill Brice, Chief PKI Architect
> International DataTrust
> 
> P.S. Congratulations to Baltimore Technologies for
> pulling this off. It will move the PKIX world forward.

From: Peter Sylvester <[email-masked]>
Date: Fri, 4 Sep 1998 18:43:29 +0200
To: [email-masked], [email-masked], [email-masked]
Subject: RE: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

I have some problem to decrpyt the following. 
Is the following picture a correct description?

- A CA1 creates a certificate for another CA2.
- To publish this information, CA1 puts something in its 
  publishing service, e.g.; its directory entry.
- CA1 can inform by whatever means CA2 that this had happened. 
- If CA2 is convinced that CA1 is really CA1 or maybe even if not,
  CA2 then can put something it its publishing service, e.g.; its directory entry.

It seems to me that first the requirement of a path resolver vs a publication
service should be defined in a neutral way. What does a path resolver need
from the publication service of one CA, and in which way can a publication
service help a resolver.    

> Do you mean though that if CA1 issues a certificate to CA2 that rather
> than requiring that same certificate to be present in the reverse
> element of the crossCertificatePair attribute of CA1's directory as well
> as requiring that same certificate to be present in the forward element
> of the crossCertificatePair attribute of CA2's directory entry, you want
> to require that it be present in the directory entry of CA2, the subject
> CA as a forward value of the crossCertificatePair and optionally allow
> CA1 to populate its reverse element with the same certificate?
> 

Date: Fri, 04 Sep 1998 12:18:06 -0400
To: [email-masked]
From: "Erin Connor" <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

--------------------------------------------------------------------------
Erin Connor                             EWA-Canada Ltd.
Voice:  +1 (613) 230-6067 Ext 234       Suite 1600 - 275 Slater Street
Fax:    +1 (613) 230-4933               Ottawa, Ontario, Canada  K1P 5H9
mailto:[email-masked]         	http://www.ewa-canada.com

** Visit the CanCERT website at  http://cancert.ca ***
--------------------------------------------------------------------------

From: Bill Brice <[email-masked]>
To: [email-masked]
Subject: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 11:11:44 -0500 
Sender: [email-masked]

While the bits are flying on the LDAP debate, I 
thought the list should know that a historic 
milestone took place today (Friday 9/4) in the
E-commerce/X.509 world.

President Clinton and the Irish Prime Minister
signed a joint communiqué on E-commerce in Dublin.
What was significant was not the communiqué but the
fact that both heads of state signed the document
digitally using X.509 technology. The private keys
were held on smartcards issued to each head of
state. This is the first instance of an 
international agreement being digitally signed.

It's nice to see that this work 
is actually showing up in the real
world in a significant way.

OK - keep voting!

Bill Brice, Chief PKI Architect
International DataTrust

P.S. Congratulations to Baltimore Technologies for
pulling this off. It will move the PKIX world forward.

From: "Robert Klerer" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: path development complexity (was Re: What the straw poll means)
Date: Fri, 4 Sep 1998 11:52:02 -0400
Sender: [email-masked]

As pkix evolves and is implemented, the task of finding an appropriate trust
path must be addressed.  As Dave has stated, it is not going to be easy if
the trust islands of today start to cross certify for some applications.  It
is my belief that putting such processing on the client will cause problems
from both then network, processor and application development perspective.
A (shared) trusted responder that will be a repository and cache of
certificates that has the capability to do path discovery would make such a
process more efficient and manageable.

But the client must always validate any path provided by the responder.

The path discovery process as so described in the drafts will require
knowledge of application specific extensions.  This is the big problem and
should be a topic of discussion.

-----Original Message-----
From: Frank O'Dwyer <[email-masked]>
To: Dave Horvath <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, September 03, 1998 11:57 PM
Subject: path development complexity (was Re: What the straw poll means)

>Dave Horvath wrote:
>>         We are back the problem we raised earlier.  Clients that attempt
to
>> efficiently develop a path from the end entity to the trusted root must
>> explore 'n' paths (worst case scenario)  prior to finding the correct
>> one with option 2.
>
>This is not on the topic of the straw poll, but I was wondering if
>anyone has really looked into how difficult path development can get in
>a full-blown and well-connected global PKI? It seems to me that the real
>worst case scenario has you following cross-certificates until you have
>downloaded all the cross-certificates in the world. It would not have to
>get that bad before it was a serious problem.
>
>A few things would help prune the search (like the depth you are willing
>to search to, constraints within the certificates themselves), but still
>in general it has the potential to get truly nasty. Unless I have missed
>something, there are no positive hints in the certificates that would
>guide path development (perhaps there should be? There is a resemblance
>to the "travelling salesman" problem here, and it would certainly be
>ironic if building a path turned out to be as hard as factoring.:)
>
>Anyone looked at this? If it is a problem, then it might be reasonable
>to give recommendations on using constraints (or something else) in
>order to encourage the creation of cross-certificates that are
>"path-development friendly", and in order to discourage scenarios that
>lead to directory search explosions.
>
>Apologies if I am re-hashing something that has already been discussed
>here.
>
>Cheers,
>Frank O'Dwyer.
>

From: "Power, Michael: LEG" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:24:33 -0400 
Sender: [email-masked]

Date: Fri, 04 Sep 1998 11:03:15 -0400
From: Pamela Grannum <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: [email-masked]
To: [email-masked]
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:13:27 -0400
Sender: [email-masked]

My vote is for Option 2 of the LDAP schema companion paper.

Edmond P. van Hees
GOC PKI Security Engineer
telephone: 613-991-7413 
Fax: 613-991-7455
E-Mail:  [email-masked]

Date: Fri, 04 Sep 1998 10:37:54 -0700
To: [email-masked]
From: "Steve O'Neil" <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Reply-To: "Mark Scherling" <[email-masked]>
From: "Mark Scherling" <[email-masked]>
To: <[email-masked]>
Subject: option 2
Date: Fri, 4 Sep 1998 10:33:53 -0400
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Sharon Boeyen <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:30:00 +0100
Sender: [email-masked]

Santosh
re this comment to Denis message:

	The argument was made very clear in terms of the original X.509
standard requiring the attribute to be populated whereas
croosCertificatePair need not be.  In addition, a technical argument was
made why the current text goes against the original X.509 and a poor
technical solution.

------
I hope we don't go far down this road. At best I think X.509 is unclear
and ambiguous on this issue. Those present at the January meeting of the
X.509 group that discussed the defect report (including at least 4 of us
who have participated directly in that standard activity since at least
1988) had a long discussion of exactly this point and agreed that
additional text was required to resolve the ambiguity around the use of
these attributes. The result of that discussion was the draft resolution
of the defect report prepared for ballot (with which the current
Internet Draft is aligned), the content which is of course still subject
to change as described earlier.

There are so many arguments on both sides of this that I believe no one
can clearly claim conformance as a differentiator in the options for the
straw poll. 

Yes the crossCertificatePair attribute was optional and still is in the
pkiCA object class, but the reason for that is that a CA can exist
without ever having certified another CA or being certified by another
CA therefore it MUST be an optional attribute, however if present, its
contents must be clearly defined. You could use the same argument to say
that cACertificate was never intended to hold certs issued from one CA
to another - again because a CA can exist legitimately without ever
having a relationship with another CA and the cACertificate attribute
was mandatory.  Also, if you read the 2nd paragraph following the asn.1
for the EXTENSION in clause 8 of X.509, you see use of forward and
reverse certificates being discussed in path development and there is no
precise definition of what goes where in the directory entries. That
text has been there since 1988 as well. and the list of references that
can be used for both sides of the argument go on and on and on. 

The outcome from PKIX discussion will hopefully be available to feed
into the 509 process to clarify the standard.

From: Rene Eberhard <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 15:06:27 +0100
Sender: [email-masked]

Best regards Rene

From: Sharon Boeyen <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:02:50 +0100
Sender: [email-masked]

Santosh, a question for clarification - tied to Denis' message also:

I definitely agree that unilateral certification is valid and I don't
think any of us have been saying that bilateral certification between a
pair of CAs is mandatory. If that needs clarification, we can certainly
add text along those lines to option 2 - Stefan had some good proposals.

Do you mean though that if CA1 issues a certificate to CA2 that rather
than requiring that same certificate to be present in the reverse
element of the crossCertificatePair attribute of CA1's directory as well
as requiring that same certificate to be present in the forward element
of the crossCertificatePair attribute of CA2's directory entry, you want
to require that it be present in the directory entry of CA2, the subject
CA as a forward value of the crossCertificatePair and optionally allow
CA1 to populate its reverse element with the same certificate?

If that's what you mean, I can accept that position as well.

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 4, 1998 9:19 AM
> To: 	'Bill Burr'; Santosh Chokhani
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> I agree that option 2 is compromise.  Actually, as you know I had
> proposed it.
> 
> I would change one thing in it.  I would not mandate the population of
> reverse component of the crossCertificatePair.
> 
> > 
> > Bill Burr
> 

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Sharon Boeyen <[email-masked]>
Cc: [email-masked], Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:45:36 -0400
Sender: [email-masked]

Comments in line.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 1:03 PM
> To:	Sharon Boeyen
> Cc:	[email-masked]; 'Santosh Chokhani'
> Subject:	Re: What the straw poll means
> 
> Sharon, 
> 
> > The "two buckets" is exactly what I was trying to avoid in the
> > earlier debate on this topic, however I believe that the single 
> > bucket option was rejected in the Chicago meeting. 
> 
> It was a pity that you could not attend the Chicago meeting. 
> "rejected" may be a strong word. During the straw poll, I did not 
> raised my hand for any of the three options for the following good 
> reasons:
> 
> 1) I had three weeks of holidays one week ahead of the meeting, :-)
> 2) When I came back, I had 470 E-mails waiting for me,
> 3) I completely skipped the thread on the LDAP schema, :-(
> 
> As a result I could not understand from the discussion what the topic
> was and so I abstained. I would guess that I was not the single one in
> that position. There was some support for it anyway, so I do not
> understand why the straw poll is not on the three options but instead
> only on two options.
> 
> > The single bucket option is the
> > text which is currently in the Internet Draft. With that text, 
> > all self signed (or self issued certificates) were to be placed 
> > in the cACertificate attribute and all certificates issued by 
> > one CA to a different CA were put in the crossCertificatePair 
> > attribute. 
> 
> This was pretty nice and simple ! If I were to open the bunch of
> messages, maybe I could understand why this is not acceptable.
> 
	The argument was made very clear in terms of the original X.509
standard requiring the attribute to be populated whereas
croosCertificatePair need not be.  In addition, a technical argument was
made why the current text goes against the original X.509 and a poor
technical solution.

> > Depending on the particular path development algorithm being 
> > used by a relying party, directory search tools, especially 
> > when we evolve to LDAPv3 could be used to filter the content 
> > of the forward and or reverse elements of that SINGLE attribute 
> > and provide the relying party with the set of certificates of 
> > interest to that particular relying party.
> 
> Indeed. []    Again the approach is consistent with the text, spirit
> and intent of X.509 and never hurts, but may help path development. 
>  
> > I still believe that this is the best solution because the relying
> > party systems are the ones that know which certs are of interest 
> > to them, 
> 
> I agree with you.
> 
> > not the CA that happened to issue the certs, especially in the 
> > post PEM world where any CA could legitimately have certs issued 
> > for it by several CAs.
>  
> > My strong support for Option 2 in the straw poll is because 
> > the above was rejected by the meeting and I see Option 2 as 
> > a workable compromise ONLY because there is a complete set of 
> > certs in a single attribute and relying parties can do what is 
> > of interest to them without knowing the definition of domain 
> > which each individual CA happens to use. For self contained 
> > environments wanting to make use of a CA or set of CAs certs
> > issued within some locally defined domain, this is still possible.
> 
> Let me take a look at option 1 and say why it is not acceptable ... 
> because it imposes a model of trust that is too specific.
> 
> General comment: The notion of "domain" has never been introduced
> before and since the understanding of a domain is "purely a matter 
> of local policy" there is no chance that the requester understands 
> what it means - unless we are in a close environment. 
> 
> I believe that this feature is being introduced to be used in close
> environments for some "good" reasons. The text should explain these
> "good" reasons otherwise readers of the document will ignore for ever
> the rational.  
> 
> PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
> OPTION 1:
> ----------------
> The cACertificate attribute, held in a particular CA's directory
> entry, shall be used to store certificates issued to this CA by CAs 
> in the same domain as this CA. 
> 
>      When the notion of domain does not exists, then this will 
>      be empty.
> 
	[]  Agreed. 

> In addition, the cACertificate attribute shall be used to
> store self-issued certificates.
> 
>      This is fine.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  
> 
>      I have a problem here. Cross certification does not mean mutual 
>      cross certification. A CA can cross-certify another CA without 
>      any knowledge from the CA being cross certified. Even if the CA
>      got the knowledge of it, that CA would not like to place that 
>      certificate in that entry. Let us pick an example: a CA from 
>      the Banana Republic of Baracuda is providing a certificate for 
>      the NIST. I do not think that the NIST will necessarilly place
>      that certificate in his entry. 
> 
	[]Denis: THIS IS NOT AN OPTION 1 ISSUE.  THE CURRENT TEXT,
OPTION 1 and OPTION 2 ALL HAVE THE SAME DRAWBACK.  

> Optionally, the reverse element of the crossCertificatePair attribute,
> 
> held in a particular CA's directory entry, may contain certificates 
> issued by this CA to CAs in other domains.
> 
>      I have a problem here with the word "Optionally" : if the 
>      previous element is not there, then I cannot place an element 
>      here. This means that if CA 1 wants to recognize CA 2, 
>      then CA 2 MUST also recognize CA 1. This mandates mutual cross
>      certification. I do not think that we have ever mandated 
>      *mutual* cross certification in PKIX-1.
> 
	]My interpretation is  different.  You can always populate the
reverse attribute even if the forward is absent.  I will be glad to
clarify the text.  Please also note that this is an issue for current
ldapv2 text, Option 1 and for option 2.

>      Thus OPTION 1 is NOT acceptable and this has nothing to do with 
>      performance or path development.
> 
> In the case of V3 certificates, none of the above CA certificates may
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> OPTION 2:
> -------------
> The crossCertificatePair attribute, held in a particular CA's
> directory entry, shall be used to store all certificates issued 
> by this CA to other CAs, as well as certificates issued 
> for this CA by other CAs. Values held in the forward element are 
> certificates issued for this CA by other CAs, while values 
> in the reverse element are certificates issued by this CA for
> other CAs. 
> 
>      I would interpret the text as mandating to store the reverse 
>      element and optionally the forward element. I would instead
>      allow to store only the forward element, only the reverse 
>      element or both. 
> 
>      Hence the OPTION 2 is NOT acceptable either and this has 
>      nothing to do with performance or path development.
> 
> The text should be corrected and be something like:
> 
>      The crossCertificatePair  attribute,  held  in  a  particular
> CA's
>      directory  entry,  may be used to store certificates issued by
> this
>      CA to other CAs, as well as certificates  issued  for  this  CA
> by
>      other  CAs.  Values  held  in  the forward element are
> certificates
>      issued for this CA by other CAs, while values in the  reverse
> ele-
>      ment  are certificates issued by this CA for other CAs. Either
> cer-
>      tificate, if present,  may be used in  building  certificate
> paths
>      for  validation  and  may  be published in the directory entries
> of
>      either CA or both.
> 
	[]  This is an acceptable compromise to me between option 1 and
option 2.  It does not mandate, but permits population of the
crossCertificatePair attribute components.

>  ... which is exactly what is in the original text !
> 
> The cACertificate attribute, held in a particular CA's directory
> entry, shall be used to store certificates issued to this CA by CAs 
> in the same domain as this CA. This set of certificates is a subset 
> of the values of the forward element of the crossCertificatePair 
> attribute in the same CA entry.
>  
> In addition, the cACertificate attribute shall beused to store
> self-issued certificates.  
> 
>      When there are no domains, and IF the text was corrected as 
>      indicated hereabove (i.e. back to the text of the original 
>      version) then we would be "compatible" with the previous 
>      text, but this is not the case. Did I understood correctly ?
> 
>      I believe that there are "good" resons to introduce the 
>      notion of "domain". Are these "good reasons" technical or 
>      commercial ? If they are technical then they SHALL be 
>      written in the document. But what about if they are 
>      "commercial" ?
> 
> For the time being, I can only vote for OPTION 0 (i.e. the original
> text) !
> 
> Denis
> 
> -- 
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Ryan Moats" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Let's try to understand the real issue (was... RE: What the straw poll means)
Date: Fri, 4 Sep 1998 08:26:03 -0500
Importance: Normal
Sender: [email-masked]

>
> Hi Ryan,
>
> > | If this CA's definition of domain and my definition of domain do not
> > | coincide exactly (and why should they, since in general this CA and
> > I
> > | have no pre-established relationship?), then this sorting performed
> > by
> > | the CA is not merely useless to me, it is actually an explicit
> > | disadvantage (because the proponents of option 1 are recommending
> > that
> > | all the intra-domain certificates be examined *before* the
> > inter-domain
> > | certificates are examined, leading to worst-case path-construction
> > times
> > | for what may turn out to be a common scenario).
> >
> > I don't see that falling out of the Option 1 text as I read the
> > straw poll message.  If such is the case, then I would say that text
> > should be present.
> >
> Dave Horvath's message to Bob Jueneman earlier today said the following:
>
>     "I feel that the definition of domain is a local policy and that CAs
> should be free to define it as they wish.   Clients  that search/read
> CAs entries and obtain the values from both the cACertificate and
> crossCertificatePair attributes can explore the values in the
> cACertficate attribute first.  If a path to the trusted root is found,
processing
> stops. If not, they can explore the crossCertificatePair attribute.  Using
this
> algorithm CAs can define their domain and post each of their CA
> certificates to one attribute or the other.  The only adverse affect will
be
> efficiency in path development  on the client side if the CA does not
carefully
> select intra or inter domain."
>
> This was also mentioned at the meeting in Chicago.

Hmm.  I was at the meeting in Chicago (both sessions) and I don't remember
hearing
that.  However, I claim that the whole argument is implementation and
therefore out
of scope for this discussion.

> > | Note that there will be special circumstances in which one
> > definition of
> > | domain will be understood throughout a given environment (e.g., the
> > | strict hierarchy of CAs has been cited in previous posts on this
> > topic).
> > | In such cases there is a clear efficiency advantage to be gained in
> > path
> > | construction.  This is why option 2 is the perfect compromise:  for
> > such
> > | environments relying parties need only retrieve the n1 < n
> > certificates
> > | that they *know* will be useful to them.  Option 2 therefore meets
> > the
> > | needs of the general case as well as the special case, while
> > | simultaneously guaranteeing interoperability of two installed bases
> > | which would otherwise have no hope of interoperating today.
> >
> > Stop. Here's where I really fall off the wagon. How does the relying
> > party
> > retrieve ONLY the n1 certificates that they know will be useful to
> > them for
> > a CA?
> >
> If the relying party knows that its definition of domain matches that of
> the CA exactly, then it can simply retrieve all certificates in the
> cACertificate attribute (rather than all certificates in the
> crossCertificatePair attribute) in option 2.  This is n1 rather than n.
>
> Carlisle.

So what your saying then is that Option 2 is better because of the
interopability
issue (I can apply all the rest of the arguments to both cases since I don't
see
any difference in the use of cACertificate in both options)

Ryan

From: Santosh Chokhani <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:19:29 -0400
Sender: [email-masked]

I agree that option 2 is compromise.  Actually, as you know I had
proposed it.

I would change one thing in it.  I would not mandate the population of
reverse component of the crossCertificatePair.

> -----Original Message-----
> From:	Bill Burr [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 9:21 AM
> To:	Santosh Chokhani
> Cc:	[email-masked]
> Subject:	RE: What the straw poll means
> 
> At 08:11 AM 9/4/98 -0400, you wrote:
> 
> Santosh,
> 
> Are you saying that you agree that option 2 is the "perfect
> compromise?"  
> 
> >Stefan:
> >
> >I agree with every thing you say in this mail message,
> >
> >> -----Original Message-----
> >> From:	Stefan Santesson [SMTP:[email-masked]]
> >> Sent:	Friday, September 04, 1998 7:20 AM
> >> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
> >> Cc:	Santosh Chokhani
> >> Subject:	RE: What the straw poll means
> 
> <snip>
> 
> >>And since
> >> this
> >> guidance by the CA may be useful in many situations, I consider
> option
> >> 2 as
> >> the perfect compromise.
> >> 
> >> /Stefan
> >> 
> >> 
> >> 
> >> 
> >> 
> Regards,
> Bill Burr

Date: Fri, 04 Sep 1998 09:20:36 -0400
To: Santosh Chokhani <[email-masked]>
From: Bill Burr <[email-masked]>
Subject: RE: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

At 08:11 AM 9/4/98 -0400, you wrote:

Santosh,

Are you saying that you agree that option 2 is the "perfect compromise?"  

>Stefan:
>
>I agree with every thing you say in this mail message,
>
>> -----Original Message-----
>> From:	Stefan Santesson [SMTP:[email-masked]]
>> Sent:	Friday, September 04, 1998 7:20 AM
>> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
>> Cc:	Santosh Chokhani
>> Subject:	RE: What the straw poll means

<snip>

>>And since
>> this
>> guidance by the CA may be useful in many situations, I consider option
>> 2 as
>> the perfect compromise.
>> 
>> /Stefan
>> 
>> 
>> 
>> 
>> 
Regards,

Bill Burr

From: "Miklos, Sue A." <[email-masked]>
To: "'Carlisle Adams'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Let's try to understand the real issue (was... RE: What the straw poll means)
Date: Fri, 4 Sep 1998 08:58:25 -0400
Sender: [email-masked]

I work in an environment where although the entire 'world' won't
need/want/have access to my directory system, I will be required to make
information available to a geographical disbursed, multinational, large
group of users.

Sandi

>----------
>From: 	Ambarish Malpani[SMTP:[email-masked]]
>Sent: 	Thursday, September 03, 1998 4:41 PM
>To: 	Carlisle Adams
>Cc: 	[email-masked]
>Subject: 	Re: Let's try to understand the real issue (was... RE: What the
>straw poll means)
>
>Hi Carlisle,
>    Is the expectation that everybody is directly accessing their
>CA's LDAP directory? I always thought that each orginazation would
>actually maintain its own LDAP directory and, therefore, be able
>to specify which CAs are preferred over others.
>
>    Are we really expecting people to share their directories with
>everyone in the world?
>
>Ambarish
>
>
>Carlisle Adams wrote:
>> 
>> Hi all,
>> 
>> I propose that we try (once again) to understand what the real issue is
>> here.
>> 
>> > ----------
>> > From:         Ryan Moats[SMTP:[email-masked]]
>> > Sent:         Thursday, September 03, 1998 12:14 PM
>> > To:   [email-masked]
>> > Cc:   [email-masked]
>> > Subject:      Retrieval efficiency herring? (was... RE: What the straw
>> > poll means)
>> >
>> > As somebody coming to the party late from the LDAP world, I don't see
>> > why
>> > the certificates need to be retrieved from two places.  An LDAP lookup
>> > of an
>> > object with a fairly simple filter (objectclass="*") will return all
>> > of the
>> > attributes associated with that object.  Therefore a single lookup
>> > will return
>> > both attributes, so I don't understand how retrieval efficiency is
>> > gained.
>> >
>> O.K., so we see that a single LDAP lookup can retrieve all certificates
>> (which, after careful enumeration, was found to be "n") in either option
>> 1 or option 2.
>> 
>> The claimed advantage of option 1 is that this retrieval gets me
>> certificates that are sorted into "intra-domain" and "inter-domain",
>> which can help in efficient path construction.  Let's think about this
>> for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
>> TRUSTED BY ME  (because if it was directly trusted by me, I would
>> already have a trusted copy of its public key and would not need
>> certificates in which it was the subject).  If it is not directly
>> trusted by me, then why would I necessarily trust it to do this sorting
>> in a way that is beneficial to my path construction needs?  How does it
>> know what *my* definition of "domain" is?  How does it know whether most
>> of my certificate validations will be "intra" its definition of domain
>> or "inter" its definition of domain?
>> 
>> If this CA's definition of domain and my definition of domain do not
>> coincide exactly (and why should they, since in general this CA and I
>> have no pre-established relationship?), then this sorting performed by
>> the CA is not merely useless to me, it is actually an explicit
>> disadvantage (because the proponents of option 1 are recommending that
>> all the intra-domain certificates be examined *before* the inter-domain
>> certificates are examined, leading to worst-case path-construction times
>> for what may turn out to be a common scenario).
>> 
>> Relying parties know what certificates they will be validating most
>> often, depending upon what particular activity they are engaged in at
>> the moment.  THAT defines the relying parties' "intra" and "inter"
>> domains.  CAs in the middle of a cert. path cannot possibly know this,
>> in general, so having THEM define a domain and sort certificates
>> according to that definition is really meaningless.
>> 
>> Note that there will be special circumstances in which one definition of
>> domain will be understood throughout a given environment (e.g., the
>> strict hierarchy of CAs has been cited in previous posts on this topic).
>> In such cases there is a clear efficiency advantage to be gained in path
>> construction.  This is why option 2 is the perfect compromise:  for such
>> environments relying parties need only retrieve the n1 < n certificates
>> that they *know* will be useful to them.  Option 2 therefore meets the
>> needs of the general case as well as the special case, while
>> simultaneously guaranteeing interoperability of two installed bases
>> which would otherwise have no hope of interoperating today.
>> 
>> The price of this panacea?  A few redundant certificates in the
>> Directory.  Is it really worth sacrificing the general- (and perhaps
>> common-) case scenario, as well as interoperability, in order to save a
>> few certificates and satisfy a particular special-case?  I haven't yet
>> heard any convincing arguments...
>> 
>> Carlisle.
>
>-- 
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect					         650.567.5457
>ValiCert, Inc.				        [email-masked]
>1215 Terra Bella Ave.		              http://www.valicert.com
>Mountain View, CA 94043-1833
>

From: Santosh Chokhani <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 08:11:19 -0400
Sender: [email-masked]

Stefan:

I agree with every thing you say in this mail message,

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 7:20 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
> Cc:	Santosh Chokhani
> Subject:	RE: What the straw poll means
> 
> At 08:48 PM 9/2/98 -0400, Santosh Chokhani wrote:
> <snip>
> >The way I look at the difference between the two options is that if
> >n=n1+n2 certificates are issued to a CA, option 1 says CA puts n1 in
> one
> >bucket and n2 in another.  Option 2 says put n in one bucket and n1
> in
> >another.  When you retrieve the two buckets (which you must for path
> >development efficiency), option 2 gives you n+n1 certificates and
> option
> >1 gives you exactly all n.
> 
> I tried to point out before that this is not the whole picture.
> 
> The CA is dealing with n CA certificates n=n1+n2+n3+n4 of the form:
> n1 = intra domain issued to other CA:s
> n2 = intra domain issued by other CA:s to this CA
> n3 = inter domain issued to other CA:s
> n4 = inter domain issued by other CA:s to this CA
> 
> Option 1 stores only n2+n3+n4
> (n2 in one bucket and n3+n4 in the other.)
> 
> Option 2 stores n1+2(n2)+n3+n4
> (n2 in one bucket and n1+n2+n3+n4) in the other)
> 
> As you see, n1 is left out of option 1 (according to text)
> You said then that it is not forbidden to store n1 (in option 1)
> in the cross certificate pair. I guess then that option 1 should
> changed-
> 
> from:
>   Optionally, the reverse element of the
>   crossCertificatePair attribute, held in a particular CA's directory
> entry,
>   may contain certificates issued by this CA to CAs in other domains.
> 
> to:
>   Optionally, the reverse element of the
>   crossCertificatePair attribute, held in a particular CA's directory
> entry,
>   may contain certificates issued by this CA to other CAs.
> 
> So if this is correct then what we are fighting about is only whether
> we
> should duplicate n2 (out of n1,n2,n3 and n4). To me it sounds
> reasonable to
> have the complete set of n1+n2+n3+n4 in one bucket and the n2 in the
> cACertificate attribute as a specific information for those who wants
> to
> have the CA:s guidance to define the inter domain subgroup. And since
> this
> guidance by the CA may be useful in many situations, I consider option
> 2 as
> the perfect compromise.
> 
> /Stefan
> 
> 
> 
> 
> 

To: [email-masked]
cc: Sharon Boeyen <[email-masked]>, [email-masked], "'Santosh Chokhani'" <[email-masked]>
Subject: Re: What the straw poll means 
Date: Fri, 04 Sep 1998 12:24:47 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

Denis,

Your comments are helpful in pointing out flaws in the expression of the
two options, although these aren't at the heart of the debate.  

I have included a suggested text for the relevant part of Option 1
below.  It seems to me that similar adjustments would need to be made to
the Option 2 text.

As for the relative merits of options 1 and 2 from a functional point of
view, I am still taking time to listen and consider.  I wish there was
more information about the installed base requiring option 2.

Denis Pinkas writes:

>Let me take a look at option 1 and say why it is not acceptable ... 
>because it imposes a model of trust that is too specific.

Would you say that the modified text I suggest below imposes the same
constraint?  In other words, is your concern simply a matter of the
expression of option 1?

>PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
>OPTION 1:
>----------------
[snip]

>The forward element of the crossCertificatePair attribute, held in a
>particular CA's directory entry, shall be used to store certificates
>issued to this CA by CAs in other domains.  
>
>     I have a problem here. Cross certification does not mean mutual 
>     cross certification. A CA can cross-certify another CA without 
>     any knowledge from the CA being cross certified. Even if the CA
>     got the knowledge of it, that CA would not like to place that 
>     certificate in that entry. Let us pick an example: a CA from 
>     the Banana Republic of Baracuda is providing a certificate for 
>     the NIST. I do not think that the NIST will necessarilly place
>     that certificate in his entry. 

>Optionally, the reverse element of the crossCertificatePair attribute, 
>held in a particular CA's directory entry, may contain certificates 
>issued by this CA to CAs in other domains.
>
>     I have a problem here with the word "Optionally" : if the 
>     previous element is not there, then I cannot place an element 
>     here. This means that if CA 1 wants to recognize CA 2, 
>     then CA 2 MUST also recognize CA 1. This mandates mutual cross
>     certification. I do not think that we have ever mandated 
>     *mutual* cross certification in PKIX-1.

I think your concern might be better directed towards the absence of the
word 'optionally' in the 'forward element' description, rather than its
presence here.

X.509 allows both the forward and reverse elements of
crossCertificatePair to be OPTIONAL, the stipulation being that at least
one is present.

A suggested text for this part of OPTION 1 might be:

"Values of the Attribute type crossCertificatePair, if present in a
particular CA's directory entry, shall have at least one of the optional
forward and reverse elements present.

When the forward element is present, it shall contain a certificate
issued to this CA by a different CA in another domain.

When the reverse element is present, it shall contain a certificate
issued by this CA to a different CA in another domain.

When both elements are present in the same value, the value shall
represent a mutual cross-certification of the two CAs. [perhaps add
further statements about compatibility of cross certification here?
(e.g. key usage;  should the certificates mutually verify each other
(probably shouldn't be required)?)]"

The statement about mutual cross-certification is the primary addition
here.  It is an attempt to clarify the meaning when both elements are
present, while leaving room for certificates which, although apparently
representing a mutual cross-certification, represent certificates in
opposite directions which have different policies, key usages, etc.

Does it need to state explicitly that crossCertificatePair is a
multi-valued attribute? 

This text could of course be adapted for OPTION 2.

>
>     Thus OPTION 1 is NOT acceptable and this has nothing to do with 
>     performance or path development.

I think this is not a fundamental flaw of OPTION 1, just an imprecision 
of expression.

>
>In the case of V3 certificates, none of the above CA certificates may
>include a basicConstraints extension with the cA value set to FALSE.
>
>The definition of domain is purely a matter of local policy.

David
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

Date: Fri, 04 Sep 1998 13:19:51 +0200
To: Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[email-masked]>
Sender: [email-masked]

At 08:48 PM 9/2/98 -0400, Santosh Chokhani wrote:
<snip>
>The way I look at the difference between the two options is that if
>n=n1+n2 certificates are issued to a CA, option 1 says CA puts n1 in one
>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>another.  When you retrieve the two buckets (which you must for path
>development efficiency), option 2 gives you n+n1 certificates and option
>1 gives you exactly all n.

I tried to point out before that this is not the whole picture.

The CA is dealing with n CA certificates n=n1+n2+n3+n4 of the form:
n1 = intra domain issued to other CA:s
n2 = intra domain issued by other CA:s to this CA
n3 = inter domain issued to other CA:s
n4 = inter domain issued by other CA:s to this CA

Option 1 stores only n2+n3+n4
(n2 in one bucket and n3+n4 in the other.)

Option 2 stores n1+2(n2)+n3+n4
(n2 in one bucket and n1+n2+n3+n4) in the other)

As you see, n1 is left out of option 1 (according to text)
You said then that it is not forbidden to store n1 (in option 1)
in the cross certificate pair. I guess then that option 1 should
changed-

from:
  Optionally, the reverse element of the
  crossCertificatePair attribute, held in a particular CA's directory entry,
  may contain certificates issued by this CA to CAs in other domains.

to:
  Optionally, the reverse element of the
  crossCertificatePair attribute, held in a particular CA's directory entry,
  may contain certificates issued by this CA to other CAs.

So if this is correct then what we are fighting about is only whether we
should duplicate n2 (out of n1,n2,n3 and n4). To me it sounds reasonable to
have the complete set of n1+n2+n3+n4 in one bucket and the n2 in the
cACertificate attribute as a specific information for those who wants to
have the CA:s guidance to define the inter domain subgroup. And since this
guidance by the CA may be useful in many situations, I consider option 2 as
the perfect compromise.

/Stefan

Date: Fri, 04 Sep 1998 12:20:04 +0200
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[email-masked]>
Sender: [email-masked]

Hi Bob,

At 06:42 PM 9/2/98 -0600, Bob Jueneman wrote:
<snip>
>>I suggest that we stick to the standardized definitions of the key usage
>>bits and leave
>>policy issues out of a common certificate profile.
>
>If there were any sense of the community as to what these definitions really
>mean, or ought to mean, we would probably not be having this discussion.
>Otherwise I would agree with you.
>>
>>non-repudiation is according to standard selected by the NR bit, not NR in
>>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>>other than non-repudiation are allowed for the key.
>
>I believe that is exactly the issue. Are you suggesting that NR plus DS
should not
>be allowed?  Why?

No I do not. I do suggest that such decision is up to local policy. But
there will be some policies where this combination will not be allowed, but
I think you agree to that.

The important thing is that I suggest that the NR bit and DS bit has
separate meaning and that they should be set independently to specify DS,
NR or both.

The vague definition of the NR bit is a problem, I agree to that.

If I were to define some distinguishing property of the NR bit that would be:

   Non repudiation denotes services constructed in such way that:
   1) The signature provides proof of the integrity and 
      origin of data - both in an unforgeable relationship - which can be 
      verified by any third party at any time.[X.509 / ISO 9594-8]
   2) The signature is applied to a message where the signatory is capable
      of, and required to, accept responsibility for the message content 
      before signing.
   3) The signatory's liability for signing the message can be concluded
      from the signed message itself, possibly within a well known and agreed 
      context that can be verified by any third party at any time.

This definitions rules out any signed logon ticket or other data
authentication mechanisms where the signature says "this message wasn't
changed" instead of "I take full responsibility for the message content".

But since this is not defined by the bit (which I regret) the way to go
will be for the CA to include this in it's published certificate policy.

I can't see any other way for now when utilizing the existing standard. I
would not object though to a defect report to get this into the standard.

In the new proposed work item, however, regaring a profile for
non-repudiation certificates supporting legal acceptance of digital
signatures I will try to get this definition in.

Would you support it?

/Stefan

From: [email-masked]
Date: Fri, 4 Sep 1998 05:56:52 -0400
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Content-type: multipart/mixed;  Boundary="0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5"
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Dave Horvath <[email-masked]> writes:

>> The difference between the two options is primarily storage efficiency
vs.
>> retrieval efficiency.  Both options divide a CAs certs into two piles.
>> Option 1 has pile A containing only intra-domain certs, and pile B
>> containing only inter-domain certs; option 2 has pile A containing only
>> intra-domain certs and pite B containing all certs.  Which option is
>> superior depends on two things:
>>
>>...
>>
>> Having the target CA divide its certificates between two places within
the
>> directory is no help to this verifier.  All it does it force the
verifier
>> to make two retrieval operations instead of the one that would be
required
>> by option 2.  The verifier isn't really interested in whether a
particular
>> certificate comes from another CA from the same "domain" as the target's
CA
>> - if it cares about "domains" at all, what it would be interested in is
if
>> any certs come from the same domain as the verifier (or one of its
trusted
>> roots), not the target (and of course that's verifier-specific).
>
>    John,  the verifier does NOT have to invoke two retrieval operations.
>The verifier simply reads the CA entry requesting both the cACertificate
>attribute and the crossCertificatePair attribute in the same search/read
>operation.  All certificates are returned.  The verifier can then decide
>whether to explore inter-domain, intra-domain, both , none, whatever.
>The verifier can lump them all together in the client application if
>they like!  The main advantage to option 1 is we don't store the
>certificates twice which is  a fundamental goal in all database
>applications.   IMHO it applies to repositories and public key
>infrastructures also.

There may not be two protocol actions across the wire, but it's definitely
less work for the client to receive a single set of objects all of the same
type, compared to the two sets of differently typed objects that option 1
requires it to retrieve.  Under option 2, verifiers that don't care about
the CAs ideas about domains can simply retrieve all the CAs certificates.
Having the CA divide its certificates into two piles only adds complexity
to the client's task.

The only place where verifiers will care about which domain the CA thinks
it's in, is if they think they (or one of their roots) are in the same
domain.  Only in that case is a verifier likely to decide to look first at
the CAs intra-domain certs, and option 2 allows for this choice just as
simply as does option 1.

The cost of this in option 2 is the duplication of some certificates in the
directory (we already have duplication in this area, unless the directory
has some intelligence that will enable it to store cross-cert pairs only
once and somehow place a reference to the shared object from both CA
entries).  But this duplication is at the discretion of the CA - if it
doesn't think the benefits of storing hints for local verifiers are
worthwhile, option 2 allows it to use _only_ the crossCertificate entry for
all its certs.

>    The general algorithm we envision is for clients to first explore the
>cACertificate attribute, then explore the crossCertificatePair
>attribute.   That way nothing will get missed.  It's not an all or
>nothing choice.  It's an attempt to store the certificates once and to
>group them to make logical decisions when exploring possibly complex
>paths.

But you can only make logical decisions when you have some data to work
with.  A CA has no idea when it's placing its certs in the directory about
who is going to come look for them.  Without knowing what domain the
verifier is in, the CA can't hope to help it out.  It can make a
special-case optimization under either option for the case where the
verifier is in the same domain as the CA  (which is really the only time
that either option offers any advantage over simply having a single entry
into which all certs are placed).

In summary, my contention is that very few verifiers will ever want to be
bothered with "domains" (or at least, not with some foreign CA's idea of
what a domain is).  Of the two options under discussion, option 2 allows
most verifiers to simply ignore the fact that a CA has chosen to issue
unwanted hints, and just retrieve the certs it wants from a single place.
The few verifiers that want to do something with a CA's hints can choose to
do so under either option, but option 1 would force all client software to
increase in complexity to gain that choice.  Option 2 burdens only those
clients that wish to exploit the hints.

John

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5
Content-type: application/octet-stream; 
	name="$RFC822.eml"
Content-Disposition: attachment; filename="$RFC822.eml"
Content-transfer-encoding: base64

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5--

Date: Fri, 04 Sep 1998 10:32:23 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Robert Zuccherato <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: TemporalData (Time Stamp Protocol)
Sender: [email-masked]

Robert,

In order to facilitate the implementation (and therefore acceptance) of
the Time Stamp Protocol draft, (draft-adams-time-stamp-02.txt) I think
we should provide the ASN.1 material in the 1988 syntax [since only a
few implementers have access to an updated 1994 ASN.1 compiler].

[Stephen Farrell just made the same request yesterday].

NB: [CCP] provides both 1988 and 1994 syntaxes and states that 1988
syntax takes precedence in case of conflict.

Only one adjustment need to be made for that draft : 
the TemporalData definition should be changed from :

TemporalData ::= SEQUENCE  {
     format                  TEMPORALDATACLASS.&id,   --objid
     rawdata                 TEMPORALDATACLASS.&Type  --open type  
}

TEMPORALDATACLASS ::= CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type } WITH SYNTAX  { &Type IDENTIFIED BY &id }

to :

TemporalData ::= SEQUENCE {
     format             OBJECT IDENTIFIER,
     rawdata            ANY DEFINED BY format }

(Please forgive me if I translated the 1994 ASN.1 syntax in a wrong way
since I'm not an ASN.1 fan or expert. :-)

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 04 Sep 1998 10:23:03 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Sender: [email-masked]

Carlisle,

(...)

I follow and fully support your argumentation. I came to the same
conclusions.

IN ADDITION, neither of OPTION 1 or OPTION 2, as written, is acceptable
for reasons which have nothing to do with duplication or location of
information. These reasons are indicated in a separate E-mail and are
related to mandating *mutual* cross certification (OPTION 1) or
forbiding the forward element of a certificate pair (i.e. certificates
issued for this CA by other CAs), if the reverse element is not present
(OPTION 2).

This is why the only acceptable choice for the time is OPTION 0, i.e.
the original text.

I would ask the chairs to :

1) look at the arguments raised about *mutual* cross certification and 
   unilateral cross certification,
2) reconsider the vote and extend it to OPTION 0, i.e. the current text.

A straw poll is not a coin toss, otherwise I would have already
answered. :-)

> The claimed advantage of option 1 is that this retrieval gets me
> certificates that are sorted into "intra-domain" and "inter-domain",
> which can help in efficient path construction.  Let's think about this
> for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
> TRUSTED BY ME  (because if it was directly trusted by me, I would
> already have a trusted copy of its public key and would not need
> certificates in which it was the subject).  If it is not directly
> trusted by me, then why would I necessarily trust it to do this sorting
> in a way that is beneficial to my path construction needs?  How does it
> know what *my* definition of "domain" is?  How does it know whether most
> of my certificate validations will be "intra" its definition of domain
> or "inter" its definition of domain?
 
> If this CA's definition of domain and my definition of domain do not
> coincide exactly (and why should they, since in general this CA and I
> have no pre-established relationship?), then this sorting performed by
> the CA is not merely useless to me, it is actually an explicit
> disadvantage (because the proponents of option 1 are recommending that
> all the intra-domain certificates be examined *before* the inter-domain
> certificates are examined, leading to worst-case path-construction times
> for what may turn out to be a common scenario).
 
> Relying parties know what certificates they will be validating most
> often, depending upon what particular activity they are engaged in at
> the moment.  THAT defines the relying parties' "intra" and "inter"
> domains.  CAs in the middle of a cert. path cannot possibly know this,
> in general, so having THEM define a domain and sort certificates
> according to that definition is really meaningless.
 
> Note that there will be special circumstances in which one definition of
> domain will be understood throughout a given environment (e.g., the
> strict hierarchy of CAs has been cited in previous posts on this topic).
> In such cases there is a clear efficiency advantage to be gained in path
> construction.  This is why option 2 is the perfect compromise:  for such
> environments relying parties need only retrieve the n1 < n certificates
> that they *know* will be useful to them.  Option 2 therefore meets the
> needs of the general case as well as the special case, while
> simultaneously guaranteeing interoperability of two installed bases
> which would otherwise have no hope of interoperating today.
 
> The price of this panacea?  A few redundant certificates in the
> Directory.  Is it really worth sacrificing the general- (and perhaps
> common-) case scenario, as well as interoperability, in order to save a
> few certificates and satisfy a particular special-case?  I haven't yet
> heard any convincing arguments...

Neither do I ...

Denis
 
> Carlisle.

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 04 Sep 1998 10:03:20 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Sharon Boeyen <[email-masked]>
CC: [email-masked], "'Santosh Chokhani'" <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

Sharon, 

> The "two buckets" is exactly what I was trying to avoid in the
> earlier debate on this topic, however I believe that the single 
> bucket option was rejected in the Chicago meeting. 

It was a pity that you could not attend the Chicago meeting. 
"rejected" may be a strong word. During the straw poll, I did not 
raised my hand for any of the three options for the following good 
reasons:

1) I had three weeks of holidays one week ahead of the meeting, :-)
2) When I came back, I had 470 E-mails waiting for me,
3) I completely skipped the thread on the LDAP schema, :-(

As a result I could not understand from the discussion what the topic
was and so I abstained. I would guess that I was not the single one in
that position. There was some support for it anyway, so I do not
understand why the straw poll is not on the three options but instead
only on two options.

> The single bucket option is the
> text which is currently in the Internet Draft. With that text, 
> all self signed (or self issued certificates) were to be placed 
> in the cACertificate attribute and all certificates issued by 
> one CA to a different CA were put in the crossCertificatePair 
> attribute. 

This was pretty nice and simple ! If I were to open the bunch of
messages, maybe I could understand why this is not acceptable.

> Depending on the particular path development algorithm being 
> used by a relying party, directory search tools, especially 
> when we evolve to LDAPv3 could be used to filter the content 
> of the forward and or reverse elements of that SINGLE attribute 
> and provide the relying party with the set of certificates of 
> interest to that particular relying party.

Indeed.
 
> I still believe that this is the best solution because the relying
> party systems are the ones that know which certs are of interest 
> to them, 

I agree with you.

> not the CA that happened to issue the certs, especially in the 
> post PEM world where any CA could legitimately have certs issued 
> for it by several CAs.
 
> My strong support for Option 2 in the straw poll is because 
> the above was rejected by the meeting and I see Option 2 as 
> a workable compromise ONLY because there is a complete set of 
> certs in a single attribute and relying parties can do what is 
> of interest to them without knowing the definition of domain 
> which each individual CA happens to use. For self contained 
> environments wanting to make use of a CA or set of CAs certs
> issued within some locally defined domain, this is still possible.

Let me take a look at option 1 and say why it is not acceptable ... 
because it imposes a model of trust that is too specific.

General comment: The notion of "domain" has never been introduced
before and since the understanding of a domain is "purely a matter 
of local policy" there is no chance that the requester understands 
what it means - unless we are in a close environment. 

I believe that this feature is being introduced to be used in close
environments for some "good" reasons. The text should explain these
"good" reasons otherwise readers of the document will ignore for ever
the rational.  

PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
OPTION 1:
----------------
The cACertificate attribute, held in a particular CA's directory
entry, shall be used to store certificates issued to this CA by CAs 
in the same domain as this CA. 

     When the notion of domain does not exists, then this will 
     be empty.

In addition, the cACertificate attribute shall be used to
store self-issued certificates.

     This is fine.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates
issued to this CA by CAs in other domains.  

     I have a problem here. Cross certification does not mean mutual 
     cross certification. A CA can cross-certify another CA without 
     any knowledge from the CA being cross certified. Even if the CA
     got the knowledge of it, that CA would not like to place that 
     certificate in that entry. Let us pick an example: a CA from 
     the Banana Republic of Baracuda is providing a certificate for 
     the NIST. I do not think that the NIST will necessarilly place
     that certificate in his entry. 

Optionally, the reverse element of the crossCertificatePair attribute, 
held in a particular CA's directory entry, may contain certificates 
issued by this CA to CAs in other domains.

     I have a problem here with the word "Optionally" : if the 
     previous element is not there, then I cannot place an element 
     here. This means that if CA 1 wants to recognize CA 2, 
     then CA 2 MUST also recognize CA 1. This mandates mutual cross
     certification. I do not think that we have ever mandated 
     *mutual* cross certification in PKIX-1.

     Thus OPTION 1 is NOT acceptable and this has nothing to do with 
     performance or path development.

In the case of V3 certificates, none of the above CA certificates may
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

OPTION 2:
-------------
The crossCertificatePair attribute, held in a particular CA's
directory entry, shall be used to store all certificates issued 
by this CA to other CAs, as well as certificates issued 
for this CA by other CAs. Values held in the forward element are 
certificates issued for this CA by other CAs, while values 
in the reverse element are certificates issued by this CA for
other CAs. 

     I would interpret the text as mandating to store the reverse 
     element and optionally the forward element. I would instead
     allow to store only the forward element, only the reverse 
     element or both. 

     Hence the OPTION 2 is NOT acceptable either and this has 
     nothing to do with performance or path development.

The text should be corrected and be something like:

     The crossCertificatePair  attribute,  held  in  a  particular  CA's
     directory  entry,  may be used to store certificates issued by this
     CA to other CAs, as well as certificates  issued  for  this  CA  by
     other  CAs.  Values  held  in  the forward element are certificates
     issued for this CA by other CAs, while values in the  reverse  ele-
     ment  are certificates issued by this CA for other CAs. Either cer-
     tificate, if present,  may be used in  building  certificate  paths
     for  validation  and  may  be published in the directory entries of
     either CA or both.

 ... which is exactly what is in the original text !

The cACertificate attribute, held in a particular CA's directory
entry, shall be used to store certificates issued to this CA by CAs 
in the same domain as this CA. This set of certificates is a subset 
of the values of the forward element of the crossCertificatePair 
attribute in the same CA entry.
 
In addition, the cACertificate attribute shall beused to store
self-issued certificates.  

     When there are no domains, and IF the text was corrected as 
     indicated hereabove (i.e. back to the text of the original 
     version) then we would be "compatible" with the previous 
     text, but this is not the case. Did I understood correctly ?

     I believe that there are "good" resons to introduce the 
     notion of "domain". Are these "good reasons" technical or 
     commercial ? If they are technical then they SHALL be 
     written in the document. But what about if they are 
     "commercial" ?

For the time being, I can only vote for OPTION 0 (i.e. the original
text) !

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Andrea Sansone" <[email-masked]>
To: [email-masked]
Date: Fri, 4 Sep 1998 08:21:29 +0200
Subject: for option 1
Sender: [email-masked]

From: Alan Lloyd <[email-masked]>
To: "'Frank O'Dwyer'" <[email-masked]>, Dave Horvath <[email-masked]>
Cc: [email-masked]
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Fri, 4 Sep 1998 14:22:16 +1000
Sender: [email-masked]

I have a few views in that certs must be supported by mutually
authenticated distributed X.500 directory systems otherwise 509 based
systems just  wont scale and provide the commercial utilitity as
demanded by global EC directed organisations. Not having this foundation
- one just drops into all sorts of operational cost, scaling and
efficiency holes.
The draft I put out attempts to put the onus on a CA to gets its
directory act in order with a common information architecture (DIB) and
not just a set of agreed object classes with multitudes of extensions
and options - and that the CAs and their supporting directories provide
a "sensible" set of validation services, starting  at a very base level
- for simple to implement client applications.

One aspect of the cross cert issue is for the CA/directory system  to
know what the originating and verifying domain is so that it can select
the necessary path information sets. 

there is some of this detail in my draft.

To me its all in the information management design of a CA and its
processing utilities and how that is effectively applied into a mutually
authenticated (cert matching ruled) distributed directory system...
Hence my previous comments about single server LDAP servers - they just
cannot do the job. 
regards alan

> -----Original Message-----
> From:	Frank O'Dwyer [SMTP:[email-masked]]
> Sent:	Friday, 4 September 1998 12:36
> To:	Dave Horvath
> Cc:	[email-masked]
> Subject:	path development complexity (was Re: What the straw poll
> means)
> 
> Dave Horvath wrote:
> >         We are back the problem we raised earlier.  Clients that
> attempt to
> > efficiently develop a path from the end entity to the trusted root
> must
> > explore 'n' paths (worst case scenario)  prior to finding the
> correct
> > one with option 2.  
> 
> This is not on the topic of the straw poll, but I was wondering if
> anyone has really looked into how difficult path development can get
> in
> a full-blown and well-connected global PKI? It seems to me that the
> real
> worst case scenario has you following cross-certificates until you
> have
> downloaded all the cross-certificates in the world. It would not have
> to
> get that bad before it was a serious problem.
> 
> A few things would help prune the search (like the depth you are
> willing
> to search to, constraints within the certificates themselves), but
> still
> in general it has the potential to get truly nasty. Unless I have
> missed
> something, there are no positive hints in the certificates that would
> guide path development (perhaps there should be? There is a
> resemblance
> to the "travelling salesman" problem here, and it would certainly be 
> ironic if building a path turned out to be as hard as factoring.:)
> 
> Anyone looked at this? If it is a problem, then it might be reasonable
> to give recommendations on using constraints (or something else) in
> order to encourage the creation of cross-certificates that are
> "path-development friendly", and in order to discourage scenarios that
> lead to directory search explosions.
> 
> Apologies if I am re-hashing something that has already been discussed
> here.
> 
> Cheers,
> Frank O'Dwyer.

Date: Thu, 03 Sep 1998 23:31:01 -0400
From: Tony Bates <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Fri, 04 Sep 1998 03:35:30 +0100
From: "Frank O'Dwyer" <[email-masked]>
To: Dave Horvath <[email-masked]>
CC: [email-masked]
Subject: path development complexity (was Re: What the straw poll means)
Sender: [email-masked]

Dave Horvath wrote:
>         We are back the problem we raised earlier.  Clients that attempt to
> efficiently develop a path from the end entity to the trusted root must
> explore 'n' paths (worst case scenario)  prior to finding the correct
> one with option 2.  

This is not on the topic of the straw poll, but I was wondering if
anyone has really looked into how difficult path development can get in
a full-blown and well-connected global PKI? It seems to me that the real
worst case scenario has you following cross-certificates until you have
downloaded all the cross-certificates in the world. It would not have to
get that bad before it was a serious problem.

A few things would help prune the search (like the depth you are willing
to search to, constraints within the certificates themselves), but still
in general it has the potential to get truly nasty. Unless I have missed
something, there are no positive hints in the certificates that would
guide path development (perhaps there should be? There is a resemblance
to the "travelling salesman" problem here, and it would certainly be 
ironic if building a path turned out to be as hard as factoring.:)

Anyone looked at this? If it is a problem, then it might be reasonable
to give recommendations on using constraints (or something else) in
order to encourage the creation of cross-certificates that are
"path-development friendly", and in order to discourage scenarios that
lead to directory search explosions.

Apologies if I am re-hashing something that has already been discussed
here.

Cheers,
Frank O'Dwyer.

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Where to store CA certificates
Date: Fri, 4 Sep 1998 12:02:04 +1000
Sender: [email-masked]

Agree with this - but in particular - if the directory system does not
correctly support distributed operations (as per X.500 DSP) and does not
implement certificate based matching rules and the client software does
not provide under what guise or domain they are validating from,  then
it (cert path processing and validation) is inefficient, may be fragile
and will be difficult to manage and therefore operationllay risky.

With no dir matching/filter  rules and accessing a CAs entry could bring
back CRLs, a bunch of CA cross certs and the client  may be none the
wiser. 

As per my other comments - dealing with 509 paths in a distributed way
without efficient distributed directories and cert based features seems
odd situation to discuss.

Views on my draft re dir - cert stat could progress the issue re
"complexity" and "efficiency" of validation actions.

regards alan

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Friday, 4 September 1998 10:11
> To:	'Ambarish Malpani'; [email-masked]'
> Subject:	RE: Where to store CA certificates
> 
> Ambarish:
> 
> We should explore your point further.  But, I am assuming that
> features
> such as subject public key identifier and authority public key
> identifier, name constraints (in conjunction with pathToName matching
> rule), key usage are available for proper digital signature
> certificate.
> The question becomes of these which one will lead to the trust anchor
> of
> the relying party from the current CA (assuming you are developing a
> path from subject to the relying party trust anchor).
> 
> I am afraid that the CA may not help much except say which
> certificates
> issued to it are from its domain/family/partners/preferred or whatever
> and which are from others.
> 
> I also see all of us doing rapid fire on this one without considering
> all the ramifications.  I am probably the worst culprit.  I will be
> the
> first one to admit that I am the worst offender.
> 
> I do not claim to have the solutions, full knowledge or the final word
> on the path development, but to use the PKI technology efficiently,
> lot
> may have to fall in place.  I am not sure directory products and
> client
> products are stepping up to offering the potential need for
> efficiency.
> 
> Let me give you simple example in which option 2 may choke the network
> and/or client if there are no matching rules implemented both in the
> directory and the client.  Let us assume that a CA has issued 30
> certificates to other CAs but has been issued very few certificates
> itself.  Under option 2, the CA must populate the reverse component of
> the crossCertificatePair attribute 30 times, and these will be
> returned
> on a query, if both the client and the directory do not implement
> matching rules.
> 
> I have thought long and hard and find that option 1 gives us the best
> hope for path development efficiency.
> 
> 
> > -----Original Message-----
> > From:	Ambarish Malpani [SMTP:[email-masked]]
> > Sent:	Thursday, September 03, 1998 12:54 PM
> > To:	[email-masked]'
> > Subject:	Where to store CA certificates
> > 
> > Hi Guys,
> >     Given the huge amount of passion that the topic of where one
> > stores CA certificates has generated, it seems to me that path
> > building is both a complicated and important thing ;-)
> > 
> >     If the premise above is true, wouldn't one want to prioritize
> > path building more precisely than just lumping CA certs into
> > one of two categories (intra-domain/inter-domain)?
> > 
> >     Would it make sense to have another attribute attached to
> > CA certificates - something like a "priority" field, with say
> > an integer value, where, during path building you first try to
> > build paths with the CA cert with the highest priority?
> > 
> >     Or is this a BAD idea, because it doesn't work with any of
> > the current implementations?
> > 
> > Comments? Sharon, Santosh?
> > 
> > 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: Alan Lloyd <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, Carlisle Adams <[email-masked]>
Cc: [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw		 poll means)
Date: Fri, 4 Sep 1998 11:29:45 +1000
Sender: [email-masked]

comments in line

> -----Original Message-----
> From:	Ambarish Malpani [SMTP:[email-masked]]
> Sent:	Friday, 4 September 1998 6:41
> To:	Carlisle Adams
> Cc:	[email-masked]
> Subject:	Re: Let's try to understand the real issue (was... RE:
> What the straw		 poll means)
> 
> Hi Carlisle,
>     Is the expectation that everybody is directly accessing their
> CA's LDAP directory? I always thought that each orginazation would
> actually maintain its own LDAP directory and, therefore, be able
> to specify which CAs are preferred over others.
> 
>     Are we really expecting people to share their directories with
> everyone in the world?
	[Alan Lloyd]  
	I think so - May be not quite share everything with everyone
but I think there will be vertical market sector directory systems such
as Defence, Finance, Transport, Health, Police, Postal, Telecomms, etc
and that little old me with my directory entry will have certificates in
- issued by them, so I can deal with these areas. And I will
interconnect my directory system so I can use the services and
privileges offered by these sectors. Just like my wallet contents allow
me today with a range of plastic card services. The main distraction
today is that LDAP servers are pointless devices (no distribution) for
wide scale EC or cert path processing. And it seems that most systems
being developed for CAs seem to grab an LDAP server (not an LDAP
accessed X.500 server) and from that point on simply limit their scope
of what a business does. In most cases all the business can do is do
business with its self and its own CA. 
	Its only when one realises that one has to connect ones Org
directory system to other Orgs and multiple CAs that one hits the
distribution issue - and throws the LDAP server in the bin.

	As for domains - I just see that as "the sphere of influence" or
if qualified like Management Domain or Directory Management Domain (see
X.501) it relates to the management influence and implied ownership of a
directory  or directory system. No Protocol or technical boundary is
enforced unless for example with directories by Name containment - its
usually an operational or business issue ie. with certs its how the
certs are applied with a management and business related policy.

	My usual thoughts
	regards alan

> Ambarish
> 
> 
> Carlisle Adams wrote:
> > 
> > Hi all,
> > 
> > I propose that we try (once again) to understand what the real issue
> is
> > here.
> > 
> > > ----------
> > > From:         Ryan Moats[SMTP:[email-masked]]
> > > Sent:         Thursday, September 03, 1998 12:14 PM
> > > To:   [email-masked]
> > > Cc:   [email-masked]
> > > Subject:      Retrieval efficiency herring? (was... RE: What the
> straw
> > > poll means)
> > >
> > > As somebody coming to the party late from the LDAP world, I don't
> see
> > > why
> > > the certificates need to be retrieved from two places.  An LDAP
> lookup
> > > of an
> > > object with a fairly simple filter (objectclass="*") will return
> all
> > > of the
> > > attributes associated with that object.  Therefore a single lookup
> > > will return
> > > both attributes, so I don't understand how retrieval efficiency is
> > > gained.
> > >
> > O.K., so we see that a single LDAP lookup can retrieve all
> certificates
> > (which, after careful enumeration, was found to be "n") in either
> option
> > 1 or option 2.
> > 
> > The claimed advantage of option 1 is that this retrieval gets me
> > certificates that are sorted into "intra-domain" and "inter-domain",
> > which can help in efficient path construction.  Let's think about
> this
> > for a moment.  The CA doing this sorting is, by definition, NOT
> DIRECTLY
> > TRUSTED BY ME  (because if it was directly trusted by me, I would
> > already have a trusted copy of its public key and would not need
> > certificates in which it was the subject).  If it is not directly
> > trusted by me, then why would I necessarily trust it to do this
> sorting
> > in a way that is beneficial to my path construction needs?  How does
> it
> > know what *my* definition of "domain" is?  How does it know whether
> most
> > of my certificate validations will be "intra" its definition of
> domain
> > or "inter" its definition of domain?
> > 
> > If this CA's definition of domain and my definition of domain do not
> > coincide exactly (and why should they, since in general this CA and
> I
> > have no pre-established relationship?), then this sorting performed
> by
> > the CA is not merely useless to me, it is actually an explicit
> > disadvantage (because the proponents of option 1 are recommending
> that
> > all the intra-domain certificates be examined *before* the
> inter-domain
> > certificates are examined, leading to worst-case path-construction
> times
> > for what may turn out to be a common scenario).
> > 
> > Relying parties know what certificates they will be validating most
> > often, depending upon what particular activity they are engaged in
> at
> > the moment.  THAT defines the relying parties' "intra" and "inter"
> > domains.  CAs in the middle of a cert. path cannot possibly know
> this,
> > in general, so having THEM define a domain and sort certificates
> > according to that definition is really meaningless.
> > 
> > Note that there will be special circumstances in which one
> definition of
> > domain will be understood throughout a given environment (e.g., the
> > strict hierarchy of CAs has been cited in previous posts on this
> topic).
> > In such cases there is a clear efficiency advantage to be gained in
> path
> > construction.  This is why option 2 is the perfect compromise:  for
> such
> > environments relying parties need only retrieve the n1 < n
> certificates
> > that they *know* will be useful to them.  Option 2 therefore meets
> the
> > needs of the general case as well as the special case, while
> > simultaneously guaranteeing interoperability of two installed bases
> > which would otherwise have no hope of interoperating today.
> > 
> > The price of this panacea?  A few redundant certificates in the
> > Directory.  Is it really worth sacrificing the general- (and perhaps
> > common-) case scenario, as well as interoperability, in order to
> save a
> > few certificates and satisfy a particular special-case?  I haven't
> yet
> > heard any convincing arguments...
> > 
> > Carlisle.
> 
> -- 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect					         650.567.5457
> ValiCert, Inc.
> [email-masked]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 20:33:53 -0400
Sender: [email-masked]

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 8:19 PM
> To:	[email-masked]'; 'Santosh Chokhani'
> Cc:	[email-masked]
> Subject:	RE: What the straw poll means
> 
>        
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > Sent: 	September 3, 1998 7:50 PM
> > To: 	[email-masked]'; Santosh Chokhani
> > Cc: 	[email-masked]
> > Subject: 	RE: What the straw poll means
> > 
> > John:
> > 
> > As Dave Horvath has replied, retrieval efficiency is the same.
> > 
> > Option 2 also retrieves all multiple certificates and hence
> introduces
> > communication delays and unnecessary bandwidth usage
> This is dependent on the query. 
> 
> For relying parties that have the same understanding of 'domain' as
> the
> CA, they could either 
> a) send an LDAP search request which retrieves ONLY the values of the
> cACertificate attribute and then after exhausting them, send another
> request that would retrieve the crossCertificatePair attribute values
> or
> 
	[]  In a), another bind and access to directory may cause delays

> b) send a single LDAP search request that would retrieve both
> attributes. In b) yes they woud retrieve the multiples. 
> In a) they would retrieve multiples only if they were unsuccessful
> with
> the 'domain' certs. In b) they would receive multiples.
> 
> Relying parties that ignore the 'domain' specifics would send a single
> LDAP search request that would retrieve only the crossCertificatePair
> attribute and would never receive multiples.
> > .
> > 
> > Using option 2, if a client only retrieves crossCertificatePair
> > attribute only, it loses potential for efficiency.
> > 
> > Your last paragraph is precisely my point.  Dividing the
> certificates
> > in
> > two buckets has potential for help and never hurts.
> > 
> > By the way, a class of application may choose to prefer exploring
> > inter-domain certificates first, if so deemed.
> > 
> > > -----Original Message-----
> > > From:	[email-masked] [SMTP:[email-masked]]
> > > Sent:	Thursday, September 03, 1998 8:51 AM
> > > To:	Santosh Chokhani
> > > Cc:	[email-masked]
> > > Subject:	RE: What the straw poll means
> > > 
> > > Santosh Chokhani <[email-masked]> writes:
> > > 
> > > >The basic difference between the two approaches is the under
> option
> > 1
> > > >you store a certificate only one time under a CA's entry.  Which
> > > >certifying CA is in its domain is upto a subject CA to decide.
> > > >
> > > >In all honesty, I do not see a benefit to option 2 except for the
> > > >argument that some installed base already does it this way.
> > > 
> > > The difference between the two options is primarily storage
> > efficiency
> > > vs.
> > > retrieval efficiency.  Both options divide a CAs certs into two
> > piles.
> > > Option 1 has pile A containing only intra-domain certs, and pile B
> > > containing only inter-domain certs; option 2 has pile A containing
> > > only
> > > intra-domain certs and pite B containing all certs.  Which option
> is
> > > superior depends on two things:
> > > 
> > >    whether you care more about storage efficiency in the directory
> > > (option
> > >    2 stores intra-domain certificates twice) or retrieval
> efficiency
> > > for
> > >    the verifier (option 1 require a verifier that wants all a
> target
> > > CA's
> > >    certificates to retrieve them from two places).
> > >    typical usage scenarios by verifiers - i.e. the percentage of
> > > clients
> > >    that are going to want to locate just inter-domain certs,
> > compared
> > > to
> > >    clients that either don't care about the difference or are only
> > >    interested in intra-domain certs.  Retrieval of _just_
> > inter-domain
> > >    certs is easier under option 1, retrieval of _all_ certs is
> > easier
> > > under
> > >    option 2, and retrieval of _just_ intra-domain certs is the
> same
> > > under
> > >    both options.
> > > 
> > > 
> > > Consider a fairly randomly structured PKI, where the verifier has
> a
> > > set of
> > > trusted roots loaded into it (assume they've been loaded under
> user
> > > control, with no particular order to them), and is trying to
> verify
> > > the key
> > > of some server that it hasn't spoken to before.  It has no idea of
> > > which
> > > "domain" the target's CA thinks it belongs to; it just wants to
> pull
> > > all
> > > the certs that have that CA as a subject, and see if it can
> > construct
> > > a
> > > valid chain starting at one of its trusted roots.
> > > 
> > > Having the target CA divide its certificates between two places
> > within
> > > the
> > > directory is no help to this verifier.  All it does it force the
> > > verifier
> > > to make two retrieval operations instead of the one that would be
> > > required
> > > by option 2.  The verifier isn't really interested in whether a
> > > particular
> > > certificate comes from another CA from the same "domain" as the
> > > target's CA
> > > - if it cares about "domains" at all, what it would be interested
> in
> > > is if
> > > any certs come from the same domain as the verifier (or one of its
> > > trusted
> > > roots), not the target (and of course that's verifier-specific).
> > > 
> > > For the special (and probably quite common) case where the
> verifier
> > > and
> > > target happen to be in the same domain, the distinction probably
> is
> > > useful.
> > > Option 2 supports this case just as well as does option 1, by
> > allowing
> > > the
> > > CA to place intra-domain certs in a separate place so that clients
> > in
> > > that
> > > domain can retrieve them first (or possibly even _instead_of_
> going
> > to
> > > the
> > > all-certs list).
> > > 
> > > John
> > > 
> > 

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 01:19:16 +0100
Sender: [email-masked]

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 3, 1998 7:50 PM
> To: 	[email-masked]'; Santosh Chokhani
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> John:
> 
> As Dave Horvath has replied, retrieval efficiency is the same.
> 
> Option 2 also retrieves all multiple certificates and hence introduces
> communication delays and unnecessary bandwidth usage
This is dependent on the query. 

For relying parties that have the same understanding of 'domain' as the
CA, they could either 
a) send an LDAP search request which retrieves ONLY the values of the
cACertificate attribute and then after exhausting them, send another
request that would retrieve the crossCertificatePair attribute values or

b) send a single LDAP search request that would retrieve both
attributes. In b) yes they woud retrieve the multiples. 
In a) they would retrieve multiples only if they were unsuccessful with
the 'domain' certs. In b) they would receive multiples.

Relying parties that ignore the 'domain' specifics would send a single
LDAP search request that would retrieve only the crossCertificatePair
attribute and would never receive multiples.
> .
> 
> Using option 2, if a client only retrieves crossCertificatePair
> attribute only, it loses potential for efficiency.
> 
> Your last paragraph is precisely my point.  Dividing the certificates
> in
> two buckets has potential for help and never hurts.
> 
> By the way, a class of application may choose to prefer exploring
> inter-domain certificates first, if so deemed.
> 
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Thursday, September 03, 1998 8:51 AM
> > To:	Santosh Chokhani
> > Cc:	[email-masked]
> > Subject:	RE: What the straw poll means
> > 
> > Santosh Chokhani <[email-masked]> writes:
> > 
> > >The basic difference between the two approaches is the under option
> 1
> > >you store a certificate only one time under a CA's entry.  Which
> > >certifying CA is in its domain is upto a subject CA to decide.
> > >
> > >In all honesty, I do not see a benefit to option 2 except for the
> > >argument that some installed base already does it this way.
> > 
> > The difference between the two options is primarily storage
> efficiency
> > vs.
> > retrieval efficiency.  Both options divide a CAs certs into two
> piles.
> > Option 1 has pile A containing only intra-domain certs, and pile B
> > containing only inter-domain certs; option 2 has pile A containing
> > only
> > intra-domain certs and pite B containing all certs.  Which option is
> > superior depends on two things:
> > 
> >    whether you care more about storage efficiency in the directory
> > (option
> >    2 stores intra-domain certificates twice) or retrieval efficiency
> > for
> >    the verifier (option 1 require a verifier that wants all a target
> > CA's
> >    certificates to retrieve them from two places).
> >    typical usage scenarios by verifiers - i.e. the percentage of
> > clients
> >    that are going to want to locate just inter-domain certs,
> compared
> > to
> >    clients that either don't care about the difference or are only
> >    interested in intra-domain certs.  Retrieval of _just_
> inter-domain
> >    certs is easier under option 1, retrieval of _all_ certs is
> easier
> > under
> >    option 2, and retrieval of _just_ intra-domain certs is the same
> > under
> >    both options.
> > 
> > 
> > Consider a fairly randomly structured PKI, where the verifier has a
> > set of
> > trusted roots loaded into it (assume they've been loaded under user
> > control, with no particular order to them), and is trying to verify
> > the key
> > of some server that it hasn't spoken to before.  It has no idea of
> > which
> > "domain" the target's CA thinks it belongs to; it just wants to pull
> > all
> > the certs that have that CA as a subject, and see if it can
> construct
> > a
> > valid chain starting at one of its trusted roots.
> > 
> > Having the target CA divide its certificates between two places
> within
> > the
> > directory is no help to this verifier.  All it does it force the
> > verifier
> > to make two retrieval operations instead of the one that would be
> > required
> > by option 2.  The verifier isn't really interested in whether a
> > particular
> > certificate comes from another CA from the same "domain" as the
> > target's CA
> > - if it cares about "domains" at all, what it would be interested in
> > is if
> > any certs come from the same domain as the verifier (or one of its
> > trusted
> > roots), not the target (and of course that's verifier-specific).
> > 
> > For the special (and probably quite common) case where the verifier
> > and
> > target happen to be in the same domain, the distinction probably is
> > useful.
> > Option 2 supports this case just as well as does option 1, by
> allowing
> > the
> > CA to place intra-domain certs in a separate place so that clients
> in
> > that
> > domain can retrieve them first (or possibly even _instead_of_ going
> to
> > the
> > all-certs list).
> > 
> > John
> > 
> 

From: Santosh Chokhani <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 20:10:53 -0400
Sender: [email-masked]

Ambarish:

We should explore your point further.  But, I am assuming that features
such as subject public key identifier and authority public key
identifier, name constraints (in conjunction with pathToName matching
rule), key usage are available for proper digital signature certificate.
The question becomes of these which one will lead to the trust anchor of
the relying party from the current CA (assuming you are developing a
path from subject to the relying party trust anchor).

I am afraid that the CA may not help much except say which certificates
issued to it are from its domain/family/partners/preferred or whatever
and which are from others.

I also see all of us doing rapid fire on this one without considering
all the ramifications.  I am probably the worst culprit.  I will be the
first one to admit that I am the worst offender.

I do not claim to have the solutions, full knowledge or the final word
on the path development, but to use the PKI technology efficiently, lot
may have to fall in place.  I am not sure directory products and client
products are stepping up to offering the potential need for efficiency.

Let me give you simple example in which option 2 may choke the network
and/or client if there are no matching rules implemented both in the
directory and the client.  Let us assume that a CA has issued 30
certificates to other CAs but has been issued very few certificates
itself.  Under option 2, the CA must populate the reverse component of
the crossCertificatePair attribute 30 times, and these will be returned
on a query, if both the client and the directory do not implement
matching rules.

I have thought long and hard and find that option 1 gives us the best
hope for path development efficiency.

> -----Original Message-----
> From:	Ambarish Malpani [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 12:54 PM
> To:	[email-masked]'
> Subject:	Where to store CA certificates
> 
> Hi Guys,
>     Given the huge amount of passion that the topic of where one
> stores CA certificates has generated, it seems to me that path
> building is both a complicated and important thing ;-)
> 
>     If the premise above is true, wouldn't one want to prioritize
> path building more precisely than just lumping CA certs into
> one of two categories (intra-domain/inter-domain)?
> 
>     Would it make sense to have another attribute attached to
> CA certificates - something like a "priority" field, with say
> an integer value, where, during path building you first try to
> build paths with the CA cert with the highest priority?
> 
>     Or is this a BAD idea, because it doesn't work with any of
> the current implementations?
> 
> Comments? Sharon, Santosh?
> 
> 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: Sharon Boeyen <[email-masked]>
To: [email-masked], [email-masked], "'John Everson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:59:48 +0100
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	John Everson[SMTP:[email-masked]]
> Sent: 	September 3, 1998 10:52 AM
> To: 	[email-masked]; [email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> 
> Does this mean there will be a new option (3):
> 
> container/pile of intra-domain certs
> container/pile of inter-domain certs
> container/pile of all certs
> 
> Or do we throw everything into one container and offer a different 
> mechanism for distinction?
> 
> 
	The 'one container' option is the solution as per the current
text in the internet draft. 

> -----Original Message-----
> From: John.Wray [mailto:[email-masked]]
> Sent: Thursday, September 03, 1998 7:51 AM
> To: chokhani
> Cc: John.Wray; ietf-pkix
> Subject: RE: What the straw poll means
> 
> 
> Santosh Chokhani <[email-masked]> writes:
> 
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> 
> The difference between the two options is primarily storage efficiency
> 
> vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing
> only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
> 
>    whether you care more about storage efficiency in the directory 
> (option
>    2 stores intra-domain certificates twice) or retrieval efficiency
> for
>    the verifier (option 1 require a verifier that wants all a target 
> CA's
>    certificates to retrieve them from two places).
>    typical usage scenarios by verifiers - i.e. the percentage of
> clients
>    that are going to want to locate just inter-domain certs, compared
> to
>    clients that either don't care about the difference or are only
>    interested in intra-domain certs.  Retrieval of _just_ inter-domain
>    certs is easier under option 1, retrieval of _all_ certs is easier 
> under
>    option 2, and retrieval of _just_ intra-domain certs is the same 
> under
>    both options.
> 
> 
> Consider a fairly randomly structured PKI, where the verifier has a
> set 
> of
> trusted roots loaded into it (assume they've been loaded under user
> control, with no particular order to them), and is trying to verify
> the 
> key
> of some server that it hasn't spoken to before.  It has no idea of
> which
> "domain" the target's CA thinks it belongs to; it just wants to pull
> all
> the certs that have that CA as a subject, and see if it can construct
> a
> valid chain starting at one of its trusted roots.
> 
> Having the target CA divide its certificates between two places within
> 
> the
> directory is no help to this verifier.  All it does it force the 
> verifier
> to make two retrieval operations instead of the one that would be 
> required
> by option 2.  The verifier isn't really interested in whether a 
> particular
> certificate comes from another CA from the same "domain" as the 
> target's CA
> - if it cares about "domains" at all, what it would be interested in
> is 
> if
> any certs come from the same domain as the verifier (or one of its 
> trusted
> roots), not the target (and of course that's verifier-specific).
> 
> For the special (and probably quite common) case where the verifier
> and
> target happen to be in the same domain, the distinction probably is 
> useful.
> Option 2 supports this case just as well as does option 1, by allowing
> 
> the
> CA to place intra-domain certs in a separate place so that clients in 
> that
> domain can retrieve them first (or possibly even _instead_of_ going to
> 
> the
> all-certs list).
> 
> John
> 
> 
> 

From: "Eaton, James (EATO)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 17:01:52 -0700 
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, Dave Horvath <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:53:58 +0100
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 3, 1998 7:41 PM
> To: 	'Bill Burr'; Dave Horvath
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> Bill, 
> 
> But under option 1 also all certificates are there since LAP gives you
> all the attributes.
> 
> All option 1 does is reduce the communication load, 
Disagree - this is dependent on the query placed by the client system
> processing load,
Disagree - this is dependent on the certificate and path discovery
algorithm 
and mechanism used by the client system
> storage load 
Agree - in those cases where the local definition of "domain" results in
duplication
> and provide you a potential for efficiency.  
Possibly in a closed specific environment to tthe detriment of other
clients
> With very,
> very little software complexity
Implementation specific
> , you have a potential for gaining a lot
> on the computational complexity.
Algorithm and process specific

> > -----Original Message-----
> > From:	Bill Burr [SMTP:[email-masked]]
> > Sent:	Thursday, September 03, 1998 12:48 PM
> > To:	Dave Horvath
> > Cc:	[email-masked]
> > Subject:	Re: What the straw poll means
> > 
> > But what is a root here?  Does it imply that a domain is PKI
> > hierarchy?  I
> > can think of 3 plausible constructions of root, all of which I
> believe
> > I've
> > seen used: 
> > 
> > (1) any CA whose key you choose to trust and therefore can start a
> > certification path, but which may not imply any other organization
> or
> > structure;
> > 
> > (2) a CA whose key everybody in the domain (what's a domain?) trusts
> > and
> > which sits on top of a hierarchical unidirectional certification
> tree
> > (as
> > in MISSI or PEM);
> > 
> > (3) a CA that exists to cross-certify with other CAs, but issues few
> > or no
> > end entity certificates, and starts few or no certification paths;
> it
> > simply exists to connect other CAs.  Examples would be the ANX
> > "supervisory
> > CA," the Gov. of Canada "Level 0" CA operated by the Canadian
> Central
> > Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is
> often
> > depicted at the hub of a mesh, or the top of a hierarchy, and
> operated
> > in
> > conjunction with the overall domain policy management authority.
> > 
> > 
> > I suppose a "trusted root" can be either 1 or 2 above.
> > 
> > But "root" to me doesn't necessarily say much about path
> development,
> > or
> > PKI certification path structure.
> > 
> > How about domain? What does it mean?  I claim that the term makes
> most
> > sense to mean a part of a PKI that operates under the direction of a
> > policy
> > management entity. Which wouldn't necessarily mean that domain
> > boundaries
> > coincide with distinctions that are meaningful for certification
> path
> > building.
> > 
> > Option 1 is probably useful if you think that a domain is
> everything
> > subordinate to the same root CA, where a root is any CA that
> somebody
> > uses
> > to start a trust path.  So in a cross-certified mesh PKI, every CA
> is
> > a
> > domain onto itself, and all CA certificates wind up only, I think,
> in
> > the
> > crossCertificatePair attribute.  But in a hierarchical PKI most
> > certificates wind up in the cACertificate Attribute.  
> > 
> > I have the feeling that Bob is right at least for option 1, unless
> we
> > know
> > what a domain is we hardly know what we are getting.  With option 2,
> I
> > suppose we are guaranteed that all certificates wind up in
> > crossCertificatePair, whatever domain means.  
> > 
> > At 11:14 AM 9/3/98 -0400, you wrote:
> > >Bob,
> > >
> > >    I feel that the definition of domain is a local policy and that
> > CAs
> > >should be free to define it as they wish.   Clients  that
> search/read
> > CAs
> > >entries and obtain the values from both the cACertificate and
> > >crossCertificatePair attributes can explore the values in the
> > cACertficate
> > >attribute first.  If a path to the trusted root is found,
> processing
> > stops.
> > >If not, they can explore the crossCertificatePair attribute.  Using
> > this
> > >algorithm CAs can define their domain and post each of their CA
> > certificates
> > >to one attribute or the other.  The only adverse affect will be
> > efficiency
> > >in path development  on the client side if the CA does not
> carefully
> > select
> > >intra or inter domain.  WIth option 1, the certificates are not
> > duplicated.
> > >With option 2, they are.
> > >
> > >But if we have an installed base that only looks in the
> > crossCertificatePair
> > >attribute, then we have a problem.  In that case option 2 will help
> > at the
> > >expense of duplicating the data.   I suggest we avoid duplication
> if
> > >possible, but we certainly must evaluate the installed base.
> > >
> > >Dave Horvath
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Bob Jueneman <[email-masked]>
> > >To: [email-masked] <[email-masked]>;
> [email-masked]
> > ><[email-masked]>
> > >Date: Wednesday, September 02, 1998 10:21 PM
> > >Subject: RE: What the straw poll means
> > >
> > >
> > >>Santosh doesn't seem to have answered the questions I've raised
> > >>regarding the definition of the domain, but he seems to believe
> that
> > >>option 2 doesn't solve that problem either.
> > >>
> > >>If so, I am increasingly beginning to lean towards "NONE OF THE
> > >>ABOVE".
> > >>
> > >>Rebuttal, Sharon/Carlisle?
> > >>
> > >>Bob
> > >>
> > >>>Yes Bob.  I hate to say this, but you have misinterpreted.
> > >>>
> > >>>The basic difference between the two approaches is the under
> option
> > 1
> > >>>you store a certificate only one time under a CA's entry.  Which
> > >>>certifying CA is in its domain is upto a subject CA to decide.
> > >>>
> > >>>In all honesty, I do not see a benefit to option 2 except for the
> > >>>argument that some installed base already does it this way.
> > >>>
> > >>>Option 1 achieves everything option 2 and with efficiency.
> > >>>
> > >>>I do not understand how option 2 solves your problems either.  We
> > need
> > >>>to have a discussion on computational complexity of path
> > development to
> > >>>allay your concerns.
> > >>>
> > >>>The way I look at the difference between the two options is that
> if
> > >>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1
> in
> > one
> > >>>bucket and n2 in another.  Option 2 says put n in one bucket and
> n1
> > in
> > >>>another.  When you retrieve the two buckets (which you must for
> > path
> > >>>development efficiency), option 2 gives you n+n1 certificates and
> > option
> > >>>1 gives you exactly all n.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Bob Jueneman [SMTP:[email-masked]]
> > >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> > >>>> To: [email-masked]
> > >>>> Cc: [email-masked]
> > >>>> Subject: What the straw poll means
> > >>>>
> > >>>> This is almost as exciting as watching a horse race!
> > >>>>
> > >>>> But what are we to make of the situation if the vote is as
> > >>>> close as it appears to be at present -- does that truly
> indicate
> > >>>> a "rough consensus"?
> > >>>>
> > >>>> As of earlier this morning, Chromatix was ahead, with
> > >>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> > >>>> cast; and MISSI some others are clustered around third place.
> > >>>>
> > >>>> So far, with the exception of a split between MISSI and NIST
> > >>>> as two US Government factions, the voting seems to be
> > >>>> strictly by company.
> > >>>>
> > >>>> Now, the polite fiction within the IETF is that memberships are
> > by
> > >>>> individual, and that there are no "votes" per se, and certainly
> > not
> > >>>> on a company by company basis. That's the fiction, at least..
> > >>>> Whether this convention shall long endure now that the IETF has
> > >>>> apparently lost some or all of its government funding and has
> > >>>> to become more self-sufficient will be interesting to see.
> > >>>>
> > >>>> But unless one side or the other starts to make some
> significant
> > >>>> in-roads by the dint of more persuasive technical argument,
> then
> > I
> > >>>> think
> > >>>> it's effectively a draw, and we may be counting companies and
> > their
> > >>>> installed base at least as much, and perhaps more, than
> > >>>> balancing the technical alternatives.
> > >>>>
> > >>>> Now, if we are truly at a technical impasse and the vote has to
> > be
> > >>>> binary, i.e., only one way or the other, then maybe counting
> > installed
> > >>>> clients and minimizing the pain is really the way to go, but
> > frankly
> > >>>> that approach makes me uncomfortable.  I want both
> > interoperability
> > >>>> AND efficiency, and I would hate to see us don't want to be
> > >>>> pressured into a less than satisfactory decision, whatever that
> > is,
> > >>>>  just because we are in a rush to get over the next hurdle in
> the
> > >>>> standards progression.
> > >>>>
> > >>>> I originally said that I was inclined to go with option 1,
> > because
> > >>>> it at least appeared to be simpler.  However, I also said that
> I
> > was
> > >>>> concerned about the "local" definition of a domain by a CA,
> > >>>> and the more I think about it, the more concerned I get.
> > >>>>
> > >>>> That approach might be viable for an organization such as
> MISSI,
> > >>>> where everyone presumably knows what community of interest
> > >>>> they fall into, but how would it apply to a public CA such as
> > >>>> VeriSign?
> > >>>>
> > >>>> Would they view all of their certificates as falling into one
> > domain,
> > >>>> including any certificates issued by subordinate CAs, as in the
> > case
> > >>>> of the old RSA Commercial hierarchy?
> > >>>>
> > >>>> What about GTE CyberTrust, considering their presumed affinity
> > >>>> with their ISP business. Would all of those certificates fall
> > into
> > >>>> one domain?
> > >>>>
> > >>>> Now suppose I want to validate a certificate from Erols.  Do I
> > decide
> > >>>> that
> > >>>> because Erols is in the top half of the alphabet that they
> > probably
> > >>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we
> do
> > an
> > >>>> East Coast/West Coast split, like radio and TV stations use W
> or
> > K in
> > >>>> their call sign?
> > >>>>
> > >>>> What if Novell and Microsoft were to become CAs and issue
> > certificates
> > >>>>
> > >>>> to their customers directly, at least their larger accounts.
> > Would
> > >>>> the relying
> > >>>> party have to try to divine whether a subscriber was running
> > NetWare
> > >>>> or
> > >>>> NT in order to decide what domain they would be likely to be
> in?
> > >>>>
> > >>>> Santosh, have I misrepresented the issue here?  Feel free to
> > correct
> > >>>> me, if so.
> > >>>> Maybe I just don't understand.
> > >>>>
> > >>>> Now, if the definition of "domain" were amended somewhat,
> perhaps
> > some
> > >>>> of these difficulties might go away.
> > >>>>
> > >>>> In particular, it seems to me that "domain" probably ought to
> > have a
> > >>>> lot to do
> > >>>> with name subordination, or at least the possibility of doing
> > name
> > >>>> subordination,
> > >>>> so that it would be deterministic.  That might not solve all of
> > the
> > >>>> concerns that those
> > >>>> who are inclined to vote for option 2 might have in mind, but
> it
> > might
> > >>>> help.
> > >>>>
> > >>>> So if I am a Novell employee, and I receive an S/MIME message
> > that
> > >>>> contains
> > >>>> a certificate that begins with c=US, o=Novell, I can probably
> > make an
> > >>>> excellent
> > >>>> good guess of what CA to go to, assuming that Novell operates a
> > CA in
> > >>>> its
> > >>>> own name.  But where do I go for a certificate from Acme
> > >>>> Manufacturing?
> > >>>>
> > >>>> I don't mean to beat up on the option 1 folks exclusively --
> > maybe
> > >>>> there are
> > >>>> some things that could be done within the options 2 that would
> > come
> > >>>> closer to a
> > >>>> compromise without breaking those existing clients.  But I need
> > to
> > >>>> think about that
> > >>>> some more.  maybe someone else could volunteer some
> suggestions.
> > >>>>
> > >>>> Bob
> > >>>>
> > >>>> Robert R. Jueneman
> > >>>> Novell, Inc.
> > >>>> 122 E. 1700 South
> > >>>> Provo, UT 84606
> > >>>> [email-masked]
> > >>>> 1-801-861-7387
> > >>
> > >>
> > >
> > >
> > Regards,
> > 
> > Bill Burr
> 

From: Santosh Chokhani <[email-masked]>
To: "'Carlisle Adams'" <[email-masked]>, [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw poll means)
Date: Thu, 3 Sep 1998 19:57:16 -0400
Sender: [email-masked]

> -----Original Message-----
> From:	Carlisle Adams [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 2:25 PM
> To:	[email-masked]
> Subject:	Let's try to understand the real issue (was... RE: What
> the straw poll means)
> 
> Hi all,
> 
> I propose that we try (once again) to understand what the real issue
> is
> here.
> 
> > ----------
> > From: 	Ryan Moats[SMTP:[email-masked]]
> > Sent: 	Thursday, September 03, 1998 12:14 PM
> > To: 	[email-masked]
> > Cc: 	[email-masked]
> > Subject: 	Retrieval efficiency herring? (was... RE: What the straw
> > poll means)
> > 
> > As somebody coming to the party late from the LDAP world, I don't
> see
> > why
> > the certificates need to be retrieved from two places.  An LDAP
> lookup
> > of an
> > object with a fairly simple filter (objectclass="*") will return all
> > of the
> > attributes associated with that object.  Therefore a single lookup
> > will return
> > both attributes, so I don't understand how retrieval efficiency is
> > gained.
> > 
> O.K., so we see that a single LDAP lookup can retrieve all
> certificates
> (which, after careful enumeration, was found to be "n") in either
> option
> 1 or option 2.
> 
	[]  If you only retrieve crossCertificatePair attribute under
option 2, you view the certificates of a single type and you lose path
development efficiency.

> The claimed advantage of option 1 is that this retrieval gets me
> certificates that are sorted into "intra-domain" and "inter-domain",
> which can help in efficient path construction.  Let's think about this
> for a moment.  The CA doing this sorting is, by definition, NOT
> DIRECTLY
> TRUSTED BY ME  (because if it was directly trusted by me, I would
> already have a trusted copy of its public key and would not need
> certificates in which it was the subject).  If it is not directly
> trusted by me, then why would I necessarily trust it to do this
> sorting
> in a way that is beneficial to my path construction needs?  How does
> it
> know what *my* definition of "domain" is?  How does it know whether
> most
> of my certificate validations will be "intra" its definition of domain
> or "inter" its definition of domain?
> 
> If this CA's definition of domain and my definition of domain do not
> coincide exactly (and why should they, since in general this CA and I
> have no pre-established relationship?), then this sorting performed by
> the CA is not merely useless to me, it is actually an explicit
> disadvantage (because the proponents of option 1 are recommending that
> all the intra-domain certificates be examined *before* the
> inter-domain
> certificates are examined, leading to worst-case path-construction
> times
> for what may turn out to be a common scenario).
> 
	[]  In these situations, you are no worse off than throwing the
certificates in one bucket.

> Relying parties know what certificates they will be validating most
> often, depending upon what particular activity they are engaged in at
> the moment.  THAT defines the relying parties' "intra" and "inter"
> domains.  CAs in the middle of a cert. path cannot possibly know this,
> in general, so having THEM define a domain and sort certificates
> according to that definition is really meaningless.
> 
	[]  This can be easily achieved using certificate and/or
certificate path caching.

> Note that there will be special circumstances in which one definition
> of
> domain will be understood throughout a given environment (e.g., the
> strict hierarchy of CAs has been cited in previous posts on this
> topic).
> In such cases there is a clear efficiency advantage to be gained in
> path
> construction.  This is why option 2 is the perfect compromise:  for
> such
> environments relying parties need only retrieve the n1 < n
> certificates
> that they *know* will be useful to them.  Option 2 therefore meets the
> needs of the general case as well as the special case, while
> simultaneously guaranteeing interoperability of two installed bases
> which would otherwise have no hope of interoperating today.
> 
> The price of this panacea?  A few redundant certificates in the
> Directory.  Is it really worth sacrificing the general- (and perhaps
> common-) case scenario, as well as interoperability, in order to save
> a
> few certificates and satisfy a particular special-case?  I haven't yet
> heard any convincing arguments...
> 
> Carlisle.

From: Santosh Chokhani <[email-masked]>
To: "'Nada Kapidzic Cicovic'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:53:00 -0400
Sender: [email-masked]

> -----Original Message-----
> From:	Nada Kapidzic Cicovic [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 5:03 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
> Cc:	Santosh Chokhani
> Subject:	RE: What the straw poll means
> 
> At 20:48 9/2/98 -0400, Santosh Chokhani wrote:
> >Yes Bob.  I hate to say this, but you have misinterpreted.
> >
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> >
> >Option 1 achieves everything option 2 and with efficiency.
> >
> >I do not understand how option 2 solves your problems either.  We
> need
> >to have a discussion on computational complexity of path development
> to
> >allay your concerns.
> >
> >The way I look at the difference between the two options is that if
> >n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> one
> >bucket and n2 in another.  Option 2 says put n in one bucket and n1
> in
> >another.  When you retrieve the two buckets (which you must for path
> >development efficiency), option 2 gives you n+n1 certificates and
> option
> >1 gives you exactly all n.
> 
> With option 2 you do not have to look at n1 certificates
> (cACertificate
> attribute) at all. The n ones (from crossCertificatePair) are
> sufficient
> for your path building.
> 
	[]  In that case you have potential for inefficiency in path
development.  

> Nada
> 
> >
> >> -----Original Message-----
> >> From:	Bob Jueneman [SMTP:[email-masked]]
> >> Sent:	Wednesday, September 02, 1998 8:33 PM
> >> To:	[email-masked]
> >> Cc:	[email-masked]
> >> Subject:	What the straw poll means
> >> 
> >> This is almost as exciting as watching a horse race!
> >> 
> >> But what are we to make of the situation if the vote is as 
> >> close as it appears to be at present -- does that truly indicate 
> >> a "rough consensus"?
> >> 
> >> As of earlier this morning, Chromatix was ahead, with 
> >> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
> >> cast; and MISSI some others are clustered around third place.
> >> 
> >> So far, with the exception of a split between MISSI and NIST
> >> as two US Government factions, the voting seems to be 
> >> strictly by company.
> >> 
> >> Now, the polite fiction within the IETF is that memberships are by
> >> individual, and that there are no "votes" per se, and certainly not
> 
> >> on a company by company basis. That's the fiction, at least.. 
> >> Whether this convention shall long endure now that the IETF has 
> >> apparently lost some or all of its government funding and has 
> >> to become more self-sufficient will be interesting to see.
> >> 
> >> But unless one side or the other starts to make some significant
> >> in-roads by the dint of more persuasive technical argument, then I
> >> think
> >> it's effectively a draw, and we may be counting companies and their
> 
> >> installed base at least as much, and perhaps more, than 
> >> balancing the technical alternatives.
> >> 
> >> Now, if we are truly at a technical impasse and the vote has to be 
> >> binary, i.e., only one way or the other, then maybe counting
> installed
> >> clients and minimizing the pain is really the way to go, but
> frankly 
> >> that approach makes me uncomfortable.  I want both interoperability
> >> AND efficiency, and I would hate to see us don't want to be 
> >> pressured into a less than satisfactory decision, whatever that is,
> >>  just because we are in a rush to get over the next hurdle in the 
> >> standards progression.
> >> 
> >> I originally said that I was inclined to go with option 1, because 
> >> it at least appeared to be simpler.  However, I also said that I
> was  
> >> concerned about the "local" definition of a domain by a CA,
> >> and the more I think about it, the more concerned I get.
> >> 
> >> That approach might be viable for an organization such as MISSI,
> >> where everyone presumably knows what community of interest 
> >> they fall into, but how would it apply to a public CA such as
> >> VeriSign?
> >> 
> >> Would they view all of their certificates as falling into one
> domain,
> >> including any certificates issued by subordinate CAs, as in the
> case
> >> of the old RSA Commercial hierarchy?
> >> 
> >> What about GTE CyberTrust, considering their presumed affinity
> >> with their ISP business. Would all of those certificates fall into
> >> one domain?
> >> 
> >> Now suppose I want to validate a certificate from Erols.  Do I
> decide
> >> that
> >> because Erols is in the top half of the alphabet that they probably
> 
> >> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
> 
> >> East Coast/West Coast split, like radio and TV stations use W or K
> in 
> >> their call sign?
> >> 
> >> What if Novell and Microsoft were to become CAs and issue
> certificates
> >> 
> >> to their customers directly, at least their larger accounts.  Would
> >> the relying 
> >> party have to try to divine whether a subscriber was running
> NetWare
> >> or
> >> NT in order to decide what domain they would be likely to be in?
> >> 
> >> Santosh, have I misrepresented the issue here?  Feel free to
> correct
> >> me, if so.
> >> Maybe I just don't understand.
> >> 
> >> Now, if the definition of "domain" were amended somewhat, perhaps
> some
> >> of these difficulties might go away.
> >> 
> >> In particular, it seems to me that "domain" probably ought to have
> a
> >> lot to do 
> >> with name subordination, or at least the possibility of doing name
> >> subordination, 
> >> so that it would be deterministic.  That might not solve all of the
> >> concerns that those
> >> who are inclined to vote for option 2 might have in mind, but it
> might
> >> help.
> >> 
> >> So if I am a Novell employee, and I receive an S/MIME message that
> >> contains 
> >> a certificate that begins with c=US, o=Novell, I can probably make
> an
> >> excellent 
> >> good guess of what CA to go to, assuming that Novell operates a CA
> in
> >> its 
> >> own name.  But where do I go for a certificate from Acme
> >> Manufacturing?
> >> 
> >> I don't mean to beat up on the option 1 folks exclusively -- maybe
> >> there are 
> >> some things that could be done within the options 2 that would come
> >> closer to a
> >> compromise without breaking those existing clients.  But I need to
> >> think about that
> >> some more.  maybe someone else could volunteer some suggestions.
> >> 
> >> Bob
> >> 
> >> Robert R. Jueneman
> >> Novell, Inc.
> >> 122 E. 1700 South
> >> Provo, UT 84606
> >> [email-masked]
> >> 1-801-861-7387
> >

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:50:58 -0400
Sender: [email-masked]

John:

As Dave Horvath has replied, retrieval efficiency is the same.

Option 2 also retrieves all multiple certificates and hence introduces
communication delays and unnecessary bandwidth usage.

Using option 2, if a client only retrieves crossCertificatePair
attribute only, it loses potential for efficiency.

Your last paragraph is precisely my point.  Dividing the certificates in
two buckets has potential for help and never hurts.

By the way, a class of application may choose to prefer exploring
inter-domain certificates first, if so deemed.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 8:51 AM
> To:	Santosh Chokhani
> Cc:	[email-masked]
> Subject:	RE: What the straw poll means
> 
> Santosh Chokhani <[email-masked]> writes:
> 
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> 
> The difference between the two options is primarily storage efficiency
> vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing
> only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
> 
>    whether you care more about storage efficiency in the directory
> (option
>    2 stores intra-domain certificates twice) or retrieval efficiency
> for
>    the verifier (option 1 require a verifier that wants all a target
> CA's
>    certificates to retrieve them from two places).
>    typical usage scenarios by verifiers - i.e. the percentage of
> clients
>    that are going to want to locate just inter-domain certs, compared
> to
>    clients that either don't care about the difference or are only
>    interested in intra-domain certs.  Retrieval of _just_ inter-domain
>    certs is easier under option 1, retrieval of _all_ certs is easier
> under
>    option 2, and retrieval of _just_ intra-domain certs is the same
> under
>    both options.
> 
> 
> Consider a fairly randomly structured PKI, where the verifier has a
> set of
> trusted roots loaded into it (assume they've been loaded under user
> control, with no particular order to them), and is trying to verify
> the key
> of some server that it hasn't spoken to before.  It has no idea of
> which
> "domain" the target's CA thinks it belongs to; it just wants to pull
> all
> the certs that have that CA as a subject, and see if it can construct
> a
> valid chain starting at one of its trusted roots.
> 
> Having the target CA divide its certificates between two places within
> the
> directory is no help to this verifier.  All it does it force the
> verifier
> to make two retrieval operations instead of the one that would be
> required
> by option 2.  The verifier isn't really interested in whether a
> particular
> certificate comes from another CA from the same "domain" as the
> target's CA
> - if it cares about "domains" at all, what it would be interested in
> is if
> any certs come from the same domain as the verifier (or one of its
> trusted
> roots), not the target (and of course that's verifier-specific).
> 
> For the special (and probably quite common) case where the verifier
> and
> target happen to be in the same domain, the distinction probably is
> useful.
> Option 2 supports this case just as well as does option 1, by allowing
> the
> CA to place intra-domain certs in a separate place so that clients in
> that
> domain can retrieve them first (or possibly even _instead_of_ going to
> the
> all-certs list).
> 
> John
> 

From: John Everson <[email-masked]>
Date: Thu, 3 Sep 1998 09:52:26 -0500
Subject: RE: What the straw poll means
TO: [email-masked], [email-masked]
CC: [email-masked]
Sender: [email-masked]

--openmail-part-0ef743e1-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.TXT"

Does this mean there will be a new option (3):

container/pile of intra-domain certs
container/pile of inter-domain certs
container/pile of all certs

Or do we throw everything into one container and offer a different 
mechanism for distinction?

-----Original Message-----
From: John.Wray [mailto:[email-masked]]
Sent: Thursday, September 03, 1998 7:51 AM
To: chokhani
Cc: John.Wray; ietf-pkix
Subject: RE: What the straw poll means

Santosh Chokhani <[email-masked]> writes:

>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.

The difference between the two options is primarily storage efficiency 
vs.
retrieval efficiency.  Both options divide a CAs certs into two piles.
Option 1 has pile A containing only intra-domain certs, and pile B
containing only inter-domain certs; option 2 has pile A containing only
intra-domain certs and pite B containing all certs.  Which option is
superior depends on two things:

   whether you care more about storage efficiency in the directory 
(option
   2 stores intra-domain certificates twice) or retrieval efficiency for
   the verifier (option 1 require a verifier that wants all a target 
CA's
   certificates to retrieve them from two places).
   typical usage scenarios by verifiers - i.e. the percentage of clients
   that are going to want to locate just inter-domain certs, compared to
   clients that either don't care about the difference or are only
   interested in intra-domain certs.  Retrieval of _just_ inter-domain
   certs is easier under option 1, retrieval of _all_ certs is easier 
under
   option 2, and retrieval of _just_ intra-domain certs is the same 
under
   both options.

Consider a fairly randomly structured PKI, where the verifier has a set 
of
trusted roots loaded into it (assume they've been loaded under user
control, with no particular order to them), and is trying to verify the 
key
of some server that it hasn't spoken to before.  It has no idea of which
"domain" the target's CA thinks it belongs to; it just wants to pull all
the certs that have that CA as a subject, and see if it can construct a
valid chain starting at one of its trusted roots.

Having the target CA divide its certificates between two places within 
the
directory is no help to this verifier.  All it does it force the 
verifier
to make two retrieval operations instead of the one that would be 
required
by option 2.  The verifier isn't really interested in whether a 
particular
certificate comes from another CA from the same "domain" as the 
target's CA
- if it cares about "domains" at all, what it would be interested in is 
if
any certs come from the same domain as the verifier (or one of its 
trusted
roots), not the target (and of course that's verifier-specific).

For the special (and probably quite common) case where the verifier and
target happen to be in the same domain, the distinction probably is 
useful.
Option 2 supports this case just as well as does option 1, by allowing 
the
CA to place intra-domain certs in a separate place so that clients in 
that
domain can retrieve them first (or possibly even _instead_of_ going to 
the
all-certs list).

John

--openmail-part-0ef743e1-00000001--

Date: Thu, 3 Sep 1998 11:27:34 -0500
Subject: Option 2
FROM: GIUBILEO/unix////////RFC-822/[email-masked]
TO: [email-masked]
Sender: [email-masked]

--openmail-part-0ef92b5d-00000001
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.RTF"

+++++++++++++++++++++++++++++++++++++++++++
John P. Giubileo         
Director IP Security Services
Sprint Corporate Security
Phone: 913.624.4796
[email-masked]
[PICTURE]

--openmail-part-0ef92b5d-00000001--

From: John Everson <[email-masked]>
Date: Thu, 3 Sep 1998 11:20:00 -0500
Subject: Voting Question
TO: [email-masked]
Sender: [email-masked]

--openmail-part-0ef90993-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.TXT"

Are the votes being compared against the "team member list"?

--openmail-part-0ef90993-00000001--

From: Sharon Boeyen <[email-masked]>
To: Bill Burr <[email-masked]>, "'Dave Horvath'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:38:06 +0100
Sender: [email-masked]

	I believe we already have the compromise solution on the table.
Option 1 in this straw poll is one end of the spectrum and the text
currently in the Internet Draft is the other end of the spectrum. Option
2 in this straw poll is the compromise that :

	a) provides a single place to find all certificates that a CA
has issued to other CAs and that have been issued to that CA
	b) allows the use of a locally defined 'domain' specific set of
certificates to 
	    be easily retrieved by any relying parties that happen to
understand and
	    prefer that set of certificates
	c) enables existing client systems which implement option 1 as
well as those 
	    that implement the current Internet Draft to continue
without change
	d) provides interoperability by allowing the directory entries
of CAs which use 
	    the proposal in option 1 AND entries of CAs which use the
interpretation as per the current Internet Draft text to be used by
client systems of either type

> ----------
> From: 	Dave Horvath[SMTP:[email-masked]]
> Sent: 	September 3, 1998 2:14 PM
> To: 	Bill Burr
> Cc: 	[email-masked]
> Subject: 	Re: What the straw poll means
> 
> 
> 
>     I understand the problems Bill is having with the definitions of
> roots
> and domains.  I think we are all  having those problems.  It seems
> that
> roughly half of the people I communicated with are concerned with the
> definitions and feel that population of all the cACertificates in one
> attribute may help.   I personally do not feel this helps, however we
> should
> all be interested in a compromise to keep things moving and to keep
> both
> sides happy.
> 
>     I must admit that I like the idea of being able to go to one place
> in
> the directory to find all certificates that a CA has issued (I believe
> Stefan pointed this out).  It appears that populating all CA
> certificates in
> the reverse component of the crossCertificatePair attribute solves
> this
> requirement and does not duplicate certs in a single CAs entry.  This
> gives
> clients that work in a forward direction the ability to determine all
> of the
> certificates that a CA has issued.  This type of population is clearly
> mandated by option 2 and only allowed by option 1.  Option 1 does not
> mandate it.   This type of population avoids duplication of
> certificates in
> a single CA entry (they are duplicated in subordinate, mesh, cross
> whatever), but seems to be advantageous from a clients point of view.
> 
>     Would populating the reverse component with all issued CA
> certificates
> provide a compromise that supports a single attribute to retrieve all
> certs?
> Would this help with the installed base issue?
> 
> Dave Horvath
> 
> 
> -----Original Message-----
> From: Bill Burr <[email-masked]>
> To: Dave Horvath <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> Date: Thursday, September 03, 1998 12:44 PM
> Subject: Re: What the straw poll means
> 
> 
> >But what is a root here?  Does it imply that a domain is PKI
> hierarchy?  I
> >can think of 3 plausible constructions of root, all of which I
> believe I've
> >seen used:
> >
> >(1) any CA whose key you choose to trust and therefore can start a
> >certification path, but which may not imply any other organization or
> >structure;
> >
> >(2) a CA whose key everybody in the domain (what's a domain?) trusts
> and
> >which sits on top of a hierarchical unidirectional certification tree
> (as
> >in MISSI or PEM);
> >
> >(3) a CA that exists to cross-certify with other CAs, but issues few
> or no
> >end entity certificates, and starts few or no certification paths; it
> >simply exists to connect other CAs.  Examples would be the ANX
> "supervisory
> >CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
> >Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is
> often
> >depicted at the hub of a mesh, or the top of a hierarchy, and
> operated in
> >conjunction with the overall domain policy management authority.
> >
> >
> >I suppose a "trusted root" can be either 1 or 2 above.
> >
> >But "root" to me doesn't necessarily say much about path development,
> or
> >PKI certification path structure.
> >
> >How about domain? What does it mean?  I claim that the term makes
> most
> >sense to mean a part of a PKI that operates under the direction of a
> policy
> >management entity. Which wouldn't necessarily mean that domain
> boundaries
> >coincide with distinctions that are meaningful for certification path
> >building.
> >
> >Option 1 is probably useful if you think that a domain is  everything
> >subordinate to the same root CA, where a root is any CA that somebody
> uses
> >to start a trust path.  So in a cross-certified mesh PKI, every CA is
> a
> >domain onto itself, and all CA certificates wind up only, I think, in
> the
> >crossCertificatePair attribute.  But in a hierarchical PKI most
> >certificates wind up in the cACertificate Attribute.
> >
> >I have the feeling that Bob is right at least for option 1, unless we
> know
> >what a domain is we hardly know what we are getting.  With option 2,
> I
> >suppose we are guaranteed that all certificates wind up in
> >crossCertificatePair, whatever domain means.
> >
> >At 11:14 AM 9/3/98 -0400, you wrote:
> >>Bob,
> >>
> >>    I feel that the definition of domain is a local policy and that
> CAs
> >>should be free to define it as they wish.   Clients  that
> search/read CAs
> >>entries and obtain the values from both the cACertificate and
> >>crossCertificatePair attributes can explore the values in the
> cACertficate
> >>attribute first.  If a path to the trusted root is found, processing
> stops.
> >>If not, they can explore the crossCertificatePair attribute.  Using
> this
> >>algorithm CAs can define their domain and post each of their CA
> certificates
> >>to one attribute or the other.  The only adverse affect will be
> efficiency
> >>in path development  on the client side if the CA does not carefully
> select
> >>intra or inter domain.  WIth option 1, the certificates are not
> duplicated.
> >>With option 2, they are.
> >>
> >>But if we have an installed base that only looks in the
> crossCertificatePair
> >>attribute, then we have a problem.  In that case option 2 will help
> at the
> >>expense of duplicating the data.   I suggest we avoid duplication if
> >>possible, but we certainly must evaluate the installed base.
> >>
> >>Dave Horvath
> >>
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: Bob Jueneman <[email-masked]>
> >>To: [email-masked] <[email-masked]>; [email-masked]
> >><[email-masked]>
> >>Date: Wednesday, September 02, 1998 10:21 PM
> >>Subject: RE: What the straw poll means
> >>
> >>
> >>>Santosh doesn't seem to have answered the questions I've raised
> >>>regarding the definition of the domain, but he seems to believe
> that
> >>>option 2 doesn't solve that problem either.
> >>>
> >>>If so, I am increasingly beginning to lean towards "NONE OF THE
> >>>ABOVE".
> >>>
> >>>Rebuttal, Sharon/Carlisle?
> >>>
> >>>Bob
> >>>
> >>>>Yes Bob.  I hate to say this, but you have misinterpreted.
> >>>>
> >>>>The basic difference between the two approaches is the under
> option 1
> >>>>you store a certificate only one time under a CA's entry.  Which
> >>>>certifying CA is in its domain is upto a subject CA to decide.
> >>>>
> >>>>In all honesty, I do not see a benefit to option 2 except for the
> >>>>argument that some installed base already does it this way.
> >>>>
> >>>>Option 1 achieves everything option 2 and with efficiency.
> >>>>
> >>>>I do not understand how option 2 solves your problems either.  We
> need
> >>>>to have a discussion on computational complexity of path
> development to
> >>>>allay your concerns.
> >>>>
> >>>>The way I look at the difference between the two options is that
> if
> >>>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1
> in one
> >>>>bucket and n2 in another.  Option 2 says put n in one bucket and
> n1 in
> >>>>another.  When you retrieve the two buckets (which you must for
> path
> >>>>development efficiency), option 2 gives you n+n1 certificates and
> option
> >>>>1 gives you exactly all n.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Bob Jueneman [SMTP:[email-masked]]
> >>>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>>> To: [email-masked]
> >>>>> Cc: [email-masked]
> >>>>> Subject: What the straw poll means
> >>>>>
> >>>>> This is almost as exciting as watching a horse race!
> >>>>>
> >>>>> But what are we to make of the situation if the vote is as
> >>>>> close as it appears to be at present -- does that truly indicate
> >>>>> a "rough consensus"?
> >>>>>
> >>>>> As of earlier this morning, Chromatix was ahead, with
> >>>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> >>>>> cast; and MISSI some others are clustered around third place.
> >>>>>
> >>>>> So far, with the exception of a split between MISSI and NIST
> >>>>> as two US Government factions, the voting seems to be
> >>>>> strictly by company.
> >>>>>
> >>>>> Now, the polite fiction within the IETF is that memberships are
> by
> >>>>> individual, and that there are no "votes" per se, and certainly
> not
> >>>>> on a company by company basis. That's the fiction, at least..
> >>>>> Whether this convention shall long endure now that the IETF has
> >>>>> apparently lost some or all of its government funding and has
> >>>>> to become more self-sufficient will be interesting to see.
> >>>>>
> >>>>> But unless one side or the other starts to make some significant
> >>>>> in-roads by the dint of more persuasive technical argument, then
> I
> >>>>> think
> >>>>> it's effectively a draw, and we may be counting companies and
> their
> >>>>> installed base at least as much, and perhaps more, than
> >>>>> balancing the technical alternatives.
> >>>>>
> >>>>> Now, if we are truly at a technical impasse and the vote has to
> be
> >>>>> binary, i.e., only one way or the other, then maybe counting
> installed
> >>>>> clients and minimizing the pain is really the way to go, but
> frankly
> >>>>> that approach makes me uncomfortable.  I want both
> interoperability
> >>>>> AND efficiency, and I would hate to see us don't want to be
> >>>>> pressured into a less than satisfactory decision, whatever that
> is,
> >>>>>  just because we are in a rush to get over the next hurdle in
> the
> >>>>> standards progression.
> >>>>>
> >>>>> I originally said that I was inclined to go with option 1,
> because
> >>>>> it at least appeared to be simpler.  However, I also said that I
> was
> >>>>> concerned about the "local" definition of a domain by a CA,
> >>>>> and the more I think about it, the more concerned I get.
> >>>>>
> >>>>> That approach might be viable for an organization such as MISSI,
> >>>>> where everyone presumably knows what community of interest
> >>>>> they fall into, but how would it apply to a public CA such as
> >>>>> VeriSign?
> >>>>>
> >>>>> Would they view all of their certificates as falling into one
> domain,
> >>>>> including any certificates issued by subordinate CAs, as in the
> case
> >>>>> of the old RSA Commercial hierarchy?
> >>>>>
> >>>>> What about GTE CyberTrust, considering their presumed affinity
> >>>>> with their ISP business. Would all of those certificates fall
> into
> >>>>> one domain?
> >>>>>
> >>>>> Now suppose I want to validate a certificate from Erols.  Do I
> decide
> >>>>> that
> >>>>> because Erols is in the top half of the alphabet that they
> probably
> >>>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do
> an
> >>>>> East Coast/West Coast split, like radio and TV stations use W or
> K in
> >>>>> their call sign?
> >>>>>
> >>>>> What if Novell and Microsoft were to become CAs and issue
> certificates
> >>>>>
> >>>>> to their customers directly, at least their larger accounts.
> Would
> >>>>> the relying
> >>>>> party have to try to divine whether a subscriber was running
> NetWare
> >>>>> or
> >>>>> NT in order to decide what domain they would be likely to be in?
> >>>>>
> >>>>> Santosh, have I misrepresented the issue here?  Feel free to
> correct
> >>>>> me, if so.
> >>>>> Maybe I just don't understand.
> >>>>>
> >>>>> Now, if the definition of "domain" were amended somewhat,
> perhaps some
> >>>>> of these difficulties might go away.
> >>>>>
> >>>>> In particular, it seems to me that "domain" probably ought to
> have a
> >>>>> lot to do
> >>>>> with name subordination, or at least the possibility of doing
> name
> >>>>> subordination,
> >>>>> so that it would be deterministic.  That might not solve all of
> the
> >>>>> concerns that those
> >>>>> who are inclined to vote for option 2 might have in mind, but it
> might
> >>>>> help.
> >>>>>
> >>>>> So if I am a Novell employee, and I receive an S/MIME message
> that
> >>>>> contains
> >>>>> a certificate that begins with c=US, o=Novell, I can probably
> make an
> >>>>> excellent
> >>>>> good guess of what CA to go to, assuming that Novell operates a
> CA in
> >>>>> its
> >>>>> own name.  But where do I go for a certificate from Acme
> >>>>> Manufacturing?
> >>>>>
> >>>>> I don't mean to beat up on the option 1 folks exclusively --
> maybe
> >>>>> there are
> >>>>> some things that could be done within the options 2 that would
> come
> >>>>> closer to a
> >>>>> compromise without breaking those existing clients.  But I need
> to
> >>>>> think about that
> >>>>> some more.  maybe someone else could volunteer some suggestions.
> >>>>>
> >>>>> Bob
> >>>>>
> >>>>> Robert R. Jueneman
> >>>>> Novell, Inc.
> >>>>> 122 E. 1700 South
> >>>>> Provo, UT 84606
> >>>>> [email-masked]
> >>>>> 1-801-861-7387
> >>>
> >>>
> >>
> >>
> >Regards,
> >
> >Bill Burr
> >
> 

From: Santosh Chokhani <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, Dave Horvath <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:41:37 -0400
Sender: [email-masked]

Bill, 

But under option 1 also all certificates are there since LAP gives you
all the attributes.

All option 1 does is reduce the communication load, processing load,
storage load and provide you a potential for efficiency.  With very,
very little software complexity, you have a potential for gaining a lot
on the computational complexity.

> -----Original Message-----
> From:	Bill Burr [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 12:48 PM
> To:	Dave Horvath
> Cc:	[email-masked]
> Subject:	Re: What the straw poll means
> 
> But what is a root here?  Does it imply that a domain is PKI
> hierarchy?  I
> can think of 3 plausible constructions of root, all of which I believe
> I've
> seen used: 
> 
> (1) any CA whose key you choose to trust and therefore can start a
> certification path, but which may not imply any other organization or
> structure;
> 
> (2) a CA whose key everybody in the domain (what's a domain?) trusts
> and
> which sits on top of a hierarchical unidirectional certification tree
> (as
> in MISSI or PEM);
> 
> (3) a CA that exists to cross-certify with other CAs, but issues few
> or no
> end entity certificates, and starts few or no certification paths; it
> simply exists to connect other CAs.  Examples would be the ANX
> "supervisory
> CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
> Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is often
> depicted at the hub of a mesh, or the top of a hierarchy, and operated
> in
> conjunction with the overall domain policy management authority.
> 
> 
> I suppose a "trusted root" can be either 1 or 2 above.
> 
> But "root" to me doesn't necessarily say much about path development,
> or
> PKI certification path structure.
> 
> How about domain? What does it mean?  I claim that the term makes most
> sense to mean a part of a PKI that operates under the direction of a
> policy
> management entity. Which wouldn't necessarily mean that domain
> boundaries
> coincide with distinctions that are meaningful for certification path
> building.
> 
> Option 1 is probably useful if you think that a domain is  everything
> subordinate to the same root CA, where a root is any CA that somebody
> uses
> to start a trust path.  So in a cross-certified mesh PKI, every CA is
> a
> domain onto itself, and all CA certificates wind up only, I think, in
> the
> crossCertificatePair attribute.  But in a hierarchical PKI most
> certificates wind up in the cACertificate Attribute.  
> 
> I have the feeling that Bob is right at least for option 1, unless we
> know
> what a domain is we hardly know what we are getting.  With option 2, I
> suppose we are guaranteed that all certificates wind up in
> crossCertificatePair, whatever domain means.  
> 
> At 11:14 AM 9/3/98 -0400, you wrote:
> >Bob,
> >
> >    I feel that the definition of domain is a local policy and that
> CAs
> >should be free to define it as they wish.   Clients  that search/read
> CAs
> >entries and obtain the values from both the cACertificate and
> >crossCertificatePair attributes can explore the values in the
> cACertficate
> >attribute first.  If a path to the trusted root is found, processing
> stops.
> >If not, they can explore the crossCertificatePair attribute.  Using
> this
> >algorithm CAs can define their domain and post each of their CA
> certificates
> >to one attribute or the other.  The only adverse affect will be
> efficiency
> >in path development  on the client side if the CA does not carefully
> select
> >intra or inter domain.  WIth option 1, the certificates are not
> duplicated.
> >With option 2, they are.
> >
> >But if we have an installed base that only looks in the
> crossCertificatePair
> >attribute, then we have a problem.  In that case option 2 will help
> at the
> >expense of duplicating the data.   I suggest we avoid duplication if
> >possible, but we certainly must evaluate the installed base.
> >
> >Dave Horvath
> >
> >
> >
> >
> >-----Original Message-----
> >From: Bob Jueneman <[email-masked]>
> >To: [email-masked] <[email-masked]>; [email-masked]
> ><[email-masked]>
> >Date: Wednesday, September 02, 1998 10:21 PM
> >Subject: RE: What the straw poll means
> >
> >
> >>Santosh doesn't seem to have answered the questions I've raised
> >>regarding the definition of the domain, but he seems to believe that
> >>option 2 doesn't solve that problem either.
> >>
> >>If so, I am increasingly beginning to lean towards "NONE OF THE
> >>ABOVE".
> >>
> >>Rebuttal, Sharon/Carlisle?
> >>
> >>Bob
> >>
> >>>Yes Bob.  I hate to say this, but you have misinterpreted.
> >>>
> >>>The basic difference between the two approaches is the under option
> 1
> >>>you store a certificate only one time under a CA's entry.  Which
> >>>certifying CA is in its domain is upto a subject CA to decide.
> >>>
> >>>In all honesty, I do not see a benefit to option 2 except for the
> >>>argument that some installed base already does it this way.
> >>>
> >>>Option 1 achieves everything option 2 and with efficiency.
> >>>
> >>>I do not understand how option 2 solves your problems either.  We
> need
> >>>to have a discussion on computational complexity of path
> development to
> >>>allay your concerns.
> >>>
> >>>The way I look at the difference between the two options is that if
> >>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> one
> >>>bucket and n2 in another.  Option 2 says put n in one bucket and n1
> in
> >>>another.  When you retrieve the two buckets (which you must for
> path
> >>>development efficiency), option 2 gives you n+n1 certificates and
> option
> >>>1 gives you exactly all n.
> >>>
> >>>> -----Original Message-----
> >>>> From: Bob Jueneman [SMTP:[email-masked]]
> >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>> To: [email-masked]
> >>>> Cc: [email-masked]
> >>>> Subject: What the straw poll means
> >>>>
> >>>> This is almost as exciting as watching a horse race!
> >>>>
> >>>> But what are we to make of the situation if the vote is as
> >>>> close as it appears to be at present -- does that truly indicate
> >>>> a "rough consensus"?
> >>>>
> >>>> As of earlier this morning, Chromatix was ahead, with
> >>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> >>>> cast; and MISSI some others are clustered around third place.
> >>>>
> >>>> So far, with the exception of a split between MISSI and NIST
> >>>> as two US Government factions, the voting seems to be
> >>>> strictly by company.
> >>>>
> >>>> Now, the polite fiction within the IETF is that memberships are
> by
> >>>> individual, and that there are no "votes" per se, and certainly
> not
> >>>> on a company by company basis. That's the fiction, at least..
> >>>> Whether this convention shall long endure now that the IETF has
> >>>> apparently lost some or all of its government funding and has
> >>>> to become more self-sufficient will be interesting to see.
> >>>>
> >>>> But unless one side or the other starts to make some significant
> >>>> in-roads by the dint of more persuasive technical argument, then
> I
> >>>> think
> >>>> it's effectively a draw, and we may be counting companies and
> their
> >>>> installed base at least as much, and perhaps more, than
> >>>> balancing the technical alternatives.
> >>>>
> >>>> Now, if we are truly at a technical impasse and the vote has to
> be
> >>>> binary, i.e., only one way or the other, then maybe counting
> installed
> >>>> clients and minimizing the pain is really the way to go, but
> frankly
> >>>> that approach makes me uncomfortable.  I want both
> interoperability
> >>>> AND efficiency, and I would hate to see us don't want to be
> >>>> pressured into a less than satisfactory decision, whatever that
> is,
> >>>>  just because we are in a rush to get over the next hurdle in the
> >>>> standards progression.
> >>>>
> >>>> I originally said that I was inclined to go with option 1,
> because
> >>>> it at least appeared to be simpler.  However, I also said that I
> was
> >>>> concerned about the "local" definition of a domain by a CA,
> >>>> and the more I think about it, the more concerned I get.
> >>>>
> >>>> That approach might be viable for an organization such as MISSI,
> >>>> where everyone presumably knows what community of interest
> >>>> they fall into, but how would it apply to a public CA such as
> >>>> VeriSign?
> >>>>
> >>>> Would they view all of their certificates as falling into one
> domain,
> >>>> including any certificates issued by subordinate CAs, as in the
> case
> >>>> of the old RSA Commercial hierarchy?
> >>>>
> >>>> What about GTE CyberTrust, considering their presumed affinity
> >>>> with their ISP business. Would all of those certificates fall
> into
> >>>> one domain?
> >>>>
> >>>> Now suppose I want to validate a certificate from Erols.  Do I
> decide
> >>>> that
> >>>> because Erols is in the top half of the alphabet that they
> probably
> >>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do
> an
> >>>> East Coast/West Coast split, like radio and TV stations use W or
> K in
> >>>> their call sign?
> >>>>
> >>>> What if Novell and Microsoft were to become CAs and issue
> certificates
> >>>>
> >>>> to their customers directly, at least their larger accounts.
> Would
> >>>> the relying
> >>>> party have to try to divine whether a subscriber was running
> NetWare
> >>>> or
> >>>> NT in order to decide what domain they would be likely to be in?
> >>>>
> >>>> Santosh, have I misrepresented the issue here?  Feel free to
> correct
> >>>> me, if so.
> >>>> Maybe I just don't understand.
> >>>>
> >>>> Now, if the definition of "domain" were amended somewhat, perhaps
> some
> >>>> of these difficulties might go away.
> >>>>
> >>>> In particular, it seems to me that "domain" probably ought to
> have a
> >>>> lot to do
> >>>> with name subordination, or at least the possibility of doing
> name
> >>>> subordination,
> >>>> so that it would be deterministic.  That might not solve all of
> the
> >>>> concerns that those
> >>>> who are inclined to vote for option 2 might have in mind, but it
> might
> >>>> help.
> >>>>
> >>>> So if I am a Novell employee, and I receive an S/MIME message
> that
> >>>> contains
> >>>> a certificate that begins with c=US, o=Novell, I can probably
> make an
> >>>> excellent
> >>>> good guess of what CA to go to, assuming that Novell operates a
> CA in
> >>>> its
> >>>> own name.  But where do I go for a certificate from Acme
> >>>> Manufacturing?
> >>>>
> >>>> I don't mean to beat up on the option 1 folks exclusively --
> maybe
> >>>> there are
> >>>> some things that could be done within the options 2 that would
> come
> >>>> closer to a
> >>>> compromise without breaking those existing clients.  But I need
> to
> >>>> think about that
> >>>> some more.  maybe someone else could volunteer some suggestions.
> >>>>
> >>>> Bob
> >>>>
> >>>> Robert R. Jueneman
> >>>> Novell, Inc.
> >>>> 122 E. 1700 South
> >>>> Provo, UT 84606
> >>>> [email-masked]
> >>>> 1-801-861-7387
> >>
> >>
> >
> >
> Regards,
> 
> Bill Burr

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Carlisle Adams <[email-masked]>, [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw poll means)
Date: Thu, 3 Sep 1998 19:28:59 -0400
Sender: [email-masked]

Actually your arguments heavily favor option 1.  You state that since
the request will retrieve all the certificates, there is no need to
retrieve n1+n2+n1 certificates when n1 will do.

So, that is the first point of efficiency.

Now, the second point of efficiency is that these certificate come as
different type (let us call them red and green) in option 1.  In option
2, these have to be separated.

The third point of efficiency is that an application can select which
type of link to pursue red or green.  At the risk of being redundant, CA
does not preordain that.  It is up to the application.  For a given
relying party, this could vary from application type to application
type.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 5:09 PM
> To:	Carlisle Adams; [email-masked]
> Subject:	Re: Let's try to understand the real issue (was... RE:
> What the straw poll means)
> 
> Call me slow, but I don't follow the argument the whole way...
> 
> | Hi all,
> | 
> | I propose that we try (once again) to understand what the real issue
> is
> | here.
> | 
> | > As somebody coming to the party late from the LDAP world, I don't
> see
> | > why
> | > the certificates need to be retrieved from two places.  An LDAP
> lookup
> | > of an
> | > object with a fairly simple filter (objectclass="*") will return
> all
> | > of the
> | > attributes associated with that object.  Therefore a single lookup
> | > will return
> | > both attributes, so I don't understand how retrieval efficiency is
> | > gained.
> | > 
> | O.K., so we see that a single LDAP lookup can retrieve all
> certificates
> | (which, after careful enumeration, was found to be "n") in either
> option
> | 1 or option 2.
> | 
> | The claimed advantage of option 1 is that this retrieval gets me
> | certificates that are sorted into "intra-domain" and "inter-domain",
> | which can help in efficient path construction.  Let's think about
> this
> | for a moment.  The CA doing this sorting is, by definition, NOT
> DIRECTLY
> | TRUSTED BY ME  (because if it was directly trusted by me, I would
> | already have a trusted copy of its public key and would not need
> | certificates in which it was the subject).  If it is not directly
> | trusted by me, then why would I necessarily trust it to do this
> sorting
> | in a way that is beneficial to my path construction needs?  How does
> it
> | know what *my* definition of "domain" is?  How does it know whether
> most
> | of my certificate validations will be "intra" its definition of
> domain
> | or "inter" its definition of domain?
> 
> I follow this portion of the argument...
> 
> | If this CA's definition of domain and my definition of domain do not
> | coincide exactly (and why should they, since in general this CA and
> I
> | have no pre-established relationship?), then this sorting performed
> by
> | the CA is not merely useless to me, it is actually an explicit
> | disadvantage (because the proponents of option 1 are recommending
> that
> | all the intra-domain certificates be examined *before* the
> inter-domain
> | certificates are examined, leading to worst-case path-construction
> times
> | for what may turn out to be a common scenario).
> 
> I don't see that falling out of the Option 1 text as I read the
> straw poll message.  If such is the case, then I would say that text
> should be present.
> 
> | Relying parties know what certificates they will be validating most
> | often, depending upon what particular activity they are engaged in
> at
> | the moment.  THAT defines the relying parties' "intra" and "inter"
> | domains.  CAs in the middle of a cert. path cannot possibly know
> this,
> | in general, so having THEM define a domain and sort certificates
> | according to that definition is really meaningless.
> 
> Agreed.
> 
> | Note that there will be special circumstances in which one
> definition of
> | domain will be understood throughout a given environment (e.g., the
> | strict hierarchy of CAs has been cited in previous posts on this
> topic).
> | In such cases there is a clear efficiency advantage to be gained in
> path
> | construction.  This is why option 2 is the perfect compromise:  for
> such
> | environments relying parties need only retrieve the n1 < n
> certificates
> | that they *know* will be useful to them.  Option 2 therefore meets
> the
> | needs of the general case as well as the special case, while
> | simultaneously guaranteeing interoperability of two installed bases
> | which would otherwise have no hope of interoperating today.
> 
> Stop. Here's where I really fall off the wagon. How does the relying
> party
> retrieve ONLY the n1 certificates that they know will be useful to
> them for
> a CA?  I can see retrieving the CA object from the directory (which
> unless
> you do something real clever will have ALL certificates independent of
> which
> option is chosen) and then doing your own sorting, but I don't see how
> CA 
> "presorting" is going to make a difference, because ALL certificates
> will
> be there.
> 
> | The price of this panacea?  A few redundant certificates in the
> | Directory.  Is it really worth sacrificing the general- (and perhaps
> | common-) case scenario, as well as interoperability, in order to
> save a
> | few certificates and satisfy a particular special-case?  I haven't
> yet
> | heard any convincing arguments...
> 
> Well, I'm not convinced of your argument here the other way (other
> than
> the interoperability consideration), but that's what e-mail is for :-)
> 
> My current reasoning is that given that a single LDAP lookup is going
> to 
> return ALL of the certificates independent of the option chosen, the
> client
> is going to have to process those certificates to build its path.
> Since
> this begins to look like a wash in terms of client complexity (yes,
> yes, this is where interoperability shows up), why not argue for
> the choice that conserves directory space?
> 
> Ryan
> 
> P.S.  I'm really beginning to like the original text, given that the
> concept of a "domain" is looking more and more useless (causing
> confusion
> and concern without appreciable positive points) in this discussion.

From: "Tuttle, Kimberly (OSSC)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2.
Date: Thu, 3 Sep 1998 16:10:29 -0700 
Sender: [email-masked]

From: "Evans,  Jim (OSSC)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 15:52:45 -0700 
Sender: [email-masked]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Evans
Frank Russell Company

Security is what YOU Practice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw poll means)
Date: Thu, 3 Sep 1998 23:05:31 +0100
Sender: [email-masked]

Hi Ryan,

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Thursday, September 03, 1998 5:09 PM
> To: 	Carlisle Adams; [email-masked]
> Subject: 	Re: Let's try to understand the real issue (was... RE:
> What the straw poll means)
> 
> Call me slow, but I don't follow the argument the whole way...
> 
> | If this CA's definition of domain and my definition of domain do not
> | coincide exactly (and why should they, since in general this CA and
> I
> | have no pre-established relationship?), then this sorting performed
> by
> | the CA is not merely useless to me, it is actually an explicit
> | disadvantage (because the proponents of option 1 are recommending
> that
> | all the intra-domain certificates be examined *before* the
> inter-domain
> | certificates are examined, leading to worst-case path-construction
> times
> | for what may turn out to be a common scenario).
> 
> I don't see that falling out of the Option 1 text as I read the
> straw poll message.  If such is the case, then I would say that text
> should be present.
> 
Dave Horvath's message to Bob Jueneman earlier today said the following:

    "I feel that the definition of domain is a local policy and that CAs
should be free to define it as they wish.   Clients  that search/read
CAs
entries and obtain the values from both the cACertificate and
crossCertificatePair attributes can explore the values in the
cACertficate
attribute first.  If a path to the trusted root is found, processing
stops.
If not, they can explore the crossCertificatePair attribute.  Using this
algorithm CAs can define their domain and post each of their CA
certificates
to one attribute or the other.  The only adverse affect will be
efficiency
in path development  on the client side if the CA does not carefully
select
intra or inter domain."

This was also mentioned at the meeting in Chicago.

> | Note that there will be special circumstances in which one
> definition of
> | domain will be understood throughout a given environment (e.g., the
> | strict hierarchy of CAs has been cited in previous posts on this
> topic).
> | In such cases there is a clear efficiency advantage to be gained in
> path
> | construction.  This is why option 2 is the perfect compromise:  for
> such
> | environments relying parties need only retrieve the n1 < n
> certificates
> | that they *know* will be useful to them.  Option 2 therefore meets
> the
> | needs of the general case as well as the special case, while
> | simultaneously guaranteeing interoperability of two installed bases
> | which would otherwise have no hope of interoperating today.
> 
> Stop. Here's where I really fall off the wagon. How does the relying
> party
> retrieve ONLY the n1 certificates that they know will be useful to
> them for
> a CA?  
> 
If the relying party knows that its definition of domain matches that of
the CA exactly, then it can simply retrieve all certificates in the
cACertificate attribute (rather than all certificates in the
crossCertificatePair attribute) in option 2.  This is n1 rather than n.

> Ryan
> 
> P.S.  I'm really beginning to like the original text, given that the
> concept of a "domain" is looking more and more useless (causing
> confusion
> and concern without appreciable positive points) in this discussion.
> 
Me too...  :-)

Carlisle.

From: "Les Mitchell" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Fri, 4 Sep 1998 08:07:40 +1000
Sender: [email-masked]

Date: Thu, 3 Sep 1998 17:09:01 -0400
From: [email-masked] (Ryan Moats)
To: Carlisle Adams <[email-masked]>, [email-masked]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Sender: [email-masked]

Call me slow, but I don't follow the argument the whole way...

| Hi all,
| 
| I propose that we try (once again) to understand what the real issue is
| here.
| 
| > As somebody coming to the party late from the LDAP world, I don't see
| > why
| > the certificates need to be retrieved from two places.  An LDAP lookup
| > of an
| > object with a fairly simple filter (objectclass="*") will return all
| > of the
| > attributes associated with that object.  Therefore a single lookup
| > will return
| > both attributes, so I don't understand how retrieval efficiency is
| > gained.
| > 
| O.K., so we see that a single LDAP lookup can retrieve all certificates
| (which, after careful enumeration, was found to be "n") in either option
| 1 or option 2.
| 
| The claimed advantage of option 1 is that this retrieval gets me
| certificates that are sorted into "intra-domain" and "inter-domain",
| which can help in efficient path construction.  Let's think about this
| for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
| TRUSTED BY ME  (because if it was directly trusted by me, I would
| already have a trusted copy of its public key and would not need
| certificates in which it was the subject).  If it is not directly
| trusted by me, then why would I necessarily trust it to do this sorting
| in a way that is beneficial to my path construction needs?  How does it
| know what *my* definition of "domain" is?  How does it know whether most
| of my certificate validations will be "intra" its definition of domain
| or "inter" its definition of domain?

I follow this portion of the argument...

| If this CA's definition of domain and my definition of domain do not
| coincide exactly (and why should they, since in general this CA and I
| have no pre-established relationship?), then this sorting performed by
| the CA is not merely useless to me, it is actually an explicit
| disadvantage (because the proponents of option 1 are recommending that
| all the intra-domain certificates be examined *before* the inter-domain
| certificates are examined, leading to worst-case path-construction times
| for what may turn out to be a common scenario).

I don't see that falling out of the Option 1 text as I read the
straw poll message.  If such is the case, then I would say that text
should be present.

| Relying parties know what certificates they will be validating most
| often, depending upon what particular activity they are engaged in at
| the moment.  THAT defines the relying parties' "intra" and "inter"
| domains.  CAs in the middle of a cert. path cannot possibly know this,
| in general, so having THEM define a domain and sort certificates
| according to that definition is really meaningless.

Agreed.

| Note that there will be special circumstances in which one definition of
| domain will be understood throughout a given environment (e.g., the
| strict hierarchy of CAs has been cited in previous posts on this topic).
| In such cases there is a clear efficiency advantage to be gained in path
| construction.  This is why option 2 is the perfect compromise:  for such
| environments relying parties need only retrieve the n1 < n certificates
| that they *know* will be useful to them.  Option 2 therefore meets the
| needs of the general case as well as the special case, while
| simultaneously guaranteeing interoperability of two installed bases
| which would otherwise have no hope of interoperating today.

Stop. Here's where I really fall off the wagon. How does the relying party
retrieve ONLY the n1 certificates that they know will be useful to them for
a CA?  I can see retrieving the CA object from the directory (which unless
you do something real clever will have ALL certificates independent of which
option is chosen) and then doing your own sorting, but I don't see how CA 
"presorting" is going to make a difference, because ALL certificates will
be there.

| The price of this panacea?  A few redundant certificates in the
| Directory.  Is it really worth sacrificing the general- (and perhaps
| common-) case scenario, as well as interoperability, in order to save a
| few certificates and satisfy a particular special-case?  I haven't yet
| heard any convincing arguments...

Well, I'm not convinced of your argument here the other way (other than
the interoperability consideration), but that's what e-mail is for :-)

My current reasoning is that given that a single LDAP lookup is going to 
return ALL of the certificates independent of the option chosen, the client
is going to have to process those certificates to build its path.  Since
this begins to look like a wash in terms of client complexity (yes,
yes, this is where interoperability shows up), why not argue for
the choice that conserves directory space?

Ryan

P.S.  I'm really beginning to like the original text, given that the
concept of a "domain" is looking more and more useless (causing confusion
and concern without appreciable positive points) in this discussion.

Date: Thu, 03 Sep 1998 17:14:02 -0400
To: [email-masked]
From: Bill Burr <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Regards,

Bill Burr

Date: Thu, 03 Sep 1998 17:02:06 -0400
From: Susan Lang <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Thu, 03 Sep 1998 16:52:36 -0400
From: David Solo <[email-masked]>
Reply-To: [email-masked]
Organization: Citicorp
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Thu, 03 Sep 1998 13:41:00 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Sender: [email-masked]

Hi Carlisle,
    Is the expectation that everybody is directly accessing their
CA's LDAP directory? I always thought that each orginazation would
actually maintain its own LDAP directory and, therefore, be able
to specify which CAs are preferred over others.

    Are we really expecting people to share their directories with
everyone in the world?

Ambarish

Carlisle Adams wrote:
> 
> Hi all,
> 
> I propose that we try (once again) to understand what the real issue is
> here.
> 
> > ----------
> > From:         Ryan Moats[SMTP:[email-masked]]
> > Sent:         Thursday, September 03, 1998 12:14 PM
> > To:   [email-masked]
> > Cc:   [email-masked]
> > Subject:      Retrieval efficiency herring? (was... RE: What the straw
> > poll means)
> >
> > As somebody coming to the party late from the LDAP world, I don't see
> > why
> > the certificates need to be retrieved from two places.  An LDAP lookup
> > of an
> > object with a fairly simple filter (objectclass="*") will return all
> > of the
> > attributes associated with that object.  Therefore a single lookup
> > will return
> > both attributes, so I don't understand how retrieval efficiency is
> > gained.
> >
> O.K., so we see that a single LDAP lookup can retrieve all certificates
> (which, after careful enumeration, was found to be "n") in either option
> 1 or option 2.
> 
> The claimed advantage of option 1 is that this retrieval gets me
> certificates that are sorted into "intra-domain" and "inter-domain",
> which can help in efficient path construction.  Let's think about this
> for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
> TRUSTED BY ME  (because if it was directly trusted by me, I would
> already have a trusted copy of its public key and would not need
> certificates in which it was the subject).  If it is not directly
> trusted by me, then why would I necessarily trust it to do this sorting
> in a way that is beneficial to my path construction needs?  How does it
> know what *my* definition of "domain" is?  How does it know whether most
> of my certificate validations will be "intra" its definition of domain
> or "inter" its definition of domain?
> 
> If this CA's definition of domain and my definition of domain do not
> coincide exactly (and why should they, since in general this CA and I
> have no pre-established relationship?), then this sorting performed by
> the CA is not merely useless to me, it is actually an explicit
> disadvantage (because the proponents of option 1 are recommending that
> all the intra-domain certificates be examined *before* the inter-domain
> certificates are examined, leading to worst-case path-construction times
> for what may turn out to be a common scenario).
> 
> Relying parties know what certificates they will be validating most
> often, depending upon what particular activity they are engaged in at
> the moment.  THAT defines the relying parties' "intra" and "inter"
> domains.  CAs in the middle of a cert. path cannot possibly know this,
> in general, so having THEM define a domain and sort certificates
> according to that definition is really meaningless.
> 
> Note that there will be special circumstances in which one definition of
> domain will be understood throughout a given environment (e.g., the
> strict hierarchy of CAs has been cited in previous posts on this topic).
> In such cases there is a clear efficiency advantage to be gained in path
> construction.  This is why option 2 is the perfect compromise:  for such
> environments relying parties need only retrieve the n1 < n certificates
> that they *know* will be useful to them.  Option 2 therefore meets the
> needs of the general case as well as the special case, while
> simultaneously guaranteeing interoperability of two installed bases
> which would otherwise have no hope of interoperating today.
> 
> The price of this panacea?  A few redundant certificates in the
> Directory.  Is it really worth sacrificing the general- (and perhaps
> common-) case scenario, as well as interoperability, in order to save a
> few certificates and satisfy a particular special-case?  I haven't yet
> heard any convincing arguments...
> 
> Carlisle.

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

Date: Thu, 03 Sep 1998 16:33:13 -0400
From: Robert Sabourin <[email-masked]>
Organization: TBS TechWatch
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: GMurphy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Option 2
Date: Thu, 3 Sep 1998 15:02:18 -0400 
Sender: [email-masked]

From: Carlisle Adams <[email-masked]>
To: [email-masked]
Subject: Let's try to understand the real issue (was... RE: What the straw poll means)
Date: Thu, 3 Sep 1998 19:25:07 +0100
Sender: [email-masked]

Hi all,

I propose that we try (once again) to understand what the real issue is
here.

> ----------
> From: 	Ryan Moats[SMTP:[email-masked]]
> Sent: 	Thursday, September 03, 1998 12:14 PM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	Retrieval efficiency herring? (was... RE: What the straw
> poll means)
> 
> As somebody coming to the party late from the LDAP world, I don't see
> why
> the certificates need to be retrieved from two places.  An LDAP lookup
> of an
> object with a fairly simple filter (objectclass="*") will return all
> of the
> attributes associated with that object.  Therefore a single lookup
> will return
> both attributes, so I don't understand how retrieval efficiency is
> gained.
> 
O.K., so we see that a single LDAP lookup can retrieve all certificates
(which, after careful enumeration, was found to be "n") in either option
1 or option 2.

The claimed advantage of option 1 is that this retrieval gets me
certificates that are sorted into "intra-domain" and "inter-domain",
which can help in efficient path construction.  Let's think about this
for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
TRUSTED BY ME  (because if it was directly trusted by me, I would
already have a trusted copy of its public key and would not need
certificates in which it was the subject).  If it is not directly
trusted by me, then why would I necessarily trust it to do this sorting
in a way that is beneficial to my path construction needs?  How does it
know what *my* definition of "domain" is?  How does it know whether most
of my certificate validations will be "intra" its definition of domain
or "inter" its definition of domain?

If this CA's definition of domain and my definition of domain do not
coincide exactly (and why should they, since in general this CA and I
have no pre-established relationship?), then this sorting performed by
the CA is not merely useless to me, it is actually an explicit
disadvantage (because the proponents of option 1 are recommending that
all the intra-domain certificates be examined *before* the inter-domain
certificates are examined, leading to worst-case path-construction times
for what may turn out to be a common scenario).

Relying parties know what certificates they will be validating most
often, depending upon what particular activity they are engaged in at
the moment.  THAT defines the relying parties' "intra" and "inter"
domains.  CAs in the middle of a cert. path cannot possibly know this,
in general, so having THEM define a domain and sort certificates
according to that definition is really meaningless.

Note that there will be special circumstances in which one definition of
domain will be understood throughout a given environment (e.g., the
strict hierarchy of CAs has been cited in previous posts on this topic).
In such cases there is a clear efficiency advantage to be gained in path
construction.  This is why option 2 is the perfect compromise:  for such
environments relying parties need only retrieve the n1 < n certificates
that they *know* will be useful to them.  Option 2 therefore meets the
needs of the general case as well as the special case, while
simultaneously guaranteeing interoperability of two installed bases
which would otherwise have no hope of interoperating today.

The price of this panacea?  A few redundant certificates in the
Directory.  Is it really worth sacrificing the general- (and perhaps
common-) case scenario, as well as interoperability, in order to save a
few certificates and satisfy a particular special-case?  I haven't yet
heard any convincing arguments...

Carlisle.

From: "Dave Horvath" <[email-masked]>
To: "Bill Burr" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 14:14:16 -0400
Sender: [email-masked]

    I understand the problems Bill is having with the definitions of roots
and domains.  I think we are all  having those problems.  It seems that
roughly half of the people I communicated with are concerned with the
definitions and feel that population of all the cACertificates in one
attribute may help.   I personally do not feel this helps, however we should
all be interested in a compromise to keep things moving and to keep both
sides happy.

    I must admit that I like the idea of being able to go to one place in
the directory to find all certificates that a CA has issued (I believe
Stefan pointed this out).  It appears that populating all CA certificates in
the reverse component of the crossCertificatePair attribute solves this
requirement and does not duplicate certs in a single CAs entry.  This gives
clients that work in a forward direction the ability to determine all of the
certificates that a CA has issued.  This type of population is clearly
mandated by option 2 and only allowed by option 1.  Option 1 does not
mandate it.   This type of population avoids duplication of certificates in
a single CA entry (they are duplicated in subordinate, mesh, cross
whatever), but seems to be advantageous from a clients point of view.

    Would populating the reverse component with all issued CA certificates
provide a compromise that supports a single attribute to retrieve all certs?
Would this help with the installed base issue?

Dave Horvath

-----Original Message-----
From: Bill Burr <[email-masked]>
To: Dave Horvath <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, September 03, 1998 12:44 PM
Subject: Re: What the straw poll means

>But what is a root here?  Does it imply that a domain is PKI hierarchy?  I
>can think of 3 plausible constructions of root, all of which I believe I've
>seen used:
>
>(1) any CA whose key you choose to trust and therefore can start a
>certification path, but which may not imply any other organization or
>structure;
>
>(2) a CA whose key everybody in the domain (what's a domain?) trusts and
>which sits on top of a hierarchical unidirectional certification tree (as
>in MISSI or PEM);
>
>(3) a CA that exists to cross-certify with other CAs, but issues few or no
>end entity certificates, and starts few or no certification paths; it
>simply exists to connect other CAs.  Examples would be the ANX "supervisory
>CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
>Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is often
>depicted at the hub of a mesh, or the top of a hierarchy, and operated in
>conjunction with the overall domain policy management authority.
>
>
>I suppose a "trusted root" can be either 1 or 2 above.
>
>But "root" to me doesn't necessarily say much about path development, or
>PKI certification path structure.
>
>How about domain? What does it mean?  I claim that the term makes most
>sense to mean a part of a PKI that operates under the direction of a policy
>management entity. Which wouldn't necessarily mean that domain boundaries
>coincide with distinctions that are meaningful for certification path
>building.
>
>Option 1 is probably useful if you think that a domain is  everything
>subordinate to the same root CA, where a root is any CA that somebody uses
>to start a trust path.  So in a cross-certified mesh PKI, every CA is a
>domain onto itself, and all CA certificates wind up only, I think, in the
>crossCertificatePair attribute.  But in a hierarchical PKI most
>certificates wind up in the cACertificate Attribute.
>
>I have the feeling that Bob is right at least for option 1, unless we know
>what a domain is we hardly know what we are getting.  With option 2, I
>suppose we are guaranteed that all certificates wind up in
>crossCertificatePair, whatever domain means.
>
>At 11:14 AM 9/3/98 -0400, you wrote:
>>Bob,
>>
>>    I feel that the definition of domain is a local policy and that CAs
>>should be free to define it as they wish.   Clients  that search/read CAs
>>entries and obtain the values from both the cACertificate and
>>crossCertificatePair attributes can explore the values in the cACertficate
>>attribute first.  If a path to the trusted root is found, processing
stops.
>>If not, they can explore the crossCertificatePair attribute.  Using this
>>algorithm CAs can define their domain and post each of their CA
certificates
>>to one attribute or the other.  The only adverse affect will be efficiency
>>in path development  on the client side if the CA does not carefully
select
>>intra or inter domain.  WIth option 1, the certificates are not
duplicated.
>>With option 2, they are.
>>
>>But if we have an installed base that only looks in the
crossCertificatePair
>>attribute, then we have a problem.  In that case option 2 will help at the
>>expense of duplicating the data.   I suggest we avoid duplication if
>>possible, but we certainly must evaluate the installed base.
>>
>>Dave Horvath
>>
>>
>>
>>
>>-----Original Message-----
>>From: Bob Jueneman <[email-masked]>
>>To: [email-masked] <[email-masked]>; [email-masked]
>><[email-masked]>
>>Date: Wednesday, September 02, 1998 10:21 PM
>>Subject: RE: What the straw poll means
>>
>>
>>>Santosh doesn't seem to have answered the questions I've raised
>>>regarding the definition of the domain, but he seems to believe that
>>>option 2 doesn't solve that problem either.
>>>
>>>If so, I am increasingly beginning to lean towards "NONE OF THE
>>>ABOVE".
>>>
>>>Rebuttal, Sharon/Carlisle?
>>>
>>>Bob
>>>
>>>>Yes Bob.  I hate to say this, but you have misinterpreted.
>>>>
>>>>The basic difference between the two approaches is the under option 1
>>>>you store a certificate only one time under a CA's entry.  Which
>>>>certifying CA is in its domain is upto a subject CA to decide.
>>>>
>>>>In all honesty, I do not see a benefit to option 2 except for the
>>>>argument that some installed base already does it this way.
>>>>
>>>>Option 1 achieves everything option 2 and with efficiency.
>>>>
>>>>I do not understand how option 2 solves your problems either.  We need
>>>>to have a discussion on computational complexity of path development to
>>>>allay your concerns.
>>>>
>>>>The way I look at the difference between the two options is that if
>>>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>>>>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>>>>another.  When you retrieve the two buckets (which you must for path
>>>>development efficiency), option 2 gives you n+n1 certificates and option
>>>>1 gives you exactly all n.
>>>>
>>>>> -----Original Message-----
>>>>> From: Bob Jueneman [SMTP:[email-masked]]
>>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>>> To: [email-masked]
>>>>> Cc: [email-masked]
>>>>> Subject: What the straw poll means
>>>>>
>>>>> This is almost as exciting as watching a horse race!
>>>>>
>>>>> But what are we to make of the situation if the vote is as
>>>>> close as it appears to be at present -- does that truly indicate
>>>>> a "rough consensus"?
>>>>>
>>>>> As of earlier this morning, Chromatix was ahead, with
>>>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
>>>>> cast; and MISSI some others are clustered around third place.
>>>>>
>>>>> So far, with the exception of a split between MISSI and NIST
>>>>> as two US Government factions, the voting seems to be
>>>>> strictly by company.
>>>>>
>>>>> Now, the polite fiction within the IETF is that memberships are by
>>>>> individual, and that there are no "votes" per se, and certainly not
>>>>> on a company by company basis. That's the fiction, at least..
>>>>> Whether this convention shall long endure now that the IETF has
>>>>> apparently lost some or all of its government funding and has
>>>>> to become more self-sufficient will be interesting to see.
>>>>>
>>>>> But unless one side or the other starts to make some significant
>>>>> in-roads by the dint of more persuasive technical argument, then I
>>>>> think
>>>>> it's effectively a draw, and we may be counting companies and their
>>>>> installed base at least as much, and perhaps more, than
>>>>> balancing the technical alternatives.
>>>>>
>>>>> Now, if we are truly at a technical impasse and the vote has to be
>>>>> binary, i.e., only one way or the other, then maybe counting installed
>>>>> clients and minimizing the pain is really the way to go, but frankly
>>>>> that approach makes me uncomfortable.  I want both interoperability
>>>>> AND efficiency, and I would hate to see us don't want to be
>>>>> pressured into a less than satisfactory decision, whatever that is,
>>>>>  just because we are in a rush to get over the next hurdle in the
>>>>> standards progression.
>>>>>
>>>>> I originally said that I was inclined to go with option 1, because
>>>>> it at least appeared to be simpler.  However, I also said that I was
>>>>> concerned about the "local" definition of a domain by a CA,
>>>>> and the more I think about it, the more concerned I get.
>>>>>
>>>>> That approach might be viable for an organization such as MISSI,
>>>>> where everyone presumably knows what community of interest
>>>>> they fall into, but how would it apply to a public CA such as
>>>>> VeriSign?
>>>>>
>>>>> Would they view all of their certificates as falling into one domain,
>>>>> including any certificates issued by subordinate CAs, as in the case
>>>>> of the old RSA Commercial hierarchy?
>>>>>
>>>>> What about GTE CyberTrust, considering their presumed affinity
>>>>> with their ISP business. Would all of those certificates fall into
>>>>> one domain?
>>>>>
>>>>> Now suppose I want to validate a certificate from Erols.  Do I decide
>>>>> that
>>>>> because Erols is in the top half of the alphabet that they probably
>>>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
>>>>> East Coast/West Coast split, like radio and TV stations use W or K in
>>>>> their call sign?
>>>>>
>>>>> What if Novell and Microsoft were to become CAs and issue certificates
>>>>>
>>>>> to their customers directly, at least their larger accounts.  Would
>>>>> the relying
>>>>> party have to try to divine whether a subscriber was running NetWare
>>>>> or
>>>>> NT in order to decide what domain they would be likely to be in?
>>>>>
>>>>> Santosh, have I misrepresented the issue here?  Feel free to correct
>>>>> me, if so.
>>>>> Maybe I just don't understand.
>>>>>
>>>>> Now, if the definition of "domain" were amended somewhat, perhaps some
>>>>> of these difficulties might go away.
>>>>>
>>>>> In particular, it seems to me that "domain" probably ought to have a
>>>>> lot to do
>>>>> with name subordination, or at least the possibility of doing name
>>>>> subordination,
>>>>> so that it would be deterministic.  That might not solve all of the
>>>>> concerns that those
>>>>> who are inclined to vote for option 2 might have in mind, but it might
>>>>> help.
>>>>>
>>>>> So if I am a Novell employee, and I receive an S/MIME message that
>>>>> contains
>>>>> a certificate that begins with c=US, o=Novell, I can probably make an
>>>>> excellent
>>>>> good guess of what CA to go to, assuming that Novell operates a CA in
>>>>> its
>>>>> own name.  But where do I go for a certificate from Acme
>>>>> Manufacturing?
>>>>>
>>>>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>>>>> there are
>>>>> some things that could be done within the options 2 that would come
>>>>> closer to a
>>>>> compromise without breaking those existing clients.  But I need to
>>>>> think about that
>>>>> some more.  maybe someone else could volunteer some suggestions.
>>>>>
>>>>> Bob
>>>>>
>>>>> Robert R. Jueneman
>>>>> Novell, Inc.
>>>>> 122 E. 1700 South
>>>>> Provo, UT 84606
>>>>> [email-masked]
>>>>> 1-801-861-7387
>>>
>>>
>>
>>
>Regards,
>
>Bill Burr
>

From: Rainer Rueppel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 19:01:41 +0100
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 18:26:10 +0100
Sender: [email-masked]

Hi Ambarish

It is the relying party, not the CA, which knows the priority for
identifying the most efficient set of certificates for path building for
a specific certificate validation. Further,  the priority for a single
relying party can change from operation to operation depending on the
particular environment in which they are operating. For that primary
reason, I don't think the CA's domain (whatever they define it to be) is
a very useful split, but rather allowing client systems to perform
flexible filtering of the contents of the directory with matching rules
that allow them to match on particular elements of the certificates is
the most generic and flexible approach. While a CA could provide some
helpful hints to relying parties (e.g. through the use of cACertificate
attribute or other attributes and prioritization tags) this can only
help a subset of relying parties who understand that CAs definition of
domain and/or prioritization criteria. Other relying parties may have
completely opposite priorities and relying parties for which the CA
hints are useless should be equally supported.   

As we migrate to LDAPv3, the extensible match capability of that
protocol, combined with the matching rules currently in X.509 (or some
evolution of them) should enable ONLY the certificates of interest to a
particular relying party and for a particular validation instance to be
retrieved. While it is true that an extensible match can be applied to
more than one attribute on a single directory protocol exchange, this
does require extra processing on the directory side, provides no
additional value,  and is obviously more work for the directory  than to
filter on a single attribute rather than always on two.

There would be nothing to prevent the use of additional attributes
(either locally defined or standardized), or some other technologies
(e.g. the use of directory contexts to flag particular values of a
single attribute) but at this point I believe those would be more
locally contained than standardized so I see them as additional helpful
hints potentially.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Ambarish Malpani[SMTP:[email-masked]]
> Sent: 	September 3, 1998 12:54 PM
> To: 	[email-masked]'
> Subject: 	Where to store CA certificates
> 
> Hi Guys,
>     Given the huge amount of passion that the topic of where one
> stores CA certificates has generated, it seems to me that path
> building is both a complicated and important thing ;-)
> 
>     If the premise above is true, wouldn't one want to prioritize
> path building more precisely than just lumping CA certs into
> one of two categories (intra-domain/inter-domain)?
> 
>     Would it make sense to have another attribute attached to
> CA certificates - something like a "priority" field, with say
> an integer value, where, during path building you first try to
> build paths with the CA cert with the highest priority?
> 
>     Or is this a BAD idea, because it doesn't work with any of
> the current implementations?
> 
> Comments? Sharon, Santosh?
> 
> 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
> 

Date: Thu, 03 Sep 1998 09:54:19 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: "[email-masked]'" <[email-masked]>
Subject: Where to store CA certificates
Sender: [email-masked]

Hi Guys,
    Given the huge amount of passion that the topic of where one
stores CA certificates has generated, it seems to me that path
building is both a complicated and important thing ;-)

    If the premise above is true, wouldn't one want to prioritize
path building more precisely than just lumping CA certs into
one of two categories (intra-domain/inter-domain)?

    Would it make sense to have another attribute attached to
CA certificates - something like a "priority" field, with say
an integer value, where, during path building you first try to
build paths with the CA cert with the highest priority?

    Or is this a BAD idea, because it doesn't work with any of
the current implementations?

Comments? Sharon, Santosh?

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

Date: Thu, 03 Sep 1998 11:14:45 -0600
From: "Russel F. Weiser" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------4DB9C958A073A47F89771625
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm a new to the PKIX in general and am more familiar with  LDAP v3 then the
CA
environment. I did understand the orignal draft and would have voted for
it.  That is if  I would have been able to attend the wg meeting, but alas;
I was in the LDAPEXT wg instead.
I have voted for option 1, because it sounds like it minimizes storage as
well as providing
consistent knowledge of what goes in which attribute without duplicating
storage.

Now I would like to know the reason the orignal text was voted down since I
couldn't be there.

I  know Bob keeps bringing up the DOMAIN issue and I do think that this is
an issue since no one has of yet given it a definition. .

Sharon Boeyen wrote:

> The "two buckets" is exactly what I was trying to avoid in the earlier
> debate on this topic, however I believe that the single bucket option
> was rejected in the Chicago meeting. The single bucket option is the
> text which is currently in the Internet Draft. With that text, all self
> signed (or self issued certificates) were to be placed in the
> cACertificate attribute and all certificates issued by one CA to a
> different CA were put in the crossCertificatePair attribute. Depending
> on the particular path development algorithm being used by a relying
> party, directory search tools, especially when we evolve to LDAPv3 could
> be used to filter the content of the forward and or reverse elements of
> that SINGLE attribute and provide the relying party with the set of
> certificates of interest to that particular relying party.
>
> I still believe that this is the best solution because the relying party
> systems are the ones that know which certs are of interest to them, not
> the CA that happened to issue the certs, especially in the post PEM
> world where any CA could legitimately have certs issued for it by
> several CAs.
>
> My strong support for Option 2 in the straw poll is because the above
> was rejected by the meeting and I see Option 2 as a workable compromise
> ONLY because there is a complete set of certs in a single attribute and
> relying parties can do what is of interest to them without knowing the
> definition of domain which each individual CA happens to use. For self
> contained environments wanting to make use of a CA or set of CAs certs
> issued within some locally defined domain, this is still possible.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies
>
> mailto:[email-masked]  Tel: (613) 247-3181
> http://www.entrust.com            Fax: (613) 247-3690
>
>
> > ----------
> > From:         Santosh Chokhani[SMTP:[email-masked]]
> > Sent:         September 2, 1998 8:48 PM
> > To:   'Bob Jueneman'; [email-masked]
> > Cc:   Santosh Chokhani
> > Subject:      RE: What the straw poll means
> >
> > Yes Bob.  I hate to say this, but you have misinterpreted.
> >
> > The basic difference between the two approaches is the under option 1
> > you store a certificate only one time under a CA's entry.  Which
> > certifying CA is in its domain is upto a subject CA to decide.
> >
> > In all honesty, I do not see a benefit to option 2 except for the
> > argument that some installed base already does it this way.
> >
> > Option 1 achieves everything option 2 and with efficiency.
> >
> > I do not understand how option 2 solves your problems either.  We need
> > to have a discussion on computational complexity of path development
> > to
> > allay your concerns.
> >
> > The way I look at the difference between the two options is that if
> > n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> > one
> > bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
> > another.  When you retrieve the two buckets (which you must for path
> > development efficiency), option 2 gives you n+n1 certificates and
> > option
> > 1 gives you exactly all n.
> >
> > > -----Original Message-----
> > > From:       Bob Jueneman [SMTP:[email-masked]]
> > > Sent:       Wednesday, September 02, 1998 8:33 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject:    What the straw poll means
> > >
> > > This is almost as exciting as watching a horse race!
> > >
> > > But what are we to make of the situation if the vote is as
> > > close as it appears to be at present -- does that truly indicate
> > > a "rough consensus"?
> > >
> > > As of earlier this morning, Chromatix was ahead, with
> > > 8 votes cast; Entrust was tied with Microsoft with 4 votes
> > > cast; and MISSI some others are clustered around third place.
> > >
> > > So far, with the exception of a split between MISSI and NIST
> > > as two US Government factions, the voting seems to be
> > > strictly by company.
> > >
> > > Now, the polite fiction within the IETF is that memberships are by
> > > individual, and that there are no "votes" per se, and certainly not
> > > on a company by company basis. That's the fiction, at least..
> > > Whether this convention shall long endure now that the IETF has
> > > apparently lost some or all of its government funding and has
> > > to become more self-sufficient will be interesting to see.
> > >
> > > But unless one side or the other starts to make some significant
> > > in-roads by the dint of more persuasive technical argument, then I
> > > think
> > > it's effectively a draw, and we may be counting companies and their
> > > installed base at least as much, and perhaps more, than
> > > balancing the technical alternatives.
> > >
> > > Now, if we are truly at a technical impasse and the vote has to be
> > > binary, i.e., only one way or the other, then maybe counting
> > installed
> > > clients and minimizing the pain is really the way to go, but frankly
> >
> > > that approach makes me uncomfortable.  I want both interoperability
> > > AND efficiency, and I would hate to see us don't want to be
> > > pressured into a less than satisfactory decision, whatever that is,
> > >  just because we are in a rush to get over the next hurdle in the
> > > standards progression.
> > >
> > > I originally said that I was inclined to go with option 1, because
> > > it at least appeared to be simpler.  However, I also said that I was
> >
> > > concerned about the "local" definition of a domain by a CA,
> > > and the more I think about it, the more concerned I get.
> > >
> > > That approach might be viable for an organization such as MISSI,
> > > where everyone presumably knows what community of interest
> > > they fall into, but how would it apply to a public CA such as
> > > VeriSign?
> > >
> > > Would they view all of their certificates as falling into one
> > domain,
> > > including any certificates issued by subordinate CAs, as in the case
> > > of the old RSA Commercial hierarchy?
> > >
> > > What about GTE CyberTrust, considering their presumed affinity
> > > with their ISP business. Would all of those certificates fall into
> > > one domain?
> > >
> > > Now suppose I want to validate a certificate from Erols.  Do I
> > decide
> > > that
> > > because Erols is in the top half of the alphabet that they probably
> > > use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
> > > East Coast/West Coast split, like radio and TV stations use W or K
> > in
> > > their call sign?
> > >
> > > What if Novell and Microsoft were to become CAs and issue
> > certificates
> > >
> > > to their customers directly, at least their larger accounts.  Would
> > > the relying
> > > party have to try to divine whether a subscriber was running NetWare
> > > or
> > > NT in order to decide what domain they would be likely to be in?
> > >
> > > Santosh, have I misrepresented the issue here?  Feel free to correct
> > > me, if so.
> > > Maybe I just don't understand.
> > >
> > > Now, if the definition of "domain" were amended somewhat, perhaps
> > some
> > > of these difficulties might go away.
> > >
> > > In particular, it seems to me that "domain" probably ought to have a
> > > lot to do
> > > with name subordination, or at least the possibility of doing name
> > > subordination,
> > > so that it would be deterministic.  That might not solve all of the
> > > concerns that those
> > > who are inclined to vote for option 2 might have in mind, but it
> > might
> > > help.
> > >
> > > So if I am a Novell employee, and I receive an S/MIME message that
> > > contains
> > > a certificate that begins with c=US, o=Novell, I can probably make
> > an
> > > excellent
> > > good guess of what CA to go to, assuming that Novell operates a CA
> > in
> > > its
> > > own name.  But where do I go for a certificate from Acme
> > > Manufacturing?
> > >
> > > I don't mean to beat up on the option 1 folks exclusively -- maybe
> > > there are
> > > some things that could be done within the options 2 that would come
> > > closer to a
> > > compromise without breaking those existing clients.  But I need to
> > > think about that
> > > some more.  maybe someone else could volunteer some suggestions.
> > >
> > > Bob
> > >
> > > Robert R. Jueneman
> > > Novell, Inc.
> > > 122 E. 1700 South
> > > Provo, UT 84606
> > > [email-masked]
> > > 1-801-861-7387
> >

--------------4DB9C958A073A47F89771625
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Russel Weiser
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Russel Weiser
n:              Weiser;Russel
org:            DST
email;internet: [email-masked]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------4DB9C958A073A47F89771625--

Date: Thu, 03 Sep 1998 12:47:53 -0400
To: "Dave Horvath" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject: Re: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

But what is a root here?  Does it imply that a domain is PKI hierarchy?  I
can think of 3 plausible constructions of root, all of which I believe I've
seen used: 

(1) any CA whose key you choose to trust and therefore can start a
certification path, but which may not imply any other organization or
structure;

(2) a CA whose key everybody in the domain (what's a domain?) trusts and
which sits on top of a hierarchical unidirectional certification tree (as
in MISSI or PEM);

(3) a CA that exists to cross-certify with other CAs, but issues few or no
end entity certificates, and starts few or no certification paths; it
simply exists to connect other CAs.  Examples would be the ANX "supervisory
CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is often
depicted at the hub of a mesh, or the top of a hierarchy, and operated in
conjunction with the overall domain policy management authority.

I suppose a "trusted root" can be either 1 or 2 above.

But "root" to me doesn't necessarily say much about path development, or
PKI certification path structure.

How about domain? What does it mean?  I claim that the term makes most
sense to mean a part of a PKI that operates under the direction of a policy
management entity. Which wouldn't necessarily mean that domain boundaries
coincide with distinctions that are meaningful for certification path
building.

Option 1 is probably useful if you think that a domain is  everything
subordinate to the same root CA, where a root is any CA that somebody uses
to start a trust path.  So in a cross-certified mesh PKI, every CA is a
domain onto itself, and all CA certificates wind up only, I think, in the
crossCertificatePair attribute.  But in a hierarchical PKI most
certificates wind up in the cACertificate Attribute.  

I have the feeling that Bob is right at least for option 1, unless we know
what a domain is we hardly know what we are getting.  With option 2, I
suppose we are guaranteed that all certificates wind up in
crossCertificatePair, whatever domain means.  

At 11:14 AM 9/3/98 -0400, you wrote:
>Bob,
>
>    I feel that the definition of domain is a local policy and that CAs
>should be free to define it as they wish.   Clients  that search/read CAs
>entries and obtain the values from both the cACertificate and
>crossCertificatePair attributes can explore the values in the cACertficate
>attribute first.  If a path to the trusted root is found, processing stops.
>If not, they can explore the crossCertificatePair attribute.  Using this
>algorithm CAs can define their domain and post each of their CA certificates
>to one attribute or the other.  The only adverse affect will be efficiency
>in path development  on the client side if the CA does not carefully select
>intra or inter domain.  WIth option 1, the certificates are not duplicated.
>With option 2, they are.
>
>But if we have an installed base that only looks in the crossCertificatePair
>attribute, then we have a problem.  In that case option 2 will help at the
>expense of duplicating the data.   I suggest we avoid duplication if
>possible, but we certainly must evaluate the installed base.
>
>Dave Horvath
>
>
>
>
>-----Original Message-----
>From: Bob Jueneman <[email-masked]>
>To: [email-masked] <[email-masked]>; [email-masked]
><[email-masked]>
>Date: Wednesday, September 02, 1998 10:21 PM
>Subject: RE: What the straw poll means
>
>
>>Santosh doesn't seem to have answered the questions I've raised
>>regarding the definition of the domain, but he seems to believe that
>>option 2 doesn't solve that problem either.
>>
>>If so, I am increasingly beginning to lean towards "NONE OF THE
>>ABOVE".
>>
>>Rebuttal, Sharon/Carlisle?
>>
>>Bob
>>
>>>Yes Bob.  I hate to say this, but you have misinterpreted.
>>>
>>>The basic difference between the two approaches is the under option 1
>>>you store a certificate only one time under a CA's entry.  Which
>>>certifying CA is in its domain is upto a subject CA to decide.
>>>
>>>In all honesty, I do not see a benefit to option 2 except for the
>>>argument that some installed base already does it this way.
>>>
>>>Option 1 achieves everything option 2 and with efficiency.
>>>
>>>I do not understand how option 2 solves your problems either.  We need
>>>to have a discussion on computational complexity of path development to
>>>allay your concerns.
>>>
>>>The way I look at the difference between the two options is that if
>>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>>>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>>>another.  When you retrieve the two buckets (which you must for path
>>>development efficiency), option 2 gives you n+n1 certificates and option
>>>1 gives you exactly all n.
>>>
>>>> -----Original Message-----
>>>> From: Bob Jueneman [SMTP:[email-masked]]
>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>> To: [email-masked]
>>>> Cc: [email-masked]
>>>> Subject: What the straw poll means
>>>>
>>>> This is almost as exciting as watching a horse race!
>>>>
>>>> But what are we to make of the situation if the vote is as
>>>> close as it appears to be at present -- does that truly indicate
>>>> a "rough consensus"?
>>>>
>>>> As of earlier this morning, Chromatix was ahead, with
>>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
>>>> cast; and MISSI some others are clustered around third place.
>>>>
>>>> So far, with the exception of a split between MISSI and NIST
>>>> as two US Government factions, the voting seems to be
>>>> strictly by company.
>>>>
>>>> Now, the polite fiction within the IETF is that memberships are by
>>>> individual, and that there are no "votes" per se, and certainly not
>>>> on a company by company basis. That's the fiction, at least..
>>>> Whether this convention shall long endure now that the IETF has
>>>> apparently lost some or all of its government funding and has
>>>> to become more self-sufficient will be interesting to see.
>>>>
>>>> But unless one side or the other starts to make some significant
>>>> in-roads by the dint of more persuasive technical argument, then I
>>>> think
>>>> it's effectively a draw, and we may be counting companies and their
>>>> installed base at least as much, and perhaps more, than
>>>> balancing the technical alternatives.
>>>>
>>>> Now, if we are truly at a technical impasse and the vote has to be
>>>> binary, i.e., only one way or the other, then maybe counting installed
>>>> clients and minimizing the pain is really the way to go, but frankly
>>>> that approach makes me uncomfortable.  I want both interoperability
>>>> AND efficiency, and I would hate to see us don't want to be
>>>> pressured into a less than satisfactory decision, whatever that is,
>>>>  just because we are in a rush to get over the next hurdle in the
>>>> standards progression.
>>>>
>>>> I originally said that I was inclined to go with option 1, because
>>>> it at least appeared to be simpler.  However, I also said that I was
>>>> concerned about the "local" definition of a domain by a CA,
>>>> and the more I think about it, the more concerned I get.
>>>>
>>>> That approach might be viable for an organization such as MISSI,
>>>> where everyone presumably knows what community of interest
>>>> they fall into, but how would it apply to a public CA such as
>>>> VeriSign?
>>>>
>>>> Would they view all of their certificates as falling into one domain,
>>>> including any certificates issued by subordinate CAs, as in the case
>>>> of the old RSA Commercial hierarchy?
>>>>
>>>> What about GTE CyberTrust, considering their presumed affinity
>>>> with their ISP business. Would all of those certificates fall into
>>>> one domain?
>>>>
>>>> Now suppose I want to validate a certificate from Erols.  Do I decide
>>>> that
>>>> because Erols is in the top half of the alphabet that they probably
>>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
>>>> East Coast/West Coast split, like radio and TV stations use W or K in
>>>> their call sign?
>>>>
>>>> What if Novell and Microsoft were to become CAs and issue certificates
>>>>
>>>> to their customers directly, at least their larger accounts.  Would
>>>> the relying
>>>> party have to try to divine whether a subscriber was running NetWare
>>>> or
>>>> NT in order to decide what domain they would be likely to be in?
>>>>
>>>> Santosh, have I misrepresented the issue here?  Feel free to correct
>>>> me, if so.
>>>> Maybe I just don't understand.
>>>>
>>>> Now, if the definition of "domain" were amended somewhat, perhaps some
>>>> of these difficulties might go away.
>>>>
>>>> In particular, it seems to me that "domain" probably ought to have a
>>>> lot to do
>>>> with name subordination, or at least the possibility of doing name
>>>> subordination,
>>>> so that it would be deterministic.  That might not solve all of the
>>>> concerns that those
>>>> who are inclined to vote for option 2 might have in mind, but it might
>>>> help.
>>>>
>>>> So if I am a Novell employee, and I receive an S/MIME message that
>>>> contains
>>>> a certificate that begins with c=US, o=Novell, I can probably make an
>>>> excellent
>>>> good guess of what CA to go to, assuming that Novell operates a CA in
>>>> its
>>>> own name.  But where do I go for a certificate from Acme
>>>> Manufacturing?
>>>>
>>>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>>>> there are
>>>> some things that could be done within the options 2 that would come
>>>> closer to a
>>>> compromise without breaking those existing clients.  But I need to
>>>> think about that
>>>> some more.  maybe someone else could volunteer some suggestions.
>>>>
>>>> Bob
>>>>
>>>> Robert R. Jueneman
>>>> Novell, Inc.
>>>> 122 E. 1700 South
>>>> Provo, UT 84606
>>>> [email-masked]
>>>> 1-801-861-7387
>>
>>
>
>
Regards,

Bill Burr

Date: Thu, 03 Sep 1998 10:41:47 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

Bill,

I was only gently tweaking the USG -- anyone who has ever 
dealt with NIST, NSA, or the FBI on issues like export controls 
knows that each agency has its one separate agenda and priorities.
I for one would hate to have to be the President or Vice President 
who has to knock heads and try to get the Administration to speak with 
one voice.

But your comments on the pioneers are very apropos. 

As a major player in the directory space, Novell certainly has an interest 
in this area. We would hate to see a solution adopted that unnecessarily 
wastes directory space. On the other hand, memory is getting cheaper 
and cheaper, but Internet congestion is getting worse, and it isn't clear 
that caching or other approaches would be likely to apply here. so I'm 
not sure that I completely buy Tim's argument that interoperability is 
more important than efficiency.

To further complicate the problem, Novell has a relationship with Entrust,
and we certainly have no desire to see their interests harmed. But likewise,
we consider the US Government a very important customer, and we would 
hate to see a solution adopted that would fly in the face of MISSI's and 
DMS's needs. 

Knowing both Sharon and Santosh reasonably well, I can certainly say that
they are both bright, and have an excellent understanding of the technology. 
The fact that they and others come out on opposite sides of the issue 
probably means that their views of the underlying problem space and 
their priorities, are probably different, rather than being due to some flaw 
in their logic.

If all else fails and we have to make a choice, I also would favor not shafting
the early developer who has helped the market grow.  The trouble is,
I'm not exactly sure whose ox would be gored, and how much effort it
would take to fix it.  Entrust obviously has an investment in their current 
client, but what the cost of changing it would be I don't know. Likewise,
I'm not sure who many other players in this space have already developed
clients that might also be impacted.

What is pretty obvious by now is that there isn't a clear consensus, at least 
not yet, and that cogent arguments can be made on both sides depending
on what your assumptions are regarding the behavior of the clients, which
may require a crystal ball.

So maybe we should go back to the drawing board and see if we have 
exhausted all of the possible alternatives.

For example, Sharon mentioned that she thought that the "single bucket" 
approach was ruled out in Chicago. I wasn't there and so I don't know 
the pros and cons, but it would seem that reexamining that possibility 
might be worthwhile. At least on the surface it seems to solve both problems.

Others have commented that with appropriate LDAP filters it is possible to 
retrieve certificates from both piles simultaneously.  Maybe there is a pony 
in there somewhere that could be explored more fully, especially for those 
of us who are not LDAP gurus.

I WANT my cake and eat it, too!

Bob

From: WHenry <[email-masked]>
To: [email-masked]
Subject: For Option #2
Date: Thu, 3 Sep 1998 12:42:32 -0400 
Sender: [email-masked]

From: "Boby Joseph" <[email-masked]>
To: [email-masked]
Date: Thu, 3 Sep 1998 11:36:24 -0500
Subject: For option 1
Sender: [email-masked]

Date: Thu, 3 Sep 1998 12:32:04 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

Folks,

A straw poll is not a vote, since we don't vote in the IETF or in WGs.  The
WG chair(s) retain discretion to interpret the outcome of s straw poll,
e.g., to discount any apparent ballot box stuffing by a given organization.
I asked Sharon to extend the polling period because this is clearly a
contentious issue and because we usually allow about a week for such
activities, although we have gone through shorter polling intervals on
occasion.

have a nice Labor Day weekend,

Steve

From: "Ryan Moats" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Retrieval efficiency herring? (was... RE: What the straw poll means)
Date: Thu, 3 Sep 1998 11:14:31 -0500
Importance: Normal
Sender: [email-masked]

[email-masked] writes:

> Santosh Chokhani <[email-masked]> writes:
>
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
>
> The difference between the two options is primarily storage efficiency vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
>
>    whether you care more about storage efficiency in the directory (option
>    2 stores intra-domain certificates twice) or retrieval efficiency for
>    the verifier (option 1 require a verifier that wants all a target CA's
>    certificates to retrieve them from two places).

As somebody coming to the party late from the LDAP world, I don't see why
the certificates need to be retrieved from two places.  An LDAP lookup of an
object with a fairly simple filter (objectclass="*") will return all of the
attributes associated with that object.  Therefore a single lookup will
return
both attributes, so I don't understand how retrieval efficiency is gained.

Ryan Moats

From: [email-masked]
To: [email-masked]
Date: Thu, 3 Sep 1998 11:53:53 -0400
Subject: For Option 2
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [email-masked]
Precedence: bulk

From: "Dave Horvath" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 11:14:45 -0400
Sender: [email-masked]

Bob,

    I feel that the definition of domain is a local policy and that CAs
should be free to define it as they wish.   Clients  that search/read CAs
entries and obtain the values from both the cACertificate and
crossCertificatePair attributes can explore the values in the cACertficate
attribute first.  If a path to the trusted root is found, processing stops.
If not, they can explore the crossCertificatePair attribute.  Using this
algorithm CAs can define their domain and post each of their CA certificates
to one attribute or the other.  The only adverse affect will be efficiency
in path development  on the client side if the CA does not carefully select
intra or inter domain.  WIth option 1, the certificates are not duplicated.
With option 2, they are.

But if we have an installed base that only looks in the crossCertificatePair
attribute, then we have a problem.  In that case option 2 will help at the
expense of duplicating the data.   I suggest we avoid duplication if
possible, but we certainly must evaluate the installed base.

Dave Horvath

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, September 02, 1998 10:21 PM
Subject: RE: What the straw poll means

>Santosh doesn't seem to have answered the questions I've raised
>regarding the definition of the domain, but he seems to believe that
>option 2 doesn't solve that problem either.
>
>If so, I am increasingly beginning to lean towards "NONE OF THE
>ABOVE".
>
>Rebuttal, Sharon/Carlisle?
>
>Bob
>
>>Yes Bob.  I hate to say this, but you have misinterpreted.
>>
>>The basic difference between the two approaches is the under option 1
>>you store a certificate only one time under a CA's entry.  Which
>>certifying CA is in its domain is upto a subject CA to decide.
>>
>>In all honesty, I do not see a benefit to option 2 except for the
>>argument that some installed base already does it this way.
>>
>>Option 1 achieves everything option 2 and with efficiency.
>>
>>I do not understand how option 2 solves your problems either.  We need
>>to have a discussion on computational complexity of path development to
>>allay your concerns.
>>
>>The way I look at the difference between the two options is that if
>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>>another.  When you retrieve the two buckets (which you must for path
>>development efficiency), option 2 gives you n+n1 certificates and option
>>1 gives you exactly all n.
>>
>>> -----Original Message-----
>>> From: Bob Jueneman [SMTP:[email-masked]]
>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: What the straw poll means
>>>
>>> This is almost as exciting as watching a horse race!
>>>
>>> But what are we to make of the situation if the vote is as
>>> close as it appears to be at present -- does that truly indicate
>>> a "rough consensus"?
>>>
>>> As of earlier this morning, Chromatix was ahead, with
>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
>>> cast; and MISSI some others are clustered around third place.
>>>
>>> So far, with the exception of a split between MISSI and NIST
>>> as two US Government factions, the voting seems to be
>>> strictly by company.
>>>
>>> Now, the polite fiction within the IETF is that memberships are by
>>> individual, and that there are no "votes" per se, and certainly not
>>> on a company by company basis. That's the fiction, at least..
>>> Whether this convention shall long endure now that the IETF has
>>> apparently lost some or all of its government funding and has
>>> to become more self-sufficient will be interesting to see.
>>>
>>> But unless one side or the other starts to make some significant
>>> in-roads by the dint of more persuasive technical argument, then I
>>> think
>>> it's effectively a draw, and we may be counting companies and their
>>> installed base at least as much, and perhaps more, than
>>> balancing the technical alternatives.
>>>
>>> Now, if we are truly at a technical impasse and the vote has to be
>>> binary, i.e., only one way or the other, then maybe counting installed
>>> clients and minimizing the pain is really the way to go, but frankly
>>> that approach makes me uncomfortable.  I want both interoperability
>>> AND efficiency, and I would hate to see us don't want to be
>>> pressured into a less than satisfactory decision, whatever that is,
>>>  just because we are in a rush to get over the next hurdle in the
>>> standards progression.
>>>
>>> I originally said that I was inclined to go with option 1, because
>>> it at least appeared to be simpler.  However, I also said that I was
>>> concerned about the "local" definition of a domain by a CA,
>>> and the more I think about it, the more concerned I get.
>>>
>>> That approach might be viable for an organization such as MISSI,
>>> where everyone presumably knows what community of interest
>>> they fall into, but how would it apply to a public CA such as
>>> VeriSign?
>>>
>>> Would they view all of their certificates as falling into one domain,
>>> including any certificates issued by subordinate CAs, as in the case
>>> of the old RSA Commercial hierarchy?
>>>
>>> What about GTE CyberTrust, considering their presumed affinity
>>> with their ISP business. Would all of those certificates fall into
>>> one domain?
>>>
>>> Now suppose I want to validate a certificate from Erols.  Do I decide
>>> that
>>> because Erols is in the top half of the alphabet that they probably
>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
>>> East Coast/West Coast split, like radio and TV stations use W or K in
>>> their call sign?
>>>
>>> What if Novell and Microsoft were to become CAs and issue certificates
>>>
>>> to their customers directly, at least their larger accounts.  Would
>>> the relying
>>> party have to try to divine whether a subscriber was running NetWare
>>> or
>>> NT in order to decide what domain they would be likely to be in?
>>>
>>> Santosh, have I misrepresented the issue here?  Feel free to correct
>>> me, if so.
>>> Maybe I just don't understand.
>>>
>>> Now, if the definition of "domain" were amended somewhat, perhaps some
>>> of these difficulties might go away.
>>>
>>> In particular, it seems to me that "domain" probably ought to have a
>>> lot to do
>>> with name subordination, or at least the possibility of doing name
>>> subordination,
>>> so that it would be deterministic.  That might not solve all of the
>>> concerns that those
>>> who are inclined to vote for option 2 might have in mind, but it might
>>> help.
>>>
>>> So if I am a Novell employee, and I receive an S/MIME message that
>>> contains
>>> a certificate that begins with c=US, o=Novell, I can probably make an
>>> excellent
>>> good guess of what CA to go to, assuming that Novell operates a CA in
>>> its
>>> own name.  But where do I go for a certificate from Acme
>>> Manufacturing?
>>>
>>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>>> there are
>>> some things that could be done within the options 2 that would come
>>> closer to a
>>> compromise without breaking those existing clients.  But I need to
>>> think about that
>>> some more.  maybe someone else could volunteer some suggestions.
>>>
>>> Bob
>>>
>>> Robert R. Jueneman
>>> Novell, Inc.
>>> 122 E. 1700 South
>>> Provo, UT 84606
>>> [email-masked]
>>> 1-801-861-7387
>
>

Date: Thu, 03 Sep 1998 11:08:28 -0400
From: Peter Lindstrom <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Thu, 03 Sep 1998 10:33:58 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: [email-masked]
CC: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: Re: What the straw poll means
Sender: [email-masked]

See comment below.

[email-masked] wrote:
> 
> Santosh Chokhani <[email-masked]> writes:
> 
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> 
> The difference between the two options is primarily storage efficiency vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
> 
>    whether you care more about storage efficiency in the directory (option
>    2 stores intra-domain certificates twice) or retrieval efficiency for
>    the verifier (option 1 require a verifier that wants all a target CA's
>    certificates to retrieve them from two places).
>    typical usage scenarios by verifiers - i.e. the percentage of clients
>    that are going to want to locate just inter-domain certs, compared to
>    clients that either don't care about the difference or are only
>    interested in intra-domain certs.  Retrieval of _just_ inter-domain
>    certs is easier under option 1, retrieval of _all_ certs is easier under
>    option 2, and retrieval of _just_ intra-domain certs is the same under
>    both options.
> 
> Consider a fairly randomly structured PKI, where the verifier has a set of
> trusted roots loaded into it (assume they've been loaded under user
> control, with no particular order to them), and is trying to verify the key
> of some server that it hasn't spoken to before.  It has no idea of which
> "domain" the target's CA thinks it belongs to; it just wants to pull all
> the certs that have that CA as a subject, and see if it can construct a
> valid chain starting at one of its trusted roots.
> 
> Having the target CA divide its certificates between two places within the
> directory is no help to this verifier.  All it does it force the verifier
> to make two retrieval operations instead of the one that would be required
> by option 2.  The verifier isn't really interested in whether a particular
> certificate comes from another CA from the same "domain" as the target's CA
> - if it cares about "domains" at all, what it would be interested in is if
> any certs come from the same domain as the verifier (or one of its trusted
> roots), not the target (and of course that's verifier-specific).

	John,  the verifier does NOT have to invoke two retrieval operations. 
The verifier simply reads the CA entry requesting both the cACertificate
attribute and the crossCertificatePair attribute in the same search/read
operation.  All certificates are returned.  The verifier can then decide
whether to explore inter-domain, intra-domain, both , none, whatever. 
The verifier can lump them all together in the client application if
they like!  The main advantage to option 1 is we don't store the
certificates twice which is  a fundamental goal in all database
applications.   IMHO it applies to repositories and public key
infrastructures also.

	In summary option 1 never ever hurts the client.  It only helps to
organize the two types of certs based on the CAs definition of domain.  

	The general algorithm we envision is for clients to first explore the
cACertificate attribute, then explore the crossCertificatePair
attribute.   That way nothing will get missed.  It's not an all or
nothing choice.  It's an attempt to store the certificates once and to
group them to make logical decisions when exploring possibly complex
paths.
 
> 
> For the special (and probably quite common) case where the verifier and
> target happen to be in the same domain, the distinction probably is useful.
> Option 2 supports this case just as well as does option 1, by allowing the
> CA to place intra-domain certs in a separate place so that clients in that
> domain can retrieve them first (or possibly even _instead_of_ going to the
> all-certs list).

	But it duplicates the data, for which there is no technically sound
reason.

Dave Horvath
> John

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Thu, 03 Sep 1998 10:34:19 -0400
To: "Bob Jueneman" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject: Re: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

Bob,

At 06:33 PM 9/2/98 -0600, you wrote:
>This is almost as exciting as watching a horse race!
>
>But what are we to make of the situation if the vote is as 
>close as it appears to be at present -- does that truly indicate 
>a "rough consensus"?
>
>As of earlier this morning, Chromatix was ahead, with 
>8 votes cast; Entrust was tied with Microsoft with 4 votes 
>cast; and MISSI some others are clustered around third place.
>
>So far, with the exception of a split between MISSI and NIST
>as two US Government factions, the voting seems to be 
>strictly by company.

I hope you don't think that the government is particularly monolithic about
such things.

Tim Polk at times has lived in dread of the possibility that I might vote
for something on one of the PKIX 1 straw polls, that would have caused him
a lot of grief as editor.  That's entirely within NIST.

>
>Now, the polite fiction within the IETF is that memberships are by
>individual, and that there are no "votes" per se, and certainly not 
>on a company by company basis. That's the fiction, at least.. 
>Whether this convention shall long endure now that the IETF has 
>apparently lost some or all of its government funding and has 
>to become more self-sufficient will be interesting to see.
>
>But unless one side or the other starts to make some significant
>in-roads by the dint of more persuasive technical argument, then I think
>it's effectively a draw, and we may be counting companies and their 
>installed base at least as much, and perhaps more, than 
>balancing the technical alternatives.

As a Government guy, who has been doing computer standards work for a
couple of decades, I have a rough philosophy about this, which gives a lot
of deference to the investments of early implementors.  In most cases, for
new technologies at least, we the government, haven't made much up front
development investment in implementing technology alternatives. Of course
MISSI and DMS are the exception to this rule here, but, on the civil side
of the government, we don't have big money to put into development.  We
don't usually have a big investment already on the table.  So it's easy to
advocate an "ignore the developer's investment" viewpoint.  But we don't
ever have a competitive reason to want to shaft a competitor who'se ahead
of us in the marketplace, either.  

I think that it's destructive of standards development in general to
unnecessarily shaft early implementors.  I want to encourage companies to
take the plunge and go ahead and build something, not wait for a standard
to get finished first.  There are a lot of risks in this for the
implementors, and I don't want to add to them.  So I tend to give a lot of
deference to the investments of early implementors, because I think that it
makes the process of creating standards work better.

Now there are some minor Government installed base issues.  Many, perhaps
most, of the PKI applications and pilots in the civil part of the
government that use what I would call a "full function" PKI, are based on
one commercial product at this point. But we're not talking a lot of big
operational systems here.  What is important to me is that the vendor of
that product has been effective in pioneering commercial PKI products that
actually build nontrivial certification paths and do nice things like
revocation. I frankly like Option 1 better, in the abstract, but I think
that the technical effect of either choice is not profound as far as I can
see, and I'm quite uncomfortable voting for something that apparently
shafts the pioneer commercial implementor a bit.  

Regards,

Bill Burr

Date: Thu, 03 Sep 1998 09:56:48 -0400
From: Susan Joseph <[email-masked]>
Reply-To: [email-masked]
Organization: BBN
To: [email-masked]
Subject: Option 1
Sender: [email-masked]

--
Susan Joseph
GTE Internetworking
9810 Patuxent Woods Drive
Columbia, MD 21046
Tel:  (410) 309-8324
Fax: (410) 309-8315
E-Mail:  [email-masked]

Date: 3 Sep 1998 08:52:29 -0400
Subject: For Option 1
To: "PKIX Mail List" <[email-masked]>
From: "Chris Francis" <[email-masked]>
Sender: [email-masked]

                                             Inter-Office Memo
                                      For Option 1

Chris Francis
Raytheon Systems

Date: Thu, 03 Sep 1998 08:53:19 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: Nada Kapidzic Cicovic <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
Subject: Re: What the straw poll means
Sender: [email-masked]

Nada Kapidzic Cicovic wrote:
> 
> At 20:48 9/2/98 -0400, Santosh Chokhani wrote:
> >Yes Bob.  I hate to say this, but you have misinterpreted.
> >
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> >
> >Option 1 achieves everything option 2 and with efficiency.
> >
> >I do not understand how option 2 solves your problems either.  We need
> >to have a discussion on computational complexity of path development to
> >allay your concerns.
> >
> >The way I look at the difference between the two options is that if
> >n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
> >bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
> >another.  When you retrieve the two buckets (which you must for path
> >development efficiency), option 2 gives you n+n1 certificates and option
> >1 gives you exactly all n.
> 
> With option 2 you do not have to look at n1 certificates (cACertificate
> attribute) at all. The n ones (from crossCertificatePair) are sufficient
> for your path building.

	We are back the problem we raised earlier.  Clients that attempt to
efficiently develop a path from the end entity to the trusted root must
explore 'n' paths (worst case scenario)  prior to finding the correct
one with option 2.  Option 1 helps in this area, but this gets back to
the definition of domain since paths in our domain will probably be the
most efficient.  Is it really a problem if all CAs do NOT standardize on
a definition for domain?  I don't think so.  An algorithm for efficient
path development (end entity to root) should always explore paths using
the cACertifcate first, then fall back to the crossCertificatePair
attribute.  That way the last resort is to explore cross
certifications.   With option 1 this is accomplished without duplication
of data. 

	Using this algorithm a CA may interpret the domain as it wishes, with
only performance impacts to path development on the client side.  

	Building a path from the root to the end entity is not a problem
either.  If the CA chooses, it may store all certificates that it issues
in the reverse component of the crossCertificatePair attribute.  That
way a client can explore all possibilities.

	Option 1 satisfies requirements for building path in either direction
without duplicating data and adds increased efficiency at the CAs
discretion.

Dave Horvath

> 
> Nada
> 
> >
> >> -----Original Message-----
> >> From:        Bob Jueneman [SMTP:[email-masked]]
> >> Sent:        Wednesday, September 02, 1998 8:33 PM
> >> To:  [email-masked]
> >> Cc:  [email-masked]
> >> Subject:     What the straw poll means
> >>
> >> This is almost as exciting as watching a horse race!
> >>
> >> But what are we to make of the situation if the vote is as
> >> close as it appears to be at present -- does that truly indicate
> >> a "rough consensus"?
> >>
> >> As of earlier this morning, Chromatix was ahead, with
> >> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> >> cast; and MISSI some others are clustered around third place.
> >>
> >> So far, with the exception of a split between MISSI and NIST
> >> as two US Government factions, the voting seems to be
> >> strictly by company.
> >>
> >> Now, the polite fiction within the IETF is that memberships are by
> >> individual, and that there are no "votes" per se, and certainly not
> >> on a company by company basis. That's the fiction, at least..
> >> Whether this convention shall long endure now that the IETF has
> >> apparently lost some or all of its government funding and has
> >> to become more self-sufficient will be interesting to see.
> >>
> >> But unless one side or the other starts to make some significant
> >> in-roads by the dint of more persuasive technical argument, then I
> >> think
> >> it's effectively a draw, and we may be counting companies and their
> >> installed base at least as much, and perhaps more, than
> >> balancing the technical alternatives.
> >>
> >> Now, if we are truly at a technical impasse and the vote has to be
> >> binary, i.e., only one way or the other, then maybe counting installed
> >> clients and minimizing the pain is really the way to go, but frankly
> >> that approach makes me uncomfortable.  I want both interoperability
> >> AND efficiency, and I would hate to see us don't want to be
> >> pressured into a less than satisfactory decision, whatever that is,
> >>  just because we are in a rush to get over the next hurdle in the
> >> standards progression.
> >>
> >> I originally said that I was inclined to go with option 1, because
> >> it at least appeared to be simpler.  However, I also said that I was
> >> concerned about the "local" definition of a domain by a CA,
> >> and the more I think about it, the more concerned I get.
> >>
> >> That approach might be viable for an organization such as MISSI,
> >> where everyone presumably knows what community of interest
> >> they fall into, but how would it apply to a public CA such as
> >> VeriSign?
> >>
> >> Would they view all of their certificates as falling into one domain,
> >> including any certificates issued by subordinate CAs, as in the case
> >> of the old RSA Commercial hierarchy?
> >>
> >> What about GTE CyberTrust, considering their presumed affinity
> >> with their ISP business. Would all of those certificates fall into
> >> one domain?
> >>
> >> Now suppose I want to validate a certificate from Erols.  Do I decide
> >> that
> >> because Erols is in the top half of the alphabet that they probably
> >> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
> >> East Coast/West Coast split, like radio and TV stations use W or K in
> >> their call sign?
> >>
> >> What if Novell and Microsoft were to become CAs and issue certificates
> >>
> >> to their customers directly, at least their larger accounts.  Would
> >> the relying
> >> party have to try to divine whether a subscriber was running NetWare
> >> or
> >> NT in order to decide what domain they would be likely to be in?
> >>
> >> Santosh, have I misrepresented the issue here?  Feel free to correct
> >> me, if so.
> >> Maybe I just don't understand.
> >>
> >> Now, if the definition of "domain" were amended somewhat, perhaps some
> >> of these difficulties might go away.
> >>
> >> In particular, it seems to me that "domain" probably ought to have a
> >> lot to do
> >> with name subordination, or at least the possibility of doing name
> >> subordination,
> >> so that it would be deterministic.  That might not solve all of the
> >> concerns that those
> >> who are inclined to vote for option 2 might have in mind, but it might
> >> help.
> >>
> >> So if I am a Novell employee, and I receive an S/MIME message that
> >> contains
> >> a certificate that begins with c=US, o=Novell, I can probably make an
> >> excellent
> >> good guess of what CA to go to, assuming that Novell operates a CA in
> >> its
> >> own name.  But where do I go for a certificate from Acme
> >> Manufacturing?
> >>
> >> I don't mean to beat up on the option 1 folks exclusively -- maybe
> >> there are
> >> some things that could be done within the options 2 that would come
> >> closer to a
> >> compromise without breaking those existing clients.  But I need to
> >> think about that
> >> some more.  maybe someone else could volunteer some suggestions.
> >>
> >> Bob
> >>
> >> Robert R. Jueneman
> >> Novell, Inc.
> >> 122 E. 1700 South
> >> Provo, UT 84606
> >> [email-masked]
> >> 1-801-861-7387
> >

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

From: [email-masked]
To: Santosh Chokhani <[email-masked]>
cc: [email-masked]
Date: Thu, 3 Sep 1998 08:50:38 -0400
Subject: RE: What the straw poll means
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk

Santosh Chokhani <[email-masked]> writes:

>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.

The difference between the two options is primarily storage efficiency vs.
retrieval efficiency.  Both options divide a CAs certs into two piles.
Option 1 has pile A containing only intra-domain certs, and pile B
containing only inter-domain certs; option 2 has pile A containing only
intra-domain certs and pite B containing all certs.  Which option is
superior depends on two things:

   whether you care more about storage efficiency in the directory (option
   2 stores intra-domain certificates twice) or retrieval efficiency for
   the verifier (option 1 require a verifier that wants all a target CA's
   certificates to retrieve them from two places).
   typical usage scenarios by verifiers - i.e. the percentage of clients
   that are going to want to locate just inter-domain certs, compared to
   clients that either don't care about the difference or are only
   interested in intra-domain certs.  Retrieval of _just_ inter-domain
   certs is easier under option 1, retrieval of _all_ certs is easier under
   option 2, and retrieval of _just_ intra-domain certs is the same under
   both options.

Consider a fairly randomly structured PKI, where the verifier has a set of
trusted roots loaded into it (assume they've been loaded under user
control, with no particular order to them), and is trying to verify the key
of some server that it hasn't spoken to before.  It has no idea of which
"domain" the target's CA thinks it belongs to; it just wants to pull all
the certs that have that CA as a subject, and see if it can construct a
valid chain starting at one of its trusted roots.

Having the target CA divide its certificates between two places within the
directory is no help to this verifier.  All it does it force the verifier
to make two retrieval operations instead of the one that would be required
by option 2.  The verifier isn't really interested in whether a particular
certificate comes from another CA from the same "domain" as the target's CA
- if it cares about "domains" at all, what it would be interested in is if
any certs come from the same domain as the verifier (or one of its trusted
roots), not the target (and of course that's verifier-specific).

For the special (and probably quite common) case where the verifier and
target happen to be in the same domain, the distinction probably is useful.
Option 2 supports this case just as well as does option 1, by allowing the
CA to place intra-domain certs in a separate place so that clients in that
domain can retrieve them first (or possibly even _instead_of_ going to the
all-certs list).

John

Date: Thu, 03 Sep 1998 08:27:50 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: Sean Mullan <[email-masked]>
CC: Sharon Boeyen <[email-masked]>, [email-masked]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
Sender: [email-masked]

Sean Mullan wrote:
> 
> I agree that the forward & reverse elements of the crossCertificatePair
> are useful. It would be nice if the cACertificate attribute contained
> forward and reverse elements too.
> 
> One issue I have with the crossCertificatePair and the forward &
> reverse elements is that I believe they are a single-valued pair (meaning
> you can't have more than one forward/reverse element per pair).
> What do you do if CA1 issues more than 1 cross certificate to CA2
> (or vice versa)?

	Sean,
		The attribute is multi-valued, therefore, you would construct multiple
"single valued" pairs, and place them in the attribute.  The clients
could then determine the appropriate CA relationship
(crossCertificatePair) for the particular application.

Dave H

> 
> --Sean
> 
> Sharon Boeyen wrote:
> >
> > Hi Bob,
> >
> > I don't think we'll every get to a point where people stop populating the
> > crossCertificatePair attribute, regardless of the result of the straw poll.
> > The forward/reverse elements in the syntax of this attribute are very useful
> > since not all path discovery algorithms are identical. Path discovery can be
> > done many ways including beginning from the subject and moving toward a
> > trust anchor, beginning from a trust anchor and moving toward a subject,
> > beginning at both ends etc etc.   Being able to retrieve both forward and
> > reverse certificates from a single entry rather than checking the directory
> > entries of two CAs is a useful feature for some algorithms.
> > ------------------
> > Sharon Boeyen
> > Entrust Technologies
> >
> > mailto:[email-masked]  Tel: (613) 247-3181
> > http://www.entrust.com            Fax: (613) 247-3690
> >
> >
> > > ----------
> > > From:         Bob Jueneman[SMTP:[email-masked]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [email-masked]; [email-masked]; [email-masked]
> > > Subject:      Re: Straw Poll cACertificate &
> > > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > >
> > > I'm still on the fence, and trying to decide between the two options.
> > >
> > > But why is a binary decision necessary?
> > >
> > > If I understand Tim's points, option 2 is a superset of option 1,
> > > and a significant number of clients only support option 2.
> > >
> > > Option 1, however, is at least arguably superior from a network and
> > > directory performance standpoint, although I am still very confused
> > > about exactly who defines a "domain" and how the relying party is
> > > supposed to intuit what "local choice" some CA made.
> > >
> > > Would a viable compromise position be to support option 2 as the initial
> > > direction, and to transition to option 1 at some later point in time, say
> > > 36 months from now, assuming further work clearly establishes that
> > > option 1 is completely workable?
> > >
> > > My directory guys assure me that the directory is effectively neutral in
> > > this,
> > > except for the possible performance issues.  So all that has to happen
> > > is for CAs to stop populating the crossCertificate pair. Is that correct?
> > >
> > > On the other hand, does this give rise to a worst of both worlds case
> > > from the perspective of the client software complexity?
> > >
> > > Bob
> > >

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Thu, 03 Sep 1998 08:00:17 -0400
From: Richard Pimental <[email-masked]>
Organization: Chromatix, Inc.
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------BBC97F524D955BDFBA611C8B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------BBC97F524D955BDFBA611C8B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Pimental
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Richard Pimental
n:              Pimental;Richard
org:            Chromatix, Inc.
adr:            Chromatix, Inc.;;10451 Twin Rivers Road, Suite 265;Columbia;MD;21044;US
email;internet: [email-masked]
title:          Software Engineer
tel;work:       (301) 596-8466
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------BBC97F524D955BDFBA611C8B--

From: Sharon Boeyen <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], "'Santosh Chokhani'" <[email-masked]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 12:35:00 +0100
Sender: [email-masked]

The "two buckets" is exactly what I was trying to avoid in the earlier
debate on this topic, however I believe that the single bucket option
was rejected in the Chicago meeting. The single bucket option is the
text which is currently in the Internet Draft. With that text, all self
signed (or self issued certificates) were to be placed in the
cACertificate attribute and all certificates issued by one CA to a
different CA were put in the crossCertificatePair attribute. Depending
on the particular path development algorithm being used by a relying
party, directory search tools, especially when we evolve to LDAPv3 could
be used to filter the content of the forward and or reverse elements of
that SINGLE attribute and provide the relying party with the set of
certificates of interest to that particular relying party. 

I still believe that this is the best solution because the relying party
systems are the ones that know which certs are of interest to them, not
the CA that happened to issue the certs, especially in the post PEM
world where any CA could legitimately have certs issued for it by
several CAs.

My strong support for Option 2 in the straw poll is because the above
was rejected by the meeting and I see Option 2 as a workable compromise
ONLY because there is a complete set of certs in a single attribute and
relying parties can do what is of interest to them without knowing the
definition of domain which each individual CA happens to use. For self
contained environments wanting to make use of a CA or set of CAs certs
issued within some locally defined domain, this is still possible.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 2, 1998 8:48 PM
> To: 	'Bob Jueneman'; [email-masked]
> Cc: 	Santosh Chokhani
> Subject: 	RE: What the straw poll means
> 
> Yes Bob.  I hate to say this, but you have misinterpreted.
> 
> The basic difference between the two approaches is the under option 1
> you store a certificate only one time under a CA's entry.  Which
> certifying CA is in its domain is upto a subject CA to decide.
> 
> In all honesty, I do not see a benefit to option 2 except for the
> argument that some installed base already does it this way.
> 
> Option 1 achieves everything option 2 and with efficiency.
> 
> I do not understand how option 2 solves your problems either.  We need
> to have a discussion on computational complexity of path development
> to
> allay your concerns.
> 
> The way I look at the difference between the two options is that if
> n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> one
> bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
> another.  When you retrieve the two buckets (which you must for path
> development efficiency), option 2 gives you n+n1 certificates and
> option
> 1 gives you exactly all n.
> 
> > -----Original Message-----
> > From:	Bob Jueneman [SMTP:[email-masked]]
> > Sent:	Wednesday, September 02, 1998 8:33 PM
> > To:	[email-masked]
> > Cc:	[email-masked]
> > Subject:	What the straw poll means
> > 
> > This is almost as exciting as watching a horse race!
> > 
> > But what are we to make of the situation if the vote is as 
> > close as it appears to be at present -- does that truly indicate 
> > a "rough consensus"?
> > 
> > As of earlier this morning, Chromatix was ahead, with 
> > 8 votes cast; Entrust was tied with Microsoft with 4 votes 
> > cast; and MISSI some others are clustered around third place.
> > 
> > So far, with the exception of a split between MISSI and NIST
> > as two US Government factions, the voting seems to be 
> > strictly by company.
> > 
> > Now, the polite fiction within the IETF is that memberships are by
> > individual, and that there are no "votes" per se, and certainly not 
> > on a company by company basis. That's the fiction, at least.. 
> > Whether this convention shall long endure now that the IETF has 
> > apparently lost some or all of its government funding and has 
> > to become more self-sufficient will be interesting to see.
> > 
> > But unless one side or the other starts to make some significant
> > in-roads by the dint of more persuasive technical argument, then I
> > think
> > it's effectively a draw, and we may be counting companies and their 
> > installed base at least as much, and perhaps more, than 
> > balancing the technical alternatives.
> > 
> > Now, if we are truly at a technical impasse and the vote has to be 
> > binary, i.e., only one way or the other, then maybe counting
> installed
> > clients and minimizing the pain is really the way to go, but frankly
> 
> > that approach makes me uncomfortable.  I want both interoperability
> > AND efficiency, and I would hate to see us don't want to be 
> > pressured into a less than satisfactory decision, whatever that is,
> >  just because we are in a rush to get over the next hurdle in the 
> > standards progression.
> > 
> > I originally said that I was inclined to go with option 1, because 
> > it at least appeared to be simpler.  However, I also said that I was
> 
> > concerned about the "local" definition of a domain by a CA,
> > and the more I think about it, the more concerned I get.
> > 
> > That approach might be viable for an organization such as MISSI,
> > where everyone presumably knows what community of interest 
> > they fall into, but how would it apply to a public CA such as
> > VeriSign?
> > 
> > Would they view all of their certificates as falling into one
> domain,
> > including any certificates issued by subordinate CAs, as in the case
> > of the old RSA Commercial hierarchy?
> > 
> > What about GTE CyberTrust, considering their presumed affinity
> > with their ISP business. Would all of those certificates fall into
> > one domain?
> > 
> > Now suppose I want to validate a certificate from Erols.  Do I
> decide
> > that
> > because Erols is in the top half of the alphabet that they probably 
> > use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
> > East Coast/West Coast split, like radio and TV stations use W or K
> in 
> > their call sign?
> > 
> > What if Novell and Microsoft were to become CAs and issue
> certificates
> > 
> > to their customers directly, at least their larger accounts.  Would
> > the relying 
> > party have to try to divine whether a subscriber was running NetWare
> > or
> > NT in order to decide what domain they would be likely to be in?
> > 
> > Santosh, have I misrepresented the issue here?  Feel free to correct
> > me, if so.
> > Maybe I just don't understand.
> > 
> > Now, if the definition of "domain" were amended somewhat, perhaps
> some
> > of these difficulties might go away.
> > 
> > In particular, it seems to me that "domain" probably ought to have a
> > lot to do 
> > with name subordination, or at least the possibility of doing name
> > subordination, 
> > so that it would be deterministic.  That might not solve all of the
> > concerns that those
> > who are inclined to vote for option 2 might have in mind, but it
> might
> > help.
> > 
> > So if I am a Novell employee, and I receive an S/MIME message that
> > contains 
> > a certificate that begins with c=US, o=Novell, I can probably make
> an
> > excellent 
> > good guess of what CA to go to, assuming that Novell operates a CA
> in
> > its 
> > own name.  But where do I go for a certificate from Acme
> > Manufacturing?
> > 
> > I don't mean to beat up on the option 1 folks exclusively -- maybe
> > there are 
> > some things that could be done within the options 2 that would come
> > closer to a
> > compromise without breaking those existing clients.  But I need to
> > think about that
> > some more.  maybe someone else could volunteer some suggestions.
> > 
> > Bob
> > 
> > Robert R. Jueneman
> > Novell, Inc.
> > 122 E. 1700 South
> > Provo, UT 84606
> > [email-masked]
> > 1-801-861-7387
> 

From: Sharon Boeyen <[email-masked]>
To: Sharon Boeyen <[email-masked]>, "'Sean Mullan'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX  LDAPv2 schema I-D
Date: Thu, 3 Sep 1998 11:57:20 +0100
Sender: [email-masked]

Sean, re your question on crossCertificatePair - This is a multi-valued
attribute and there can be any number of instances of
CrossCertificatePair. So if CA1 issued more than one certificate to CA2,
these can all be present in the same attribute, just in a different
instance of CertificatePair.    

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Sean Mullan[SMTP:[email-masked]]
> Sent: 	September 2, 1998 4:32 PM
> To: 	Sharon Boeyen
> Cc: 	[email-masked]
> Subject: 	Re: Straw Poll cACertificate &
> crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
> 
> I agree that the forward & reverse elements of the
> crossCertificatePair
> are useful. It would be nice if the cACertificate attribute contained
> forward and reverse elements too.
> 
> One issue I have with the crossCertificatePair and the forward & 
> reverse elements is that I believe they are a single-valued pair
> (meaning
> you can't have more than one forward/reverse element per pair).
> What do you do if CA1 issues more than 1 cross certificate to CA2
> (or vice versa)?
> 
> --Sean
>  
> Sharon Boeyen wrote:
> > 
> > Hi Bob,
> > 
> > I don't think we'll every get to a point where people stop
> populating the
> > crossCertificatePair attribute, regardless of the result of the
> straw poll.
> > The forward/reverse elements in the syntax of this attribute are
> very useful
> > since not all path discovery algorithms are identical. Path
> discovery can be
> > done many ways including beginning from the subject and moving
> toward a
> > trust anchor, beginning from a trust anchor and moving toward a
> subject,
> > beginning at both ends etc etc.   Being able to retrieve both
> forward and
> > reverse certificates from a single entry rather than checking the
> directory
> > entries of two CAs is a useful feature for some algorithms.
> > ------------------
> > Sharon Boeyen
> > Entrust Technologies
> > 
> > mailto:[email-masked]  Tel: (613) 247-3181
> > http://www.entrust.com            Fax: (613) 247-3690
> > 
> > 
> > > ----------
> > > From:         Bob Jueneman[SMTP:[email-masked]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [email-masked]; [email-masked]; [email-masked]
> > > Subject:      Re: Straw Poll cACertificate &
> > > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > >
> > > I'm still on the fence, and trying to decide between the two
> options.
> > >
> > > But why is a binary decision necessary?
> > >
> > > If I understand Tim's points, option 2 is a superset of option 1,
> > > and a significant number of clients only support option 2.
> > >
> > > Option 1, however, is at least arguably superior from a network
> and
> > > directory performance standpoint, although I am still very
> confused
> > > about exactly who defines a "domain" and how the relying party is
> > > supposed to intuit what "local choice" some CA made.
> > >
> > > Would a viable compromise position be to support option 2 as the
> initial
> > > direction, and to transition to option 1 at some later point in
> time, say
> > > 36 months from now, assuming further work clearly establishes that
> > > option 1 is completely workable?
> > >
> > > My directory guys assure me that the directory is effectively
> neutral in
> > > this,
> > > except for the possible performance issues.  So all that has to
> happen
> > > is for CAs to stop populating the crossCertificate pair. Is that
> correct?
> > >
> > > On the other hand, does this give rise to a worst of both worlds
> case
> > > from the perspective of the client software complexity?
> > >
> > > Bob
> > >
> 

Date: Thu, 03 Sep 1998 11:02:39 +0200
To: Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[email-masked]>
Sender: [email-masked]

At 20:48 9/2/98 -0400, Santosh Chokhani wrote:
>Yes Bob.  I hate to say this, but you have misinterpreted.
>
>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.
>
>Option 1 achieves everything option 2 and with efficiency.
>
>I do not understand how option 2 solves your problems either.  We need
>to have a discussion on computational complexity of path development to
>allay your concerns.
>
>The way I look at the difference between the two options is that if
>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>another.  When you retrieve the two buckets (which you must for path
>development efficiency), option 2 gives you n+n1 certificates and option
>1 gives you exactly all n.

With option 2 you do not have to look at n1 certificates (cACertificate
attribute) at all. The n ones (from crossCertificatePair) are sufficient
for your path building.

Nada

>
>> -----Original Message-----
>> From:	Bob Jueneman [SMTP:[email-masked]]
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[email-masked]
>> Cc:	[email-masked]
>> Subject:	What the straw poll means
>> 
>> This is almost as exciting as watching a horse race!
>> 
>> But what are we to make of the situation if the vote is as 
>> close as it appears to be at present -- does that truly indicate 
>> a "rough consensus"?
>> 
>> As of earlier this morning, Chromatix was ahead, with 
>> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
>> cast; and MISSI some others are clustered around third place.
>> 
>> So far, with the exception of a split between MISSI and NIST
>> as two US Government factions, the voting seems to be 
>> strictly by company.
>> 
>> Now, the polite fiction within the IETF is that memberships are by
>> individual, and that there are no "votes" per se, and certainly not 
>> on a company by company basis. That's the fiction, at least.. 
>> Whether this convention shall long endure now that the IETF has 
>> apparently lost some or all of its government funding and has 
>> to become more self-sufficient will be interesting to see.
>> 
>> But unless one side or the other starts to make some significant
>> in-roads by the dint of more persuasive technical argument, then I
>> think
>> it's effectively a draw, and we may be counting companies and their 
>> installed base at least as much, and perhaps more, than 
>> balancing the technical alternatives.
>> 
>> Now, if we are truly at a technical impasse and the vote has to be 
>> binary, i.e., only one way or the other, then maybe counting installed
>> clients and minimizing the pain is really the way to go, but frankly 
>> that approach makes me uncomfortable.  I want both interoperability
>> AND efficiency, and I would hate to see us don't want to be 
>> pressured into a less than satisfactory decision, whatever that is,
>>  just because we are in a rush to get over the next hurdle in the 
>> standards progression.
>> 
>> I originally said that I was inclined to go with option 1, because 
>> it at least appeared to be simpler.  However, I also said that I was  
>> concerned about the "local" definition of a domain by a CA,
>> and the more I think about it, the more concerned I get.
>> 
>> That approach might be viable for an organization such as MISSI,
>> where everyone presumably knows what community of interest 
>> they fall into, but how would it apply to a public CA such as
>> VeriSign?
>> 
>> Would they view all of their certificates as falling into one domain,
>> including any certificates issued by subordinate CAs, as in the case
>> of the old RSA Commercial hierarchy?
>> 
>> What about GTE CyberTrust, considering their presumed affinity
>> with their ISP business. Would all of those certificates fall into
>> one domain?
>> 
>> Now suppose I want to validate a certificate from Erols.  Do I decide
>> that
>> because Erols is in the top half of the alphabet that they probably 
>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
>> East Coast/West Coast split, like radio and TV stations use W or K in 
>> their call sign?
>> 
>> What if Novell and Microsoft were to become CAs and issue certificates
>> 
>> to their customers directly, at least their larger accounts.  Would
>> the relying 
>> party have to try to divine whether a subscriber was running NetWare
>> or
>> NT in order to decide what domain they would be likely to be in?
>> 
>> Santosh, have I misrepresented the issue here?  Feel free to correct
>> me, if so.
>> Maybe I just don't understand.
>> 
>> Now, if the definition of "domain" were amended somewhat, perhaps some
>> of these difficulties might go away.
>> 
>> In particular, it seems to me that "domain" probably ought to have a
>> lot to do 
>> with name subordination, or at least the possibility of doing name
>> subordination, 
>> so that it would be deterministic.  That might not solve all of the
>> concerns that those
>> who are inclined to vote for option 2 might have in mind, but it might
>> help.
>> 
>> So if I am a Novell employee, and I receive an S/MIME message that
>> contains 
>> a certificate that begins with c=US, o=Novell, I can probably make an
>> excellent 
>> good guess of what CA to go to, assuming that Novell operates a CA in
>> its 
>> own name.  But where do I go for a certificate from Acme
>> Manufacturing?
>> 
>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>> there are 
>> some things that could be done within the options 2 that would come
>> closer to a
>> compromise without breaking those existing clients.  But I need to
>> think about that
>> some more.  maybe someone else could volunteer some suggestions.
>> 
>> Bob
>> 
>> Robert R. Jueneman
>> Novell, Inc.
>> 122 E. 1700 South
>> Provo, UT 84606
>> [email-masked]
>> 1-801-861-7387
>

Date: Wed, 02 Sep 1998 19:09:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: What the straw poll means
Sender: [email-masked]

Santosh doesn't seem to have answered the questions I've raised
regarding the definition of the domain, but he seems to believe that
option 2 doesn't solve that problem either.

If so, I am increasingly beginning to lean towards "NONE OF THE 
ABOVE".

Rebuttal, Sharon/Carlisle?

Bob

>Yes Bob.  I hate to say this, but you have misinterpreted.
>
>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.
>
>Option 1 achieves everything option 2 and with efficiency.
>
>I do not understand how option 2 solves your problems either.  We need
>to have a discussion on computational complexity of path development to
>allay your concerns.
>
>The way I look at the difference between the two options is that if
>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>another.  When you retrieve the two buckets (which you must for path
>development efficiency), option 2 gives you n+n1 certificates and option
>1 gives you exactly all n.
>
>> -----Original Message-----
>> From:	Bob Jueneman [SMTP:[email-masked]] 
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[email-masked] 
>> Cc:	[email-masked] 
>> Subject:	What the straw poll means
>> 
>> This is almost as exciting as watching a horse race!
>> 
>> But what are we to make of the situation if the vote is as 
>> close as it appears to be at present -- does that truly indicate 
>> a "rough consensus"?
>> 
>> As of earlier this morning, Chromatix was ahead, with 
>> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
>> cast; and MISSI some others are clustered around third place.
>> 
>> So far, with the exception of a split between MISSI and NIST
>> as two US Government factions, the voting seems to be 
>> strictly by company.
>> 
>> Now, the polite fiction within the IETF is that memberships are by
>> individual, and that there are no "votes" per se, and certainly not 
>> on a company by company basis. That's the fiction, at least.. 
>> Whether this convention shall long endure now that the IETF has 
>> apparently lost some or all of its government funding and has 
>> to become more self-sufficient will be interesting to see.
>> 
>> But unless one side or the other starts to make some significant
>> in-roads by the dint of more persuasive technical argument, then I
>> think
>> it's effectively a draw, and we may be counting companies and their 
>> installed base at least as much, and perhaps more, than 
>> balancing the technical alternatives.
>> 
>> Now, if we are truly at a technical impasse and the vote has to be 
>> binary, i.e., only one way or the other, then maybe counting installed
>> clients and minimizing the pain is really the way to go, but frankly 
>> that approach makes me uncomfortable.  I want both interoperability
>> AND efficiency, and I would hate to see us don't want to be 
>> pressured into a less than satisfactory decision, whatever that is,
>>  just because we are in a rush to get over the next hurdle in the 
>> standards progression.
>> 
>> I originally said that I was inclined to go with option 1, because 
>> it at least appeared to be simpler.  However, I also said that I was  
>> concerned about the "local" definition of a domain by a CA,
>> and the more I think about it, the more concerned I get.
>> 
>> That approach might be viable for an organization such as MISSI,
>> where everyone presumably knows what community of interest 
>> they fall into, but how would it apply to a public CA such as
>> VeriSign?
>> 
>> Would they view all of their certificates as falling into one domain,
>> including any certificates issued by subordinate CAs, as in the case
>> of the old RSA Commercial hierarchy?
>> 
>> What about GTE CyberTrust, considering their presumed affinity
>> with their ISP business. Would all of those certificates fall into
>> one domain?
>> 
>> Now suppose I want to validate a certificate from Erols.  Do I decide
>> that
>> because Erols is in the top half of the alphabet that they probably 
>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
>> East Coast/West Coast split, like radio and TV stations use W or K in 
>> their call sign?
>> 
>> What if Novell and Microsoft were to become CAs and issue certificates
>> 
>> to their customers directly, at least their larger accounts.  Would
>> the relying 
>> party have to try to divine whether a subscriber was running NetWare
>> or
>> NT in order to decide what domain they would be likely to be in?
>> 
>> Santosh, have I misrepresented the issue here?  Feel free to correct
>> me, if so.
>> Maybe I just don't understand.
>> 
>> Now, if the definition of "domain" were amended somewhat, perhaps some
>> of these difficulties might go away.
>> 
>> In particular, it seems to me that "domain" probably ought to have a
>> lot to do 
>> with name subordination, or at least the possibility of doing name
>> subordination, 
>> so that it would be deterministic.  That might not solve all of the
>> concerns that those
>> who are inclined to vote for option 2 might have in mind, but it might
>> help.
>> 
>> So if I am a Novell employee, and I receive an S/MIME message that
>> contains 
>> a certificate that begins with c=US, o=Novell, I can probably make an
>> excellent 
>> good guess of what CA to go to, assuming that Novell operates a CA in
>> its 
>> own name.  But where do I go for a certificate from Acme
>> Manufacturing?
>> 
>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>> there are 
>> some things that could be done within the options 2 that would come
>> closer to a
>> compromise without breaking those existing clients.  But I need to
>> think about that
>> some more.  maybe someone else could volunteer some suggestions.
>> 
>> Bob
>> 
>> Robert R. Jueneman
>> Novell, Inc.
>> 122 E. 1700 South
>> Provo, UT 84606
>> [email-masked] 
>> 1-801-861-7387

From: Santosh Chokhani <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Wed, 2 Sep 1998 20:48:05 -0400
Sender: [email-masked]

Yes Bob.  I hate to say this, but you have misinterpreted.

The basic difference between the two approaches is the under option 1
you store a certificate only one time under a CA's entry.  Which
certifying CA is in its domain is upto a subject CA to decide.

In all honesty, I do not see a benefit to option 2 except for the
argument that some installed base already does it this way.

Option 1 achieves everything option 2 and with efficiency.

I do not understand how option 2 solves your problems either.  We need
to have a discussion on computational complexity of path development to
allay your concerns.

The way I look at the difference between the two options is that if
n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
another.  When you retrieve the two buckets (which you must for path
development efficiency), option 2 gives you n+n1 certificates and option
1 gives you exactly all n.

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Wednesday, September 02, 1998 8:33 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	What the straw poll means
> 
> This is almost as exciting as watching a horse race!
> 
> But what are we to make of the situation if the vote is as 
> close as it appears to be at present -- does that truly indicate 
> a "rough consensus"?
> 
> As of earlier this morning, Chromatix was ahead, with 
> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
> cast; and MISSI some others are clustered around third place.
> 
> So far, with the exception of a split between MISSI and NIST
> as two US Government factions, the voting seems to be 
> strictly by company.
> 
> Now, the polite fiction within the IETF is that memberships are by
> individual, and that there are no "votes" per se, and certainly not 
> on a company by company basis. That's the fiction, at least.. 
> Whether this convention shall long endure now that the IETF has 
> apparently lost some or all of its government funding and has 
> to become more self-sufficient will be interesting to see.
> 
> But unless one side or the other starts to make some significant
> in-roads by the dint of more persuasive technical argument, then I
> think
> it's effectively a draw, and we may be counting companies and their 
> installed base at least as much, and perhaps more, than 
> balancing the technical alternatives.
> 
> Now, if we are truly at a technical impasse and the vote has to be 
> binary, i.e., only one way or the other, then maybe counting installed
> clients and minimizing the pain is really the way to go, but frankly 
> that approach makes me uncomfortable.  I want both interoperability
> AND efficiency, and I would hate to see us don't want to be 
> pressured into a less than satisfactory decision, whatever that is,
>  just because we are in a rush to get over the next hurdle in the 
> standards progression.
> 
> I originally said that I was inclined to go with option 1, because 
> it at least appeared to be simpler.  However, I also said that I was  
> concerned about the "local" definition of a domain by a CA,
> and the more I think about it, the more concerned I get.
> 
> That approach might be viable for an organization such as MISSI,
> where everyone presumably knows what community of interest 
> they fall into, but how would it apply to a public CA such as
> VeriSign?
> 
> Would they view all of their certificates as falling into one domain,
> including any certificates issued by subordinate CAs, as in the case
> of the old RSA Commercial hierarchy?
> 
> What about GTE CyberTrust, considering their presumed affinity
> with their ISP business. Would all of those certificates fall into
> one domain?
> 
> Now suppose I want to validate a certificate from Erols.  Do I decide
> that
> because Erols is in the top half of the alphabet that they probably 
> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
> East Coast/West Coast split, like radio and TV stations use W or K in 
> their call sign?
> 
> What if Novell and Microsoft were to become CAs and issue certificates
> 
> to their customers directly, at least their larger accounts.  Would
> the relying 
> party have to try to divine whether a subscriber was running NetWare
> or
> NT in order to decide what domain they would be likely to be in?
> 
> Santosh, have I misrepresented the issue here?  Feel free to correct
> me, if so.
> Maybe I just don't understand.
> 
> Now, if the definition of "domain" were amended somewhat, perhaps some
> of these difficulties might go away.
> 
> In particular, it seems to me that "domain" probably ought to have a
> lot to do 
> with name subordination, or at least the possibility of doing name
> subordination, 
> so that it would be deterministic.  That might not solve all of the
> concerns that those
> who are inclined to vote for option 2 might have in mind, but it might
> help.
> 
> So if I am a Novell employee, and I receive an S/MIME message that
> contains 
> a certificate that begins with c=US, o=Novell, I can probably make an
> excellent 
> good guess of what CA to go to, assuming that Novell operates a CA in
> its 
> own name.  But where do I go for a certificate from Acme
> Manufacturing?
> 
> I don't mean to beat up on the option 1 folks exclusively -- maybe
> there are 
> some things that could be done within the options 2 that would come
> closer to a
> compromise without breaking those existing clients.  But I need to
> think about that
> some more.  maybe someone else could volunteer some suggestions.
> 
> Bob
> 
> Robert R. Jueneman
> Novell, Inc.
> 122 E. 1700 South
> Provo, UT 84606
> [email-masked]
> 1-801-861-7387

Date: Wed, 02 Sep 1998 18:42:40 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Sender: [email-masked]

><snip>
>>I'll grant that by suggesting that NR might apply to encryption, I am
>stretching the 
>>popular concept a bit, and effectively redefining the key usage to mean
>"exclusive
>>control of the private key by the names user".  But isn't that effectively
>what we have 
>>been saying?
>>
>
>I suggest that we stick to the standardized definitions of the key usage
>bits and leave
>policy issues out of a common certificate profile.

If there were any sense of the community as to what these definitions really
mean, or ought to mean, we would probably not be having this discussion.
Otherwise I would agree with you.
>
>non-repudiation is according to standard selected by the NR bit, not NR in
>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>other than non-repudiation are allowed for the key.

I believe that is exactly the issue. Are you suggesting that NR plus DS should not
be allowed?  Why?
>
>Restrictions regarding combinations of key usages are policy issues.
>Whether a particular key usage combination is good or bad has to be decided
>through the perspective of a community with common security requirements.
>
>Non-repudiation is defined to be (according to X.509):
>  non-repudiation - This service provides proof of the integrity and 
>  origin of data - both in an unforgeable relationship - which can be 
>  verified by any third party at any time.

That particular definition is both circular and could also apply to any kind
of digital signature, and so is conspicuously unhelpful, regardless of its
origins.  It's broken, and must be fixed, whether we provide an overlay
within PKIX that further refines it, or we start the process to drive through 
a defect report.
>
>Key escrow is not defined by non-repudiation so I would not use the NR bit
>as a "no-recovery" declaration.

I guess I could agree with you, as I don't like to overload bits.  So there is yet
another reason to submit a defect report, to add a key escrow/key recovery/GAK
notification bit.
>/Stefan

Bob

Date: Wed, 02 Sep 1998 18:33:01 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: What the straw poll means
Sender: [email-masked]

This is almost as exciting as watching a horse race!

But what are we to make of the situation if the vote is as 
close as it appears to be at present -- does that truly indicate 
a "rough consensus"?

As of earlier this morning, Chromatix was ahead, with 
8 votes cast; Entrust was tied with Microsoft with 4 votes 
cast; and MISSI some others are clustered around third place.

So far, with the exception of a split between MISSI and NIST
as two US Government factions, the voting seems to be 
strictly by company.

Now, the polite fiction within the IETF is that memberships are by
individual, and that there are no "votes" per se, and certainly not 
on a company by company basis. That's the fiction, at least.. 
Whether this convention shall long endure now that the IETF has 
apparently lost some or all of its government funding and has 
to become more self-sufficient will be interesting to see.

But unless one side or the other starts to make some significant
in-roads by the dint of more persuasive technical argument, then I think
it's effectively a draw, and we may be counting companies and their 
installed base at least as much, and perhaps more, than 
balancing the technical alternatives.

Now, if we are truly at a technical impasse and the vote has to be 
binary, i.e., only one way or the other, then maybe counting installed
clients and minimizing the pain is really the way to go, but frankly 
that approach makes me uncomfortable.  I want both interoperability
AND efficiency, and I would hate to see us don't want to be 
pressured into a less than satisfactory decision, whatever that is,
 just because we are in a rush to get over the next hurdle in the 
standards progression.

I originally said that I was inclined to go with option 1, because 
it at least appeared to be simpler.  However, I also said that I was  
concerned about the "local" definition of a domain by a CA,
and the more I think about it, the more concerned I get.

That approach might be viable for an organization such as MISSI,
where everyone presumably knows what community of interest 
they fall into, but how would it apply to a public CA such as VeriSign?

Would they view all of their certificates as falling into one domain,
including any certificates issued by subordinate CAs, as in the case
of the old RSA Commercial hierarchy?

What about GTE CyberTrust, considering their presumed affinity
with their ISP business. Would all of those certificates fall into
one domain?

Now suppose I want to validate a certificate from Erols.  Do I decide that
because Erols is in the top half of the alphabet that they probably 
use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
East Coast/West Coast split, like radio and TV stations use W or K in 
their call sign?

What if Novell and Microsoft were to become CAs and issue certificates 
to their customers directly, at least their larger accounts.  Would the relying 
party have to try to divine whether a subscriber was running NetWare or
NT in order to decide what domain they would be likely to be in?

Santosh, have I misrepresented the issue here?  Feel free to correct me, if so.
Maybe I just don't understand.

Now, if the definition of "domain" were amended somewhat, perhaps some
of these difficulties might go away.

In particular, it seems to me that "domain" probably ought to have a lot to do 
with name subordination, or at least the possibility of doing name subordination, 
so that it would be deterministic.  That might not solve all of the concerns that those
who are inclined to vote for option 2 might have in mind, but it might help.

So if I am a Novell employee, and I receive an S/MIME message that contains 
a certificate that begins with c=US, o=Novell, I can probably make an excellent 
good guess of what CA to go to, assuming that Novell operates a CA in its 
own name.  But where do I go for a certificate from Acme Manufacturing?

I don't mean to beat up on the option 1 folks exclusively -- maybe there are 
some things that could be done within the options 2 that would come closer to a
compromise without breaking those existing clients.  But I need to think about that
some more.  maybe someone else could volunteer some suggestions.

Bob

Robert R. Jueneman
Novell, Inc.
122 E. 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Wed, 02 Sep 1998 19:35:39 -0400
From: bgmiller <[email-masked]>
Reply-To: [email-masked]
Organization: Jones Internet Channel
To: ietf-pkix <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 19:19:11 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01BDD6A6.90B777E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_000A_01BDD6A6.90B777E0
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>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000A_01BDD6A6.90B777E0--

From: "Maloney, Teresa A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 15:58:03 -0700 
Sender: [email-masked]

Thanks

From: John Everson <[email-masked]>
Date: Wed, 2 Sep 1998 17:52:31 -0500
Subject: For Option 2
TO: [email-masked]
Sender: [email-masked]

From: "PACHL, Jan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 16:22:19 -0500
Sender: [email-masked]

From: Charles Moore <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: for Option 1
Date: Thu, 3 Sep 1998 07:03:54 +1000 
Sender: [email-masked]

From: MA Crane <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 17:09:46 -0400
Sender: [email-masked]

From: Rick Johnson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:59:20 -0700 
Sender: [email-masked]

Date: Wed, 02 Sep 1998 16:32:03 -0400
From: Sean Mullan <[email-masked]>
Organization: Sun Microsystems
To: Sharon Boeyen <[email-masked]>
CC: [email-masked]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
Sender: [email-masked]

I agree that the forward & reverse elements of the crossCertificatePair
are useful. It would be nice if the cACertificate attribute contained
forward and reverse elements too.

One issue I have with the crossCertificatePair and the forward & 
reverse elements is that I believe they are a single-valued pair (meaning
you can't have more than one forward/reverse element per pair).
What do you do if CA1 issues more than 1 cross certificate to CA2
(or vice versa)?

--Sean
 
Sharon Boeyen wrote:
> 
> Hi Bob,
> 
> I don't think we'll every get to a point where people stop populating the
> crossCertificatePair attribute, regardless of the result of the straw poll.
> The forward/reverse elements in the syntax of this attribute are very useful
> since not all path discovery algorithms are identical. Path discovery can be
> done many ways including beginning from the subject and moving toward a
> trust anchor, beginning from a trust anchor and moving toward a subject,
> beginning at both ends etc etc.   Being able to retrieve both forward and
> reverse certificates from a single entry rather than checking the directory
> entries of two CAs is a useful feature for some algorithms.
> ------------------
> Sharon Boeyen
> Entrust Technologies
> 
> mailto:[email-masked]  Tel: (613) 247-3181
> http://www.entrust.com            Fax: (613) 247-3690
> 
> 
> > ----------
> > From:         Bob Jueneman[SMTP:[email-masked]]
> > Sent:         September 1, 1998 7:20 PM
> > To:   [email-masked]; [email-masked]; [email-masked]
> > Subject:      Re: Straw Poll cACertificate &
> > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> >
> > I'm still on the fence, and trying to decide between the two options.
> >
> > But why is a binary decision necessary?
> >
> > If I understand Tim's points, option 2 is a superset of option 1,
> > and a significant number of clients only support option 2.
> >
> > Option 1, however, is at least arguably superior from a network and
> > directory performance standpoint, although I am still very confused
> > about exactly who defines a "domain" and how the relying party is
> > supposed to intuit what "local choice" some CA made.
> >
> > Would a viable compromise position be to support option 2 as the initial
> > direction, and to transition to option 1 at some later point in time, say
> > 36 months from now, assuming further work clearly establishes that
> > option 1 is completely workable?
> >
> > My directory guys assure me that the directory is effectively neutral in
> > this,
> > except for the possible performance issues.  So all that has to happen
> > is for CAs to stop populating the crossCertificate pair. Is that correct?
> >
> > On the other hand, does this give rise to a worst of both worlds case
> > from the perspective of the client software complexity?
> >
> > Bob
> >

From: Kenneth Eggers <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 14:55:08 -0400
Sender: [email-masked]

Kenneth W. Eggers  <[email-masked]> http://www.cygnacom.com
CygnaCom Solutions, Inc.  
7927 Jones Branch Drive, Suite 100 West
McLean, VA  22102
(703) 848-0883x228  fax: (703) 848-0960                    

From: Sharon Boeyen <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 19:40:43 +0100
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 2, 1998 2:17 PM
> To: 	'Sharon Boeyen'; [email-masked]; [email-masked]; 'Bob
> Jueneman'
> Cc: 	'Stefan Santesson'
> Subject: 	RE: Straw Poll cACertificate &
> crossCertificatePairattributes- PK IX LDAPv2 schema I-D
> 
> Hi Sharon and Stefan:
> 
> While option 1 does not mandate it, it does not prohibit a CA from
> populating all the certificates it has issued to other CAs (inter as
> well as intra domain) in the reverse attribute of the cross
> certificate
> pair.
Agreed

> The fundamental difference between the two options is that under
> option
> 1 certificates are not duplicated in a CA's entry.
There are other fundamental differences as well such as requiring CAs to
split the certs to populate 2 attributes in Option 1 and requiring
clients to know the meaning of domain ahead of time in order to be able
to take any advantage of the split storage, else to require retrieval
from 2 attributes.

> > -----Original Message-----
> > From:	Sharon Boeyen [SMTP:[email-masked]]
> > Sent:	Wednesday, September 02, 1998 8:46 AM
> > To:	[email-masked]; [email-masked]; 'Bob Jueneman'
> > Subject:	RE: Straw Poll cACertificate &
> > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > 
> > Hi Bob,
> > 
> > I don't think we'll every get to a point where people stop
> populating
> > the
> > crossCertificatePair attribute, regardless of the result of the
> straw
> > poll.
> > The forward/reverse elements in the syntax of this attribute are
> very
> > useful
> > since not all path discovery algorithms are identical. Path
> discovery
> > can be
> > done many ways including beginning from the subject and moving
> toward
> > a
> > trust anchor, beginning from a trust anchor and moving toward a
> > subject,
> > beginning at both ends etc etc.   Being able to retrieve both
> forward
> > and
> > reverse certificates from a single entry rather than checking the
> > directory
> > entries of two CAs is a useful feature for some algorithms. 
> > ------------------
> > Sharon Boeyen                  
> > Entrust Technologies
> > 
> > mailto:[email-masked]  Tel: (613) 247-3181 
> > http://www.entrust.com            Fax: (613) 247-3690 
> >        
> > 
> > 
> > > ----------
> > > From: 	Bob Jueneman[SMTP:[email-masked]]
> > > Sent: 	September 1, 1998 7:20 PM
> > > To: 	[email-masked]; [email-masked]; [email-masked]
> > > Subject: 	Re: Straw Poll cACertificate &
> > > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > > 
> > > I'm still on the fence, and trying to decide between the two
> > options.
> > > 
> > > But why is a binary decision necessary?
> > > 
> > > If I understand Tim's points, option 2 is a superset of option 1, 
> > > and a significant number of clients only support option 2.
> > > 
> > > Option 1, however, is at least arguably superior from a network
> and
> > > directory performance standpoint, although I am still very
> confused 
> > > about exactly who defines a "domain" and how the relying party is
> > > supposed to intuit what "local choice" some CA made.
> > > 
> > > Would a viable compromise position be to support option 2 as the
> > initial
> > > direction, and to transition to option 1 at some later point in
> > time, say 
> > > 36 months from now, assuming further work clearly establishes that
> 
> > > option 1 is completely workable?
> > > 
> > > My directory guys assure me that the directory is effectively
> > neutral in
> > > this,
> > > except for the possible performance issues.  So all that has to
> > happen 
> > > is for CAs to stop populating the crossCertificate pair. Is that
> > correct?
> > > 
> > > On the other hand, does this give rise to a worst of both worlds
> > case
> > > from the perspective of the client software complexity?
> > > 
> > > Bob
> > > 
> 

From: Eric Rosenquist <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 14:42:00 -0400 
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_01BDD6A1.5ED91770
Content-Type: text/plain

------ =_NextPart_001_01BDD6A1.5ED91770
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.1960.3">
<TITLE>For Option 2</TITLE>
</HEAD>
<BODY>
<BR>

</BODY>
</HTML>
------ =_NextPart_001_01BDD6A1.5ED91770--

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 14:17:18 -0400
Sender: [email-masked]

Hi Sharon and Stefan:

While option 1 does not mandate it, it does not prohibit a CA from
populating all the certificates it has issued to other CAs (inter as
well as intra domain) in the reverse attribute of the cross certificate
pair.

The fundamental difference between the two options is that under option
1 certificates are not duplicated in a CA's entry.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Wednesday, September 02, 1998 8:46 AM
> To:	[email-masked]; [email-masked]; 'Bob Jueneman'
> Subject:	RE: Straw Poll cACertificate &
> crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> 
> Hi Bob,
> 
> I don't think we'll every get to a point where people stop populating
> the
> crossCertificatePair attribute, regardless of the result of the straw
> poll.
> The forward/reverse elements in the syntax of this attribute are very
> useful
> since not all path discovery algorithms are identical. Path discovery
> can be
> done many ways including beginning from the subject and moving toward
> a
> trust anchor, beginning from a trust anchor and moving toward a
> subject,
> beginning at both ends etc etc.   Being able to retrieve both forward
> and
> reverse certificates from a single entry rather than checking the
> directory
> entries of two CAs is a useful feature for some algorithms. 
> ------------------
> Sharon Boeyen                  
> Entrust Technologies
> 
> mailto:[email-masked]  Tel: (613) 247-3181 
> http://www.entrust.com            Fax: (613) 247-3690 
>        
> 
> 
> > ----------
> > From: 	Bob Jueneman[SMTP:[email-masked]]
> > Sent: 	September 1, 1998 7:20 PM
> > To: 	[email-masked]; [email-masked]; [email-masked]
> > Subject: 	Re: Straw Poll cACertificate &
> > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > 
> > I'm still on the fence, and trying to decide between the two
> options.
> > 
> > But why is a binary decision necessary?
> > 
> > If I understand Tim's points, option 2 is a superset of option 1, 
> > and a significant number of clients only support option 2.
> > 
> > Option 1, however, is at least arguably superior from a network and
> > directory performance standpoint, although I am still very confused 
> > about exactly who defines a "domain" and how the relying party is
> > supposed to intuit what "local choice" some CA made.
> > 
> > Would a viable compromise position be to support option 2 as the
> initial
> > direction, and to transition to option 1 at some later point in
> time, say 
> > 36 months from now, assuming further work clearly establishes that 
> > option 1 is completely workable?
> > 
> > My directory guys assure me that the directory is effectively
> neutral in
> > this,
> > except for the possible performance issues.  So all that has to
> happen 
> > is for CAs to stop populating the crossCertificate pair. Is that
> correct?
> > 
> > On the other hand, does this give rise to a worst of both worlds
> case
> > from the perspective of the client software complexity?
> > 
> > Bob
> > 

From: Peter Brundrett <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 11:01:16 -0700 
Sender: [email-masked]

From: Peter Yeatrakas <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:34:55 -0700 
Sender: [email-masked]

Date: Wed, 2 Sep 1998 13:20:42 -0400 (EDT)
From: Karen Oostendorp <[email-masked]>
To: [email-masked]
cc: Chris Vance <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

From: Peter Hesse <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:11:54 -0400
Sender: [email-masked]

----------------------------------------------------------------
Peter M. Hesse           [email-masked]   
CygnaCom Solutions, Inc. (703)848-0883(voice) (703)848-0960(fax)
Visit the CygnaCom Solutions Web Site:  http://www.cygnacom.com
Page me instantly! http://wwp.mirabilis.com/1942828#pager

Date: Wed, 02 Sep 1998 10:08:25 -0700
To: [email-masked]
From: Joe Tardo <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

From: Bruce Greenblatt <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:07:04 -0700 
Sender: [email-masked]

Note new phone number below |
                            v
----------------------------------------------------
Bruce Greenblatt      
[email-masked]   Personal: [email-masked]
(650) 295-7569        http://www.innetix.com/~bruceg
----------------------------------------------------

From: [email-masked]
Date: Wed, 2 Sep 1998 12:52:48 EDT
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

I vote for Option 1.

EAL

Date: Wed, 02 Sep 1998 11:10:19 -0500
From: "Dale Gustafson" <[email-masked]>
Organization: Datakey, Inc.
To: PKIX Working Group <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 11:06:52 +0000
From: susanmaloney <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Extension of straw poll
Date: Wed, 2 Sep 1998 16:40:06 +0100
Sender: [email-masked]

I've just been speaking with one of the PKIX co-chairs and as a result
of that conversation, we're extending the deadline on the straw poll
regarding the use of cACertificate and crossCertificatePair attributes
to be more in line with the length of time usually afforded straw polls
in IETF.  My reason for pushing a short timeframe was in anticipation of
a PKIX resolution which could then be submitted to the X.509 group next
week for consideration in their discussion of the related defect report.
If the straw poll ends on Wednesday, and if a PKIX resolution is
finalized quickly, we can probably still meet that timeframe. 

Votes can now be submitted up until COB on Wednesday September 9th.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

From: Ivan Milman <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 11:36:41 -0400
Sender: [email-masked]

Thanks,
Ivan

Ivan M. Milman
IBM/Austin
Distributed System Services
Email:  [email-masked]        Phone:
1-512-838-8152                                       Fax:
1-512-838-8597                      T/L:  678-8152

Date: Wed, 02 Sep 1998 11:02:48 -0400
From: Tom Horvath <[email-masked]>
Organization: Smart Link Office
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

Date: Wed, 2 Sep 1998 11:05:12 -0400
To: [email-masked]
From: David Dalkowski <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

Date: Wed, 02 Sep 1998 11:00:48 -0400
From: "Hirsch Matthew" <[email-masked]>
Organization: BAH
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: "Bill Lenz" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 10:50:09 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0081_01BDD65F.74558200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0081_01BDD65F.74558200
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.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0081_01BDD65F.74558200--

From: "Pawluk, Jean" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 07:48:14 -0700 
Sender: [email-masked]

From: Bruce Bell <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: for option 1
Date: Wed, 2 Sep 1998 07:41:24 -0700 
Sender: [email-masked]

Bruce S. Bell
Compliance Officer
phone 510-568-0276 ext.361
fax      510-568-0195

From: "Nora Kraemer" <[email-masked]>
To: <[email-masked]>
Subject: Option 1
Date: Wed, 2 Sep 1998 09:48:46 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00BE_01BDD656.E0E3D100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Nora Kraemer=20
Chromatix
10451 Twin Rivers Road, #265
Columbia, MD  21044
Phone:  301-596-8466
Fax:       410-997-4306
[email-masked]
http://www.chromatix.com

------=_NextPart_000_00BE_01BDD656.E0E3D100
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.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Nora Kraemer </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Chromatix<BR>10451 Twin Rivers Road, =

#265<BR>Columbia, MD&nbsp; 21044<BR>Phone:&nbsp;=20
301-596-8466<BR>Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
410-997-4306<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A>=
<BR><A=20
href=3D"http://www.chromatix.com">http://www.chromatix.com</A></FONT></DI=
V></BODY></HTML>

------=_NextPart_000_00BE_01BDD656.E0E3D100--

Date: Wed, 2 Sep 1998 09:47:04 -0400 (EDT)
From: Serge Mister <[email-masked]>
Reply-To: Serge Mister <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 09:38:22 -0400
From: David Berstein <[email-masked]>
Organization: Chromatix
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

--
      _/_/_/         David M. Berstein
   _/      _/
  _/                 Chromatix, Inc.
 _/           _/  _/ 10451 Twin Rivers Road, Suite 265
_/            _/_/   Columbia, MD 21044
 _/     _/   _/_/    Phone:  (301) 596-8466 | http://www.chromatix.com
  _/_/_/   _/   _/   Fax:    (410) 997-4306 | [email-masked]

Date: Wed, 2 Sep 1998 09:36:05 -0400 (EDT)
From: Chris Vance <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 08:46:34 -0400 
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

From: Sharon Boeyen <[email-masked]>
To: [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 08:45:32 -0400 
Sender: [email-masked]

Hi Bob,

I don't think we'll every get to a point where people stop populating the
crossCertificatePair attribute, regardless of the result of the straw poll.
The forward/reverse elements in the syntax of this attribute are very useful
since not all path discovery algorithms are identical. Path discovery can be
done many ways including beginning from the subject and moving toward a
trust anchor, beginning from a trust anchor and moving toward a subject,
beginning at both ends etc etc.   Being able to retrieve both forward and
reverse certificates from a single entry rather than checking the directory
entries of two CAs is a useful feature for some algorithms. 
------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	September 1, 1998 7:20 PM
> To: 	[email-masked]; [email-masked]; [email-masked]
> Subject: 	Re: Straw Poll cACertificate &
> crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> 
> I'm still on the fence, and trying to decide between the two options.
> 
> But why is a binary decision necessary?
> 
> If I understand Tim's points, option 2 is a superset of option 1, 
> and a significant number of clients only support option 2.
> 
> Option 1, however, is at least arguably superior from a network and
> directory performance standpoint, although I am still very confused 
> about exactly who defines a "domain" and how the relying party is
> supposed to intuit what "local choice" some CA made.
> 
> Would a viable compromise position be to support option 2 as the initial
> direction, and to transition to option 1 at some later point in time, say 
> 36 months from now, assuming further work clearly establishes that 
> option 1 is completely workable?
> 
> My directory guys assure me that the directory is effectively neutral in
> this,
> except for the possible performance issues.  So all that has to happen 
> is for CAs to stop populating the crossCertificate pair. Is that correct?
> 
> On the other hand, does this give rise to a worst of both worlds case
> from the perspective of the client software complexity?
> 
> Bob
> 

Date: Wed, 02 Sep 1998 08:37:49 -0400
To: [email-masked]
From: [email-masked] (Ella P. Gardner)
Subject: For Option 1
Sender: [email-masked]

Ella P. Gardner	               phone: +1 703 883 5826
The MITRE Corporation	         fax    +1 703 883 7142
1820 Dolley Madison Boulevard	   email: [email-masked]
McLean, VA 22102-3481

Date: Wed, 02 Sep 1998 08:34:05 -0400
From: "Saylor, John" <[email-masked]>
Subject: For Option 2
To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

\js

Date: Wed, 02 Sep 1998 08:01:58 -0400
From: John Garner <[email-masked]>
To: "IETF X.509 PKI" <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

--------------06CB147F224BAAC5EA029C20
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--

======================================================================
      //_/_/               John R. Garner
   _/      _/
  _/       _/              Chromatix, Inc.
 _/           _/  _/       10451 Twin Rivers Road, Suite 265
_/            _/_/         Columbia, MD 21044
 _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  [email-masked]

--------------06CB147F224BAAC5EA029C20
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
&nbsp;
<PRE>--&nbsp;

======================================================================
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //_/_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; John R. Garner
&nbsp;&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chromatix, Inc.&nbsp;
&nbsp;_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10451 Twin Rivers Road, Suite 265
_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Columbia, MD 21044
&nbsp;_/&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp;&nbsp; _/_/&nbsp; Phone:&nbsp; (301) 596-8466&nbsp; |&nbsp; <A HREF="http://www.chromatix.com">http://www.chromatix.com</A>
&nbsp; _/_/_/&nbsp;&nbsp; _/&nbsp;&nbsp; _/ Fax:&nbsp;&nbsp;&nbsp; (410) 997-4306&nbsp; |&nbsp; [email-masked]</PRE>
&nbsp;</HTML>

--------------06CB147F224BAAC5EA029C20--

Date: Wed, 02 Sep 1998 07:36:15 -0400
To: [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: for option 1
Sender: [email-masked]

From: Mark C Davis <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 07:29:13 -0400
Sender: [email-masked]

______________________________________________________________
Mark C Davis/Raleigh/IBM, DSS Network Security, [email-masked]
(919)254-7876, pager 1(800)946-4646 PIN 6066244,  FAX (919)254-5710

Date: Wed, 02 Sep 1998 13:10:19 +0200
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[email-masked]>
Sender: [email-masked]

At 11:35 AM 9/1/98 -0600, Bob Jueneman wrote:
<snip>
>>>Equally clearly, the use of both the DS and the NR bit _is_ allowed.
>>
>>YES!! If I could, I would require the DS bit to be set anytime the NR was
set.
>
>I'm not strongly opposed to that, and in fact that was my position prior
to realizing 
>that NR plus encryption could be used to indicate that no escrow was
taking place.
>If the DS bit would always be set, as opposed to using NR by itself, it
would be
>a few nanoseconds faster.

<snip>
>I'll grant that by suggesting that NR might apply to encryption, I am
stretching the 
>popular concept a bit, and effectively redefining the key usage to mean
"exclusive
>control of the private key by the names user".  But isn't that effectively
what we have 
>been saying?

I suggest that we stick to the standardized definitions of the key usage
bits and leave
policy issues out of a common certificate profile.

non-repudiation is according to standard selected by the NR bit, not NR in
combination with DS bit. Inclusion of the DS bit means that DS mechanisms
other than non-repudiation are allowed for the key.

Restrictions regarding combinations of key usages are policy issues.
Whether a particular key usage combination is good or bad has to be decided
through the perspective of a community with common security requirements.

Non-repudiation is defined to be (according to X.509):
  non-repudiation - This service provides proof of the integrity and 
  origin of data - both in an unforgeable relationship - which can be 
  verified by any third party at any time.

Key escrow is not defined by non-repudiation so I would not use the NR bit
as a "no-recovery" declaration.

/Stefan

From: [email-masked]
To: [email-masked]
Date: Wed, 2 Sep 1998 07:01:37 -0400
Subject: For Option 2
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [email-masked]
Precedence: bulk

Date: Wed, 02 Sep 1998 06:51:36 -0400
From: Jesse Walker <[email-masked]>
Organization: Shiva Corporation
To: [email-masked]
Subject: For option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 12:08:11 +0200
To: Santosh Chokhani <[email-masked]>, Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[email-masked]>
Sender: [email-masked]

I just feel uncomfortable with a situation where the CA is NOT allowed
to store some of it's issued CA certificates in its directory (OPTION 1).

If nothing less, storage of these certificates may be used for cashing
to enhance path construction (less directory look ups in new paths).

Since OPTION2 closes less doors and obviously supports a wider range
of local path algorithms, OPTION 2 seems to be the natural choice.

I agree with Carlislie and Tim that since OPTION 1 only is a subset of 
OPTION 2 and OPTION 2 offer full interoperability, that OPTION 2 should 
be selected even if only a minority declare a need for it. 

/Stefan

At 05:56 PM 9/1/98 -0400, Santosh Chokhani wrote:
>They are stored in caCertificate attribute of directory entry
>representing the subject (subscriber) CA.
>
>> -----Original Message-----
>> From:	Stefan Santesson [SMTP:[email-masked]]
>> Sent:	Tuesday, September 01, 1998 3:54 PM
>> To:	Sharon Boeyen; [email-masked]'
>> Cc:	'Santosh Chokhani'
>> Subject:	Re: Straw Poll cACertificate & crossCertificatePair
>> attributes - PKIX LDAPv2 schema I-D
>> 
>> I don't get this.
>> 
>> In OPTION 1, where do I store certificates issued by this CA to CA:s 
>> in the same domain????
>> 
>> It seems to be missing.
>> 
>> /Stefan
>> 
>> 

Date: Wed, 02 Sep 1998 12:08:12 +0200
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 10:39:52 +0200
To: [email-masked]
From: Martin =?iso-8859-1?Q?Lindström?= <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

 ______________________________________
|________ Entegrity Solutions _________|
|                                      |
| Martin Lindström, Systems Engineer   |
|                                      |                                    
| Finlandsgatan 60                     |
| S-164 74 Kista, Sweden               |
| Direct: +46-(0)8-477-7735            |
| Fax:    +46-(0)8-477-7731            |
| Cell:   +46-(0)70-483-0024           |
|______________________________________|

Date: Wed, 02 Sep 1998 10:19:46 +0200
To: [email-masked]
From: Thomas Caldenius <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

From: "Andrey Lopatenko" <[email-masked]>
To: <[email-masked]>
Subject: Option 2
Date: Wed, 2 Sep 1998 12:22:54 +0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0052_01BDD66C.68EE6D70
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0052_01BDD66C.68EE6D70
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Dkoi8-r http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0052_01BDD66C.68EE6D70--

Date: Wed, 02 Sep 1998 10:14:29 +0200
To: [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 09:38:55 +0400 (MSK DST)
From: Pavel Krylov <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: [email-masked]
Date: Tue, 1 Sep 1998 21:14:44 -0700
To: [email-masked]
Subject: option 2
Sender: [email-masked]

From: "Yuriy Dzambasow" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 22:44:42 -0400
Importance: Normal
Sender: [email-masked]

Date: Tue, 01 Sep 1998 17:20:10 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX LDAPv2 schema I-D
Sender: [email-masked]

I'm still on the fence, and trying to decide between the two options.

But why is a binary decision necessary?

If I understand Tim's points, option 2 is a superset of option 1, 
and a significant number of clients only support option 2.

Option 1, however, is at least arguably superior from a network and
directory performance standpoint, although I am still very confused 
about exactly who defines a "domain" and how the relying party is
supposed to intuit what "local choice" some CA made.

Would a viable compromise position be to support option 2 as the initial
direction, and to transition to option 1 at some later point in time, say 
36 months from now, assuming further work clearly establishes that 
option 1 is completely workable?

My directory guys assure me that the directory is effectively neutral in this,
except for the possible performance issues.  So all that has to happen 
is for CAs to stop populating the crossCertificate pair. Is that correct?

On the other hand, does this give rise to a worst of both worlds case
from the perspective of the client software complexity?

Bob

Date: Tue, 01 Sep 1998 09:01:49 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: For  Option 2
Sender: [email-masked]

--Paul Hoffman, Director
--Internet Mail Consortium

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:02:05 -0700 
Sender: [email-masked]

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 18:00:13 -0400
Sender: [email-masked]

For option 1

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
[email-masked]
http://www.cygnacom.com

From: [email-masked] (Mike Just)
Date: Tue, 1 Sep 1998 17:59:54 -0400
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: Santosh Chokhani <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Santosh Chokhani'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 17:56:27 -0400
Sender: [email-masked]

They are stored in caCertificate attribute of directory entry
representing the subject (subscriber) CA.

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[email-masked]]
> Sent:	Tuesday, September 01, 1998 3:54 PM
> To:	Sharon Boeyen; [email-masked]'
> Cc:	'Santosh Chokhani'
> Subject:	Re: Straw Poll cACertificate & crossCertificatePair
> attributes - PKIX LDAPv2 schema I-D
> 
> I don't get this.
> 
> In OPTION 1, where do I store certificates issued by this CA to CA:s 
> in the same domain????
> 
> It seems to be missing.
> 
> /Stefan
> 
> 
> At 11:10 AM 9/1/98 -0400, Sharon Boeyen wrote:
> >
> >Folks 
> >
> >This is a straw poll on the use of the cACertificate and
> >crossCertificatePair attributes in the PKIX LDAP schema draft. There
> are 2
> >options, each of which received sufficient support during the Chicago
> >meeting to require this straw poll to resolve the issue. Below is the
> >specific text proposed for each option, followed by a summary of the
> >rationale behind each of the proposals. The specific text for the
> proposals
> >and rationale summaries have been cooperatively drafted by Santosh
> Chokhani,
> >Dave Horvath and myself.
> >
> >Votes must be in by COB on Thursday Sept 3.  This is the only
> outstanding
> >issue on this I-D following the 2 week last call so we should be able
> to
> >progress both the PKIX LDAPv2 protocol profile and PKIX LDAPv2 schema
> >following this poll.
> >. 
> >To vote, send an email to [email-masked] with one of the following
> >subject lines: 
> >
> >To vote for option 1put "For Option 1" in the subject line. 
> >To vote for option 2 put "For Option 2" in the subject line.	 
> >
> >As with the earlier polls conducted by Tim Polk on Part 1, don't
> bother with
> >a message body, I am just going to count the messages.  Discussion of
> the
> >content of this message should reply to this message.
> >
> >
> >PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
> >OPTION 1:
> >----------------
> >The cACertificate attribute, held in a particular CA's directory
> entry,
> >shall be used to store certificates issued to this CA by CAs in the
> same
> >domain as this CA. In addition, the cACertificate attribute shall be
> used to
> >store self-issued certificates.
> >
> >The forward element of the crossCertificatePair attribute, held in a
> >particular CA's directory entry, shall be used to store certificates
> issued
> >to this CA by CAs in other domains.  Optionally, the reverse element
> of the
> >crossCertificatePair attribute, held in a particular CA's directory
> entry,
> >may contain certificates issued by this CA to CAs in other domains.
> >
> >In the case of V3 certificates, none of the above CA certificates may
> >include a basicConstraints extension with the cA value set to FALSE.
> >
> >The definition of domain is purely a matter of local policy.
> >
> >OPTION 2:
> >-------------
> >The crossCertificatePair attribute, held in a particular CA's
> directory
> >entry, shall be used to store all certificates issued by this CA to
> other
> >CAs, as well as certificates issued for this CA by other CAs. Values
> held in
> >the forward element are certificates issued for this CA by other CAs,
> while
> >values in the reverse element are certificates issued by this CA for
> other
> >CAs. 
> >
> >The cACertificate attribute, held in a particular CA's directory
> entry,
> >shall be used to store certificates issued to this CA by CAs in the
> same
> >domain as this CA. This set of certificates is a subset of the values
> of the
> >forward element of the crossCertificatePair attribute in the same CA
> entry.
> >In addition, the cACertificate attribute shall beused to store
> self-issued
> >certificates.  
> >
> >The definition of domain is purely a matter of local policy.
> >
> >In the case of version 3 certificates, none of the above CA
> certificates may
> >include a basicConstraints extension with the cA value set to FALSE.
> >
> >SUMMARY OF RATIONALE FOR EACH OF THE OPTIONS:
> >--------------------------------------------------------------------
> >
> >RATIONALE FOR PROPOSING OPTION 1:
> >--------------------------------------------------
> >The major advantage of this approach is that it minimizes the amount
> of data
> >retrieved from the directory.  The approach improves the relying
> party
> >response time and minimizes network utilization.
> >
> >Another advantage of this approach over the alternative is that it
> does not
> >require the relying parties to separate the certificates stored in
> >caCertificate attribute from those stored in the crossCertificatePair
> >attribute.  The clients may need to do this during path construction.
> >
> >Storing all the certificates in the crossCertificatePair attribute
> and also
> >storing some of the certificates in the caCertificate attribute, as
> >described in the alternative, unnecessarily increases the number of
> >certificates retrieved.  The alternative will result in poorer
> relying party
> >response time and use network bandwidth unnecessarily.  The
> alternative will
> >be particularly inefficient when a relying party is located remotely
> from
> >the repository/directory.
> >
> >A minor disadvantage of the alternative is that it requires the same
> >information object (certificate) to be stored twice in a repository,
> once in
> >the caCertificate attribute and once in the crossCertificatePair
> attribute.
> >This increases he storage requirement on the directory.
> >
> >
> >RATIONALE FOR PROPOSING OPTION 2:
> >------------------------------------------------------------
> >
> >Path development is a relying party process and the criteria for
> selection
> >of a 'preferred' set of certificates to enable efficiencies in that
> process
> >can vary according to the path discovery algorithm as well as from
> one
> >relying party to another, from one application to another, and on
> other
> >criteria as well. While a CA should optionally be able to provide
> helpful
> >hints to relying parties regarding the set of certificates the CA
> expects to
> >provide efficiencies, these may or may not match the requirements of
> a
> >relying party path discovery process. Relying parties will access CA
> >directory entries frequently to retrieve certificates as input to a
> >certification path development process and they should not be forced
> to know
> >whether or not a CA has published a set of  its 'preferred'
> certificates,
> >nor should relying parties be required to take on the extra burden of
> having
> >to request filtering of multiple directory attributes to retrieve the
> set of
> >certificates which is preferred in their particular environment,
> especially
> >given that relying parties will often need this information from CAs
> outside
> >their own local Intranet. 
> >
> >CAs should be given the option to publish a set of 'preferred'
> certificates
> >but should not be required to do so. Should a CA elect to publish
> such a
> >set, the criteria used by that CA to determine the bases of the
> preference
> >should be left to the discretion of each CA or each security domain.
> The
> >preference should not be necessarily tied to a predetermined
> universal
> >criterion such as a single PKI or 'internal domain', especially given
> that a
> >CA may be issued a certificate by any number of other CAs and may
> therefore
> >subscribe to many PKIs.
> >
> >
> >------------------
> >Sharon Boeyen                  
> >Entrust Technologies
> >
> >mailto:[email-masked]  Tel: (613) 247-3181 
> >http://www.entrust.com            Fax: (613) 247-3690 
> >       
> >
> >
> >

Date: Tue, 01 Sep 1998 14:50:18 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 01 Sep 1998 17:41:41 -0400
From: Sean Mullan <[email-masked]>
Organization: Sun Microsystems
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 01 Sep 1998 18:32:48 -0300
From: Eduardo Rosemberg de Moura <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

-- 
Eduardo Rosemberg de Moura
mailto:[email-masked] ([email-masked])
Phone: +55 21 521-0120 (voice)
       +55 21 523-4499 (fax)
Mobile:+55 21 9985-7934
ICQ:   6365858

From: Brian LaMacchia <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:21:30 -0700 
Sender: [email-masked]

From: "Adkins, Sherrill" <[email-masked]>
To: [email-masked]
Subject: For Option 1
Date: Tue, 1 Sep 1998 20:55:47 -0000 
Importance: low
Sender: [email-masked]

From: Barb Fox <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: for Option 1
Date: Tue, 1 Sep 1998 13:54:51 -0700 
Sender: [email-masked]

Date: Tue, 01 Sep 1998 16:53:40 -0400
From: Greg Byrd <[email-masked]>
Organization: SECANT Network Technologies
To: [email-masked]
Subject: for option 2
Sender: [email-masked]

-- 
Greg Byrd                          [email-masked]
SECANT Network Technologies, Inc.  919-462-1900 x229
P.O. Box 14285                     919-462-1933 (fax)
Research Triangle Park, NC 27709

Date: Tue, 01 Sep 1998 14:31:19 -0600
From: "Russel F. Weiser" <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------C201775B051242826227D678
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------C201775B051242826227D678
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Russel Weiser
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Russel Weiser
n:              Weiser;Russel
org:            DST
email;internet: [email-masked]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------C201775B051242826227D678--

Date: Tue, 01 Sep 1998 21:53:35 +0200
To: Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[email-masked]>
Sender: [email-masked]

I don't get this.

In OPTION 1, where do I store certificates issued by this CA to CA:s 
in the same domain????

It seems to be missing.

/Stefan

At 11:10 AM 9/1/98 -0400, Sharon Boeyen wrote:
>
>Folks 
>
>This is a straw poll on the use of the cACertificate and
>crossCertificatePair attributes in the PKIX LDAP schema draft. There are 2
>options, each of which received sufficient support during the Chicago
>meeting to require this straw poll to resolve the issue. Below is the
>specific text proposed for each option, followed by a summary of the
>rationale behind each of the proposals. The specific text for the proposals
>and rationale summaries have been cooperatively drafted by Santosh Chokhani,
>Dave Horvath and myself.
>
>Votes must be in by COB on Thursday Sept 3.  This is the only outstanding
>issue on this I-D following the 2 week last call so we should be able to
>progress both the PKIX LDAPv2 protocol profile and PKIX LDAPv2 schema
>following this poll.
>. 
>To vote, send an email to [email-masked] with one of the following
>subject lines: 
>
>To vote for option 1put "For Option 1" in the subject line. 
>To vote for option 2 put "For Option 2" in the subject line.	 
>
>As with the earlier polls conducted by Tim Polk on Part 1, don't bother with
>a message body, I am just going to count the messages.  Discussion of the
>content of this message should reply to this message.
>
>
>PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
>OPTION 1:
>----------------
>The cACertificate attribute, held in a particular CA's directory entry,
>shall be used to store certificates issued to this CA by CAs in the same
>domain as this CA. In addition, the cACertificate attribute shall be used to
>store self-issued certificates.
>
>The forward element of the crossCertificatePair attribute, held in a
>particular CA's directory entry, shall be used to store certificates issued
>to this CA by CAs in other domains.  Optionally, the reverse element of the
>crossCertificatePair attribute, held in a particular CA's directory entry,
>may contain certificates issued by this CA to CAs in other domains.
>
>In the case of V3 certificates, none of the above CA certificates may
>include a basicConstraints extension with the cA value set to FALSE.
>
>The definition of domain is purely a matter of local policy.
>
>OPTION 2:
>-------------
>The crossCertificatePair attribute, held in a particular CA's directory
>entry, shall be used to store all certificates issued by this CA to other
>CAs, as well as certificates issued for this CA by other CAs. Values held in
>the forward element are certificates issued for this CA by other CAs, while
>values in the reverse element are certificates issued by this CA for other
>CAs. 
>
>The cACertificate attribute, held in a particular CA's directory entry,
>shall be used to store certificates issued to this CA by CAs in the same
>domain as this CA. This set of certificates is a subset of the values of the
>forward element of the crossCertificatePair attribute in the same CA entry.
>In addition, the cACertificate attribute shall beused to store self-issued
>certificates.  
>
>The definition of domain is purely a matter of local policy.
>
>In the case of version 3 certificates, none of the above CA certificates may
>include a basicConstraints extension with the cA value set to FALSE.
>
>SUMMARY OF RATIONALE FOR EACH OF THE OPTIONS:
>--------------------------------------------------------------------
>
>RATIONALE FOR PROPOSING OPTION 1:
>--------------------------------------------------
>The major advantage of this approach is that it minimizes the amount of data
>retrieved from the directory.  The approach improves the relying party
>response time and minimizes network utilization.
>
>Another advantage of this approach over the alternative is that it does not
>require the relying parties to separate the certificates stored in
>caCertificate attribute from those stored in the crossCertificatePair
>attribute.  The clients may need to do this during path construction.
>
>Storing all the certificates in the crossCertificatePair attribute and also
>storing some of the certificates in the caCertificate attribute, as
>described in the alternative, unnecessarily increases the number of
>certificates retrieved.  The alternative will result in poorer relying party
>response time and use network bandwidth unnecessarily.  The alternative will
>be particularly inefficient when a relying party is located remotely from
>the repository/directory.
>
>A minor disadvantage of the alternative is that it requires the same
>information object (certificate) to be stored twice in a repository, once in
>the caCertificate attribute and once in the crossCertificatePair attribute.
>This increases he storage requirement on the directory.
>
>
>RATIONALE FOR PROPOSING OPTION 2:
>------------------------------------------------------------
>
>Path development is a relying party process and the criteria for selection
>of a 'preferred' set of certificates to enable efficiencies in that process
>can vary according to the path discovery algorithm as well as from one
>relying party to another, from one application to another, and on other
>criteria as well. While a CA should optionally be able to provide helpful
>hints to relying parties regarding the set of certificates the CA expects to
>provide efficiencies, these may or may not match the requirements of a
>relying party path discovery process. Relying parties will access CA
>directory entries frequently to retrieve certificates as input to a
>certification path development process and they should not be forced to know
>whether or not a CA has published a set of  its 'preferred' certificates,
>nor should relying parties be required to take on the extra burden of having
>to request filtering of multiple directory attributes to retrieve the set of
>certificates which is preferred in their particular environment, especially
>given that relying parties will often need this information from CAs outside
>their own local Intranet. 
>
>CAs should be given the option to publish a set of 'preferred' certificates
>but should not be required to do so. Should a CA elect to publish such a
>set, the criteria used by that CA to determine the bases of the preference
>should be left to the discretion of each CA or each security domain. The
>preference should not be necessarily tied to a predetermined universal
>criterion such as a single PKI or 'internal domain', especially given that a
>CA may be issued a certificate by any number of other CAs and may therefore
>subscribe to many PKIs.
>
>
>------------------
>Sharon Boeyen                  
>Entrust Technologies
>
>mailto:[email-masked]  Tel: (613) 247-3181 
>http://www.entrust.com            Fax: (613) 247-3690 
>       
>
>
>

From: "Fabio Omenigrandi" <[email-masked]>
To: [email-masked]
Date: Tue, 1 Sep 1998 21:32:35 +0200
Subject: For Option 1
Sender: [email-masked]

From: Ron Chittaro <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:35:44 -0400 
Sender: [email-masked]

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Tim Polk'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 15:06:36 -0400 
Sender: [email-masked]

Hi,

Here's my two cents (which, at the current exchange rate, is worth
considerably less than Tim's two cents...).

> ----------
> From: 	Tim Polk[SMTP:[email-masked]]
> Sent: 	Tuesday, September 01, 1998 1:39 PM
> To: 	[email-masked]'
> Subject: 	Re: Straw Poll cACertificate & crossCertificatePair
> attributes - PKIX LDAPv2 schema I-D
> 
> In case anyone is interested, here's my two cents worth...
> 
...

> I prefer option #2, but for rather pragmatic reasons.  There are two large
> pools of PKI clients.  These two groups were designed independently, and
> the implementers made different assumptions.  If we choose option #1, we
> break one group of clients. HOWEVER, if we choose option #2, both sets of
> clients will work - and will be interoperable!
> 
> Since a technically viable solution exists that doesn't break any existing
> clients and actually makes them interoperable, that is my preference.
> 
This sort of reasoning (*especially* within the IETF community) seems
sufficiently strong that I wonder why in the world we need a straw poll at
all.  It meets every conceivable definition of "rough consensus and running
code" and "interoperability above non-interoperability", which are the two
golden rules of this community.  Within an *IETF* Working Group, is there
any defensible basis for choosing another option that does not have these
properties?

Carlisle.

P.S., Bob, I share your concern for the definition of a domain being left up
to "local policy".  What exactly is the definition of "local"?  Does this
mean local to the CA whose entry we're considering?  If so, then if I am
certified by another CA, how do I know whether or not I'm in that first CA's
"domain" (i.e., how do I know what it "locally" defined its domain to be)?
Therefore, how do I know whether or not to look in the caCertificate
attribute?

Again, it seems to me that option 2 nicely (and completely) solves this
problem:  if I somehow (magically) know that I'm in that CA's domain, then I
can retrieve certificates from the caCertificate attribute; otherwise, I can
retrieve certificates from the crossCertificatePair attribute.  Both methods
are guaranteed to work.  Option 1, on the other hand, works on the
underlying assumption that everybody knows (a priori) what domain they're
in.  Given that there is no universal definition for "domain" (i.e., that it
is only defined "locally"), it is not at all obvious how to ensure this.

From: Carlisle Adams <[email-masked]>
To: [email-masked]
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:07:25 -0400 
Sender: [email-masked]

Date: Tue, 01 Sep 1998 15:07:07 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

From: MHenry <[email-masked]>
To: [email-masked]
Subject: for option 2
Date: Tue, 1 Sep 1998 15:05:25 -0400 
Sender: [email-masked]

From: "Fillingham,  David W." <[email-masked]>
To: "'IETF/PKIX'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:01:50 -0400
Sender: [email-masked]

Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 2
From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Sep 1998 19:52:09 +0100
Sender: [email-masked]

Date: Tue, 01 Sep 1998 14:43:28 -0400
From: Michael Maloney <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------10B5479D1700C8A1FFAC998E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------10B5479D1700C8A1FFAC998E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Mike Maloney
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Mike Maloney
n:              Maloney;Mike
org:            Chromatix, Inc
adr:            10451 Twin Rivers Road;;Suite 265;Columbia;MD;21044;USA
email;internet: [email-masked]
title:          Senior Engineer
tel;work:       301 596-8466
tel;fax:        410 997-4306
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------10B5479D1700C8A1FFAC998E--

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 14:33:05 -0400 
Sender: [email-masked]

From: "Rogers III, Edward B." <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:26:56 -0400 
Importance: low
Sender: [email-masked]

R/ Ed
Technical Lead, DMS Security Evolution
Lockheed Martin Federal Systems

From: "Steven (Pete) Peterson" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:12:22 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_017F_01BDD5B2.89B86520
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_017F_01BDD5B2.89B86520
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.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_017F_01BDD5B2.89B86520--

Date: Tue, 01 Sep 1998 14:12:56 -0400
From: Thomas Llanso <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

--

      _/_/_/                   Thomas H. Llanso
   _/      _/
  _/       _/                  Chromatix, Inc.
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/      Phone:  (301) 596-8466  |
http://www.chromatix.com
 _/_/_/   _/   _/      Fax:    (410) 997-4306  |
[email-masked]

Date: Tue, 01 Sep 1998 14:06:38 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Larry Layten <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 12:58:05 -0500
Sender: [email-masked]

Date: Tue, 01 Sep 1998 11:51:01 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes- PKIX LDAPv2 schema I-D
Sender: [email-masked]

I am inclined to support option 1, because it seems simpler..

However, I am concerned that the definition of the domain is left up to local
policy.

If "domain " referred to the chain of certificates that could be validated by 
climbing the subject to issuer chain within the certificates, I think it would
be much cleaner.

As it stands, I'm not quite sure that I understand how to construct a path search
algorithm in either of the two proposals, so I guess I need to stare at it harder.

I understand Tim's pragmatic argument, but I'm not convinced that the number of 
applications actually using LDAP to retrieve certificates is so large that this is an
overwhelming reason to go one way or the other.  In absolute numbers, what 
are we talking about?

Bob

>>> Tim Polk <[email-masked]> 09/01 11:39 AM >>>

In case anyone is interested, here's my two cents worth...

The LDAP straw poll message concentrates on the technical rationale behind
each of the two options.  In fact, each is a technically sound proposal.
Option #1 is more elegant since there is no redundant data.  Option #2 is a
little more flexible, but clients may incur a performance hit when building
infrequently used paths.  IMHO, it's a wash.

I prefer option #2, but for rather pragmatic reasons.  There are two large
pools of PKI clients.  These two groups were designed independently, and
the implementers made different assumptions.  If we choose option #1, we
break one group of clients. HOWEVER, if we choose option #2, both sets of
clients will work - and will be interoperable!

Since a technically viable solution exists that doesn't break any existing
clients and actually makes them interoperable, that is my preference.

Date: Tue, 1 Sep 1998 13:51:23 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 01 Sep 1998 11:35:15 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Sender: [email-masked]

Hi, Aram,

I'll try to respond to some of your points to clarify what I meant, 
although in some cases I suspect we may agree to disagree.

>>I believe that we can agree on at least two things:

Maybe not!
>>
>>1.  The Digital Signature key usage is an important indicator in those 
>>environments where key strength may be limited and/or key escrow
>>required, _except_ for keys whose usage can be proven to be restricted
>>to benign applications, e.g., digital signatures.  (Actually proving that
>>to the satisfaction of the export/import/use authorities isn't all that easy,
>>especially in a general-purpose API environment, but the PKIX group
>>doesn't need to concern themselves with those kinds of details.)
>
>I do not think that key usage should be tied to any key strength and/or key
>escrow requirements. There are many valid *security* reasons to limit how a key
>is used.

I certainly agree with your second sentence, and am not trying to tie key usage to
key strength and/or key escrow requirements.

But for those of us who are delivering software to international markets, notably 
including France, Russia, Singapore, and some other countries, key escrow is 
a fact of life that is quite independent of what you or I, or for that matter what the
US Government thinks of it.

It's true that the originator is primarily concerned with the _private_ key, not the 
public key or the certificate.  But I  disagree with whoever suggested that the 
application would have to parse the certificate to understand the key usage 
restriction.  It is much more likely that the key pair is typed once and for all at the 
time of its creation, and that the application or operating system therefore knows 
the kinds of operation that the key can be used for from the type that is bound to it,
and has to enforce those limitations on the key usage. Including the key usage 
in the certificate is therefore merely reflecting the already existing restrictions on 
the private key, so that someone won't try to use the public key in the certificate 
for encryption, since the recipient wouldn't be able to read it.

(Note that by saying this I don't mean to imply that there are other perfectly valid reasons
why the owner of the DS key doesn't want it used for encryption as well.  So I'm not
limiting the use of the DS bit to this purpose exclusively.)
>
>>
>>2.  There is a strong desire to have the Non-Repudiation bit serve as
>>an indication of a conscious, volitional act that may have significant 
>>legal consequences.
>
>Does this mean that unless there is *always* "a conscious, volitional act"
>Non-Repudiation can never occur?

Well, from a legal standpoint as I understand it, non-repudiation is an oxymoron, 
since a contract or other apparent agreement can always be repudiated by 
showing that compulsion or force was used, that the signer was not mentally
and legally competent (of sufficient age, etc.)  I'm not an attorney, and I'm not going
to try to summarize a year's worth of contract law in a sentence or two, but it is 
my understanding that the essential elements of a contract are a true meeting of the
minds of the two (or more) parties, plus "consideration," normally an exchange 
of money for goods.

I believe that there is some concern in legal circles that someone who was not 
necessarily skilled in the software arts might not recognize when a digital signature
was being applied, and hence could claims that they were uninformed or worse 
yet, duped or tricked into signing away Grandma's house.

So I'm not going to say "always," especially with a double negative like 
"non-repudiation can never occur".  A conscious, volitional act might still be 
overturned for some other reason, and the absence of a conscious, 
volitional act might still be upheld as legal binding, especially if it can be 
shown that the alleged signer knew, or ought to have known, the likely
consequences of their actions.  You or I, in other words, are probably going
to have a more difficult time trying to wriggle out of a contract than Grandma might.

(Since I'm married to a "Grandma," I guess I ought to make it clear that I am
using that term in an affectionate, rather than pejorative sense! :-)

Now it's true that there might be other implications associated with the NR usage.
Some have suggested that when it is asserted, the CA is assuming an obligation 
to maintain all of the records necessary to confirm the absence of any revocation,
more or less in perpetuity.  I doubt that makes much business sense -- in perpetuity
is a very long time, and I suspect that the amount charged for the certificate isn't
enough to pay for maintaining those records forever, but if some CA wants to 
commit to that for its NR certificates I won't object.

Personally, I would like to see the NR bit used to inform the relying party that this 
certificate is rather special, and that any document that is signed and verified 
with it is likely to be important, and hence the relying party would probably be 
well advised to collect all of the certificates, perhaps have them notarized or 
timestamped, and archive them along with the document.  That's what I would 
do for any important document that I received that was associated with a NR usage,
but I'm not going to lobby too hard for that interpretation either.

Again, just to make it clear, I am  addressing the key usage which is primarily
associated with the private key, and is _reflected_ in the public key usage.

>
>>
>>(Although there might be some benefit to having defining an "authentication 
>>service" that would be distinct from the nonrepudiation service, there wasn't 
>>much support for that, especially if it would mean trying to push a defect 
>>report through X.509.  So I've given up on that thrust.)
>
>I'd be glad to support pushing a defect report. They never should have
>overloaded the key usage extension. They have overloaded the extension with 1)
>usage of the key, 2) services the key may provide, and 3) limiting what the key
>may signed.

In the immortal words of Walt Kelley, the originator of the finest comic strip ever
created ("Pogo"), "We have met the enemy, and they is us."  I'm afraid we are
all somewhat guilty in this particular area -- it looked reasonable at the time.

I'm not sure how feasible it is to try to overturn the apple cart at this late date, but 
maybe better late than later still.  You lead, and I'll follow.
>
>>
>>So let's think about what the implications of the NR bit ought to be.
>>
>>For one thing, as some people on the legal side of the house have argued,
>>in order to forestall the "Grandma hits the wrong button and loses her house"
>>argument against PKI and digital signatures in general, we need to require
>>a "gravity charge" be provided in the software in this case.  It should say something 
>>like: "Warning. You are about to sign something using a Non-Repudiation 
>>key, which may give rise to legal consequences for which you may be 
>>held personally and uniquely liable or responsible. Do you want to continue?"
>
>As someone else already pointed out, this assumes that the application can parse
>the certificate. Also, it assumes the the underlying crypto API takes the
>certificate to do the sign operation and not the private key.

No, as I said earlier, I am assuming that the key is strongly typed at the time of 
its creation. If the usage by the originator depended only on the certificate, 
then the issue of having two certificates for the same key could arise.
>
>>
>>In addition to the gravity charge, it would certainly be desirable to have 
>>an additional level of password or even biometric controls that are applied in 
>>order to unlock the NR key.  This not only underscores the serious, ceremonial 
>>aspect of a legally binding signature, it helps to assure that that user and that user 
>>only has access to that key.
>>
>>(I'm using the term "NR key" to avoid the awkward phrase, "the private 
>>key that is logically associated with the public key which is included in a 
>>certificate which has a Non Repudiation keyUsage parameter specified."  
>>Besides, although some applications and/or APIs may not associate 
>>the corresponding public key attributes with the private key, I 
>>believe that most applications will in fact do so.)
>>
>>Since the absolute quintessence of non-repudiation in the technical sense is that
>>only the authorized holder of the corresponding private key could have possibly
>>signed the document which is validated by the NR certificate, it is essential that 
>>access to that key be uniquely restricted to that user.
>>
>>At the risk of being obvious, that means that:
>>
>>1.  It must be computationally infeasible in the strictest sense for any other person 
>>than the authorized user to computer or re-derive the private key. that includes the 
>>software vendor, the user's MIS department, the various export/import authorities,
>>etc.
>>
>>2.  Likewise, it means that all possible precautions must be taken against 
>>the possibility
>>that even the authorized user could, accidentally or deliberately, disclose 
>>or give away 
>>knowledge of or access to so much as a single bit of the private key, or of 
>>the entropy 
>>from which it was derived.
>>
>>3. And again, it must not be possible for even the user's supervisor or MIS department 
>>to replace the user's private key with another private key that matches a certificate 
>>containing the user's identity information or rights access.  (The CA may 
>>be able to issue
>>a certificate corresponding to a bogus private key, but the network 
>>administrator, directory
>>administrator, etc., must not be able to do so, or to cause it to happen.)
>
>Don't these 3 items apply to digital signatures when used for authentication?
>While digital signatures provide integrity, you usually want more than integrity
>(otherwise why use digital signatures?). Thus, if my supervisor can replace my
>private key, then he can impersonate me.

You of course have a point.  However, in most of the authentication examples I
am familiar with, the user is authenticating his access to resources that are controlled
by the company he works for (e.g., printer, a server, or a database), and those 
access rights are typically controlled by the much the same people that issue 
e-mail accounts, grant directory access, etc.  

I'm willing to think about this some more, but I view the use of digital signatures to 
control access to information and/or other resources as being primarily a usage 
issue, and secondarily a privacy issue.

For example, take an on-line personnel database.  The company might very well 
require the use of a digital signature, e.g., SSL client authentication, to control access 
to who can read my 401K earnings. I would certainly be upset if my supervisor 
could access that information, but it wouldn't be the end of the world, since he already 
knows and controls how much I make, etc.

What I do want to make very sure, however, is that he can't go into my file and for 
example cash me out, or change the beneficiary of my insurance policies -- such actions
have significant legal consequences that go far beyond privacy, and ought to require
non-repudiation.

So I don't think there would be any disagreement with point 1 -- digital signature keys
should never be escrowed.  Even the feds don't want that for it would make it too 
easy for someone to claim that they were set up.

Point 2 is particularly difficult to implement, but is intended to prevent the situation where
someone allows their spouse to have access to their private key (password) for home 
banking, but without that person' knowledge, or even after death, uses that key to
forge a codicil to their will, etc.  So I'd live to come right out and require the use
of biometrics for all non-repudiation, but as yet is isn't quite feasible.

Point 3 address the case we were talking about earlier, in particular where the user's key
may be stored in the directory or other central location where the system administrator
could conceivably change the user's password and access the key somehow.

Although I can imagine that a number of people who would say that this is just flat out 
a terrible idea and should never be done, the benefits of being able to access a single 
sign-on key from whatever terminal or workstation you are using are considerable.
Schools, for example, can usually not afford to dedicate a particular terminal to a single 
student, and the same is true for operational control centers that operate on a 7x24 
hour basis.  Storing keys in smart cards, is one approach, but if you forget or lose 
your card you may be locked out. Password encrypted floppy disks are another 
possibility, but still awkward.  So I'm not willing to rule out these kinds of systems in 
general. I just want to make sure that they don't compromise the NR aspects that
apply to a particular individual.

>>In a sense, the NR bit goes further than my definition of the DS bit, in 
>>that the DS bit 
>>implies that the private key is not subject to governmental escrow as a 
>>condition of its 
>>export, import, or use, while the NR bit implies that the private key is 
>>not subject to 
>>ANY form of externally imposed escrow, key recovery, or key sharing.
>
>I strongly disagree! Don't confuse the issue by bringing in key escrow, key
>strength, key recovery, etc. into the picture. If I can coin a new phrase (and
>I'm not trying to insult you, I highly respect your opinions): KISS - Keep It
>Secure Stupid!

Well, thanks, but unfortunately as a US citizen I don't get to vote in the French 
elections. so whether we like it or not, these issues have to be dealt with.

All I'm suggesting is that the prohibitions against key sharing, access to keys by
people within the company, etc., etc., are not quite as rigid in the case of DS as 
they are in the NR case.  In either case, DS or NR, government access to keys
(GAK!) would be prohibited by the key typing, or vice versa, and so indicated.
>
>>
>>So what does this imply about various combinations of key usage bits?
>>
>>Clearly, the use of the DS bit and either key exchange or data encryption is not 
>>valid, as they are diametrically opposed concepts.
>
>YES!!
>
>>
>>Equally clearly, the use of both the DS and the NR bit _is_ allowed.
>
>YES!! If I could, I would require the DS bit to be set anytime the NR was set.

I'm not strongly opposed to that, and in fact that was my position prior to realizing 
that NR plus encryption could be used to indicate that no escrow was taking place.
If the DS bit would always be set, as opposed to using NR by itself, it would be
a few nanoseconds faster.
>
>>
>>But surprisingly, as I just realized while driving in to work this morning, the use 
>>of the NR bit in combination with key encryption or data encryption is NOT prohibited,
>>and in fact can be used as a form of back-handed specification of a key that can be 
>>used for encryption and is not subject to escrow or sharing!
>
>NO!! Do not mix key usage. To provide Non-Repudiation, you have to sign
>something and hence that key should not be used for encryption.

Well, not so fast.  Even if NR _always_ equates to a signature operation, that shouldn't
necessarily _prohibit_ its use for encryption, should it?  You and I might prefer to use
two different keys, but does that have to be imposed as a mandatory standard?

For example, is it possible to conceive of an SSL v3 session which uses client 
authentication, and claims nonrepudiation for the _session_, as opposed to signing
a particular document?  Seems to me that some home banking and similar applications 
might conceivably want to make use of such a concept.

I'll grant that by suggesting that NR might apply to encryption, I am stretching the 
popular concept a bit, and effectively redefining the key usage to mean "exclusive
control of the private key by the names user".  But isn't that effectively what we have 
been saying?

I won't go to war if the consensus is that we should restrict NR to signature operations,
but even then I wonder about such constructs as hashed MAC operations, etc.
>
>>That is the assumed or default case, where none of the key usage bits are specified.
>>
>>Using a key that is marked for both NR and key or data encryption does NOT mean that 
>>it is being used for digital signature, however -- at least with the above 
>>definition. But it 
>>does mean that that key is uniquely and exclusively associated with that user, which
>>in many cases is a very desirable condition.

I unfortunately muddied the water by a typo repeated several times.

>>So KR by itself or KR plus data encryption is OK.

Let's take them one at a time:

NR by itself is OK.  

I suppose you agree, but would prefer that NR always means signature,
and hence should never be used alone, whereas I am willing to allow (but would
discourage) a single key labeled NR being used for both signature and encryption purposes.

NR in combination with key encryption or data encryption is OK.

(This makes it explicit. In particular, it means that the key is NOT subject to key escrow
or other forms of sharing, whether or not it is used for signature purposes. So I would think 
you would like this??)

>>KR plus DS is OK.

>I would prefer NOT OK.

I meant NR plus DS is OK, and I think you meant to agree, except for the 
confusion, especially if you interpreted "KR" to mean key recovery.  
Sorry about that.
>
>>
>>DS by itself is OK.
>>
>>DS plus data encryption is forbidden.
>
>YES!!

In this case (DS by itself), I am assuming the use of a signature for 
integrity purposes, but perhaps with a lesser standard of exclusivity
of the key control (no key escrow, however), and also the lack of 
the gravity charge and the conscious, volitional usage?

Whereas the absence of both DS and KR would imply that the key 
might possible have been escrowed, and/or that the signature
might be generated by an automaton that is not under the specific 
control and case by case review of the user?
>
>>
>>Does this make sense?
>
>In general yes, but where does this leave a question I previously posted: "What
>happens when there is more than one certificate for a key?" Who ensures that
>there are no conflicting key usage in the different certificates?

Typing the key, as opposed to relying on the contents of the certificate, solves 
this problem. The key usage in the certificate is primarily of an advisory 
nature to the recipient.
>Regards,
>Aram Perez
>Apple Computer, Inc.

This stuff is hard, and we have to get it right.  I appreciate the detailed comments 
and the dialog.

Regards,

Bob

Date: Tue, 01 Sep 1998 13:39:54 -0400
To: "[email-masked]'" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: For  Option 2
Sender: [email-masked]

Date: Tue, 01 Sep 1998 13:39:47 -0400
To: "[email-masked]'" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Sender: [email-masked]

In case anyone is interested, here's my two cents worth...

The LDAP straw poll message concentrates on the technical rationale behind
each of the two options.  In fact, each is a technically sound proposal.
Option #1 is more elegant since there is no redundant data.  Option #2 is a
little more flexible, but clients may incur a performance hit when building
infrequently used paths.  IMHO, it's a wash.

I prefer option #2, but for rather pragmatic reasons.  There are two large
pools of PKI clients.  These two groups were designed independently, and
the implementers made different assumptions.  If we choose option #1, we
break one group of clients. HOWEVER, if we choose option #2, both sets of
clients will work - and will be interoperable!

Since a technically viable solution exists that doesn't break any existing
clients and actually makes them interoperable, that is my preference.

From: Anne Anderson - Sun Microsystems <[email-masked]>
Date: Tue,  1 Sep 1998 12:38:44 -0400 (EDT)
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Steve Kent'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 11:10:28 -0400 
Sender: [email-masked]

Folks 

This is a straw poll on the use of the cACertificate and
crossCertificatePair attributes in the PKIX LDAP schema draft. There are 2
options, each of which received sufficient support during the Chicago
meeting to require this straw poll to resolve the issue. Below is the
specific text proposed for each option, followed by a summary of the
rationale behind each of the proposals. The specific text for the proposals
and rationale summaries have been cooperatively drafted by Santosh Chokhani,
Dave Horvath and myself.

Votes must be in by COB on Thursday Sept 3.  This is the only outstanding
issue on this I-D following the 2 week last call so we should be able to
progress both the PKIX LDAPv2 protocol profile and PKIX LDAPv2 schema
following this poll.
. 
To vote, send an email to [email-masked] with one of the following
subject lines: 

To vote for option 1put "For Option 1" in the subject line. 
To vote for option 2 put "For Option 2" in the subject line.	 

As with the earlier polls conducted by Tim Polk on Part 1, don't bother with
a message body, I am just going to count the messages.  Discussion of the
content of this message should reply to this message.

PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
OPTION 1:
----------------
The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA. In addition, the cACertificate attribute shall be used to
store self-issued certificates.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates issued
to this CA by CAs in other domains.  Optionally, the reverse element of the
crossCertificatePair attribute, held in a particular CA's directory entry,
may contain certificates issued by this CA to CAs in other domains.

In the case of V3 certificates, none of the above CA certificates may
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

OPTION 2:
-------------
The crossCertificatePair attribute, held in a particular CA's directory
entry, shall be used to store all certificates issued by this CA to other
CAs, as well as certificates issued for this CA by other CAs. Values held in
the forward element are certificates issued for this CA by other CAs, while
values in the reverse element are certificates issued by this CA for other
CAs. 

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA. This set of certificates is a subset of the values of the
forward element of the crossCertificatePair attribute in the same CA entry.
In addition, the cACertificate attribute shall beused to store self-issued
certificates.  

The definition of domain is purely a matter of local policy.

In the case of version 3 certificates, none of the above CA certificates may
include a basicConstraints extension with the cA value set to FALSE.

SUMMARY OF RATIONALE FOR EACH OF THE OPTIONS:
--------------------------------------------------------------------

RATIONALE FOR PROPOSING OPTION 1:
--------------------------------------------------
The major advantage of this approach is that it minimizes the amount of data
retrieved from the directory.  The approach improves the relying party
response time and minimizes network utilization.

Another advantage of this approach over the alternative is that it does not
require the relying parties to separate the certificates stored in
caCertificate attribute from those stored in the crossCertificatePair
attribute.  The clients may need to do this during path construction.

Storing all the certificates in the crossCertificatePair attribute and also
storing some of the certificates in the caCertificate attribute, as
described in the alternative, unnecessarily increases the number of
certificates retrieved.  The alternative will result in poorer relying party
response time and use network bandwidth unnecessarily.  The alternative will
be particularly inefficient when a relying party is located remotely from
the repository/directory.

A minor disadvantage of the alternative is that it requires the same
information object (certificate) to be stored twice in a repository, once in
the caCertificate attribute and once in the crossCertificatePair attribute.
This increases he storage requirement on the directory.

RATIONALE FOR PROPOSING OPTION 2:
------------------------------------------------------------

Path development is a relying party process and the criteria for selection
of a 'preferred' set of certificates to enable efficiencies in that process
can vary according to the path discovery algorithm as well as from one
relying party to another, from one application to another, and on other
criteria as well. While a CA should optionally be able to provide helpful
hints to relying parties regarding the set of certificates the CA expects to
provide efficiencies, these may or may not match the requirements of a
relying party path discovery process. Relying parties will access CA
directory entries frequently to retrieve certificates as input to a
certification path development process and they should not be forced to know
whether or not a CA has published a set of  its 'preferred' certificates,
nor should relying parties be required to take on the extra burden of having
to request filtering of multiple directory attributes to retrieve the set of
certificates which is preferred in their particular environment, especially
given that relying parties will often need this information from CAs outside
their own local Intranet. 

CAs should be given the option to publish a set of 'preferred' certificates
but should not be required to do so. Should a CA elect to publish such a
set, the criteria used by that CA to determine the bases of the preference
should be left to the discretion of each CA or each security domain. The
preference should not be necessarily tied to a predetermined universal
criterion such as a single PKI or 'internal domain', especially given that a
CA may be issued a certificate by any number of other CAs and may therefore
subscribe to many PKIs.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Tue, 1 Sep 98 11:09:56 -0400
To: <[email-masked]>
From: "Fred Gloade Hrdc-drhc" <[email-masked]>
Reply-To: <[email-masked]>
Subject: fwd: Re: ...no subject...
Sender: [email-masked]

Fred Gloade 
Senior Auditor/Vérificateur principal
Information Technology and Systems
Technologies et systèmes informatiques
(819) 953-0842
[email-masked]

-------------
Original Text
From: "Steve Coya" <[email-masked]>, on 9/1/98 8:37 AM:
To: [email-masked]@NHQ
Cc: INET[<[email-masked]>]

Fred,

Your question should be sent to the PKIX Working Group:
[email-masked]

On Mon, 24 Aug 1998, Fred Gloade Hrdc-drhc wrote:

>>OK help me out here. 
>>With PKI do we need to rewrite code to incorporate the encryption 
routines?
>>There will be a server maintained somewhere with the public keys?
>>Will there be a hardware component or just a PIN?
>>Do you have a simple diagram that shows the flow of information in a very 
>>simple way?
>>Anything else you can send to help me would be greatly appreciated.
>>
>>
>>Fred Gloade 
>>Senior Auditor/VÚrificateur principal
>>Information Technology and Systems
>>Technologies et systþmes informatiques
>>(819) 953-0842
>>[email-masked]
>>
>>
>>

o

Date: Thu, 1 Oct 1998 00:48:37 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
cc: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan:

pls add in your 1) "if the server is non-anonymous"

pls add also a 0) "a self-signed common CA cert for the server and
user certs can make your life and the customer's life a lot more
pleasant"

>2) You suggest hashed SSN (social security numbers) using "salt"

if you must add SSN-based info in a public cert, IMO yes!

>type have to match the selected key exchange algorithm.

I fail to see why you "can't find this as an active selection
mechanism" together with the issuer DN, even if you want to keep the
same type for your repudiable and non-repudiable cases (which I
possibly would not, but that is another story). As I wrote:

>> (for higher security) with a different CA cert for each type.

and, again, later in the same msg:

>> Or, for higher security, the Bank can use different CA certs for
>> each type and send their DNs accordingly, in each case.
>>

so, all you need is to have different "types" (ie, DNs) of CA certs,
where both "types" should be signed by the same root CA cert of
course and the public-key root CA cert should be included in the
distribution.

Can you pls explain what causes selection difficulties for you in the
above scenario?

>"non-repudiation" certificate in the Java script application.

Please read above, I hope it is clearer now.

> I also fail

;-) If "all your problems" is what you stated, sure, all at one stop.

>Do you suggest that a more general matching mechanism is not needed?

If the problem is what you defined, yes.

>the dictionary attack is still possible.

1. The salt is only known to those entities that should know the SSN
-- not to the evildoer that is trying to get SSNs from a list of
cached client certs, in a common access area or in memory.

2. the salt is treated as client's private information -- and kept
separate from the cert, in a protected area together with other
private information from the client.

BTW, this is similar to "dividing" a SSN "signature" into two parts,
one public (in the cert) and another private (the salt).

> I would say that your "salt" is

Yes, certainly -- but it is more appropriately called a keyed-MAC.

BTW, I am glad that you now repudiate your phrase after your P.s
above ;-)

>should, or should not, be allowed to contain SSN.

No, I don't argue. As I wrote two msgs ago, some think they have
valid reasons for it and I do not disagree with the need to preserve
freedom. In that, I follow the C maxim -- even though I think that
security work is perhaps not the best place to leave enough rope so
that you may hang yourself with it if you so want or don't think it
is dangerous...

Cheers,

Ed Gerck

From: Alan Lloyd <[email-masked]>
To: "'Dave Horvath '" <[email-masked]>, "'Stefan Santesson '" <[email-masked]>
Cc: Alan Lloyd <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 09:25:18 +1000
Sender: [email-masked]

Sob story introduction - still on the road in the UK now - and flat chat
with the upswing in big X.500 systems and PKIs  from every point on the
compass. So the details below may have been skipped...
anyway. 

I always thought that the matching rules for certs and crls as defined
in X.509 were like other matching rules in that objects/attrs of
particular types can be searched for and managed whilst in the directory
system.

The issues is that the PKI /CA design has been designed as a set of
"sort of related objects, but operationally there are multipaths and
multi domains.. so we have an information relationship and managment
issue (in an originators domain).. and in some form, knowledge of this
"environment" must be propagated to the recipient of signed message with
a cert - so that efficient validation can occur.

The matching rule system is a mechanism for finding what one wants and
it can be configured with the desired values - ie knowledge (not
knowledge as per DSA access point knowledge) english meaning.

It strikes me that this knowledge (and the certficate)of the originating
domain should be transferred to the recipient domain and this knowledge
supplimented by the recipient - where appropriate - and this applied
through the matching rule mechanism into the directory system to achieve
validation.

the draft I submitted - draft-lloyd-dir-cert-stat  starts the
validation/matching rule direction off. And in fact permits orgainised
knowledge of validity - which is maintained by a CA..

Any way please read. 

Its an information management and knowledge issue associated with
CA/directory systems we are dealing with  - it wont be fixed by more
attributes on certficates and more protocols like OCSP.

thoughts are welcome
regards alan
----------
From: Stefan Santesson
To: Dave Horvath
Cc: Alan Lloyd; [email-masked] '; [email-masked] ';
[email-masked] '
Sent: 10/1/98 8:53:52 AM
Subject: Re: NEW Data type for certificate selection ?

I really do agree with you, sticking with the X.500 matching rules makes
it
possible to link a certificate select from a local application to a
suitable directory.

Say that the client certificates is stored in a directory and not in the
client application (or any mix). When receiving the match rule from the
server it would then be very easy to use the same match data to perform
an
extended lookup in the directory.

Unfortunately I just represent some of those service providers who need
this to be done, I will not be implementing this myself. Personally I
can
just predict better business for all if we solve this.

/Stefan

rules,
me.
APPLICATION.
>> >>  If anyone has any useful solutions for this (apart from "We
should
>> >> force

Date: Thu, 01 Oct 1998 00:53:52 +0200
To: Dave Horvath <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Cc: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

/Stefan

rules,
me.
APPLICATION.

Date: Thu, 01 Oct 1998 00:35:02 +0200
To: Ed Gerck <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Cc: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

Ed,

/Stefan

P.s

Date: Wed, 30 Sep 1998 15:08:26 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
cc: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan:

Cheers,

Ed Gerck

From: "Robert Klerer" <[email-masked]>
To: <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Date: Wed, 30 Sep 1998 13:44:02 -0400
Sender: [email-masked]

Stefan,

me.
APPLICATION.
>>SEIS Contact: [email-masked]

Date: Wed, 30 Sep 1998 13:20:43 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: Stefan Santesson <[email-masked]>
CC: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan,

I would add that I firmly believe the matching rule mechanisms should be
compatible with the work being done in X.500 and LDAP.   I would also like to
see X.500 and LDAP join forces and be compatible in the area of matching rules,
I am not sure where LDAP stands at this time.

Dave Horvath

Stefan Santesson wrote:
> Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.
> 

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Wed, 30 Sep 1998 16:43:41 +0200
To: David Horvath <[email-masked]>, Alan Lloyd <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

David,

Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.

Comments?
How do wee proceed ?

/Stefan

Date: Wed, 30 Sep 1998 11:15:51 -0400
From: David Horvath <[email-masked]>
Organization: @Home Network
To: Alan Lloyd <[email-masked]>
CC: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Alan,

Dave Horvath

> Snip

Date: Tue, 29 Sep 1998 13:30:03 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
Cc: [email-masked]
Sender: [email-masked]

Allen:

It means that the data in the CRL cannot be used to validate any
certificates.  Another source of revocation information must be used.

Russ

At 02:55 PM 9/28/98 -0700, [email-masked] wrote:
>First the question.   In Section 5.2 "CRL Extensions", p. 46, it says:
>
>     "A CRL validation MUST fail if it encounters a critical extension
>which it does not know how to process".
>
>My question is exactly what does it means that a "CRL validation fails"?.
>Does this mean that the CRL is to be ignored and that any certificates that
>might appear on the CRL are not invalidated by the CRL?.  I would suppose
>it is that interpretation rather than that a certificate validation fails
>if such a CRL is encountered.
>
>And now a minor comment.  I notice that RFC 2044 (on UTF8 strings) has been
>obsoleted by RFC 2279.  The comment is just to update the RFC reference in
>the spec in Appendix A.1 under UTF8String (p.69).
>
>
>

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure Certificate and CRL Profile to Proposed Standard
Date: Tue, 29 Sep 1998 08:06:00 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft Internet X.509 Public Key
Infrastructure Certificate and CRL Profile
<draft-ietf-pkix-ipki-part1-11.txt> as a Proposed Standard.  This
document is the product of the Public-Key Infrastructure (X.509)
Working Group.  The IESG contact persons are Jeffrey Schiller and
Marcus Leech.

Technical Summary
 
  The PKIX Working Group is chartered to specify an Internet profile
  for the use of X.509 certificates. The focus of the profile is to
  ensure interoperation between implementations that conform to it. The
  Part I specification defines formats and requirements for Certificates
  and Certificate Revocation Lists (CRLs). It is part of a suite of 
  documents, but can stand alone.

Working Group Summary

  This document is  the tenth  revision  of the Part I profile
  document. Input from many members of the community has gone into this
  draft which the working group has consensus on.

Protocol Quality

  Many  experts on Public Key Infrastructure and contributed and
  commented on  this  specification. Jeffrey  I. Schiller  reviewed the
  document for the IESG.

Y2K Compliance

  The protocols and formats in this document are Year 2000 compliant.

From: Anders Rundgren <[email-masked]>
To: "'Ed Gerck'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 09:26:09 +0200
Sender: [email-masked]

 

Anders

Date: Mon, 28 Sep 1998 15:31:45 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
Sender: [email-masked]

>And now a minor comment.  I notice that RFC 2044 (on UTF8 strings) has been
>obsoleted by RFC 2279.  The comment is just to update the RFC reference in
>the spec in Appendix A.1 under UTF8String (p.69).

Yes, please, since RFC 2279 had some technical corrections to RFC 2044, I
believe.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: [email-masked]
Date: Mon, 28 Sep 1998 14:55:42 -0700
Subject: A question and comment about PKIX - Part 1, Version 11.
Sender: [email-masked]

First the question.   In Section 5.2 "CRL Extensions", p. 46, it says:

     "A CRL validation MUST fail if it encounters a critical extension
which it does not know how to process".

My question is exactly what does it means that a "CRL validation fails"?.
Does this mean that the CRL is to be ignored and that any certificates that
might appear on the CRL are not invalidated by the CRL?.  I would suppose
it is that interpretation rather than that a certificate validation fails
if such a CRL is encountered.

And now a minor comment.  I notice that RFC 2044 (on UTF8 strings) has been
obsoleted by RFC 2279.  The comment is just to update the RFC reference in
the spec in Appendix A.1 under UTF8String (p.69).

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 07:11:56 +1000
Sender: [email-masked]

Snip

----------

 If anyone has any useful solutions for this (apart from "We should
force

" 
 
Peter.

Date: Mon, 28 Sep 1998 16:47:25 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Peter Gutmann <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Stefan and Peter:

 

but such is not safe.

Cheers,

Ed Gerck

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Time Stamp and Notary Drafts
Date: Mon, 28 Sep 1998 13:36:34 -0400
Sender: [email-masked]

As some of you may have noticed, I have submitted the latest versions of our
Time Stamp and Data Certification Server drafts as PKIX Internet Drafts, in
accordance with the decisions made in Chicago.  These drafts are based on
the drafts that we have been submitting independently on these topics for
some time now and reporting to PKIX on their progress.

The Time Stamp Draft describes a protocol in which a trusted Time Stamp
Authority provides evidence that a message existed at a particular point in
time.  It is available at:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt

The Data Certification Server provides "notary" type services (signature
validation, certificate path validation) in support of non-repudiation.
This draft is available at:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt

As usual, comments are welcome.

	Robert Zuccherato.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Reply-To: [email-masked]
Date: Tue, 29 Sep 1998 03:01:30 (NZST)
Sender: [email-masked]

 

 

 
Peter.

Date: Mon, 28 Sep 1998 07:32:49 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Questions about PKIX
Sender: [email-masked]

Actually, those are questions about a specific PKIX implementation. As
announced here earlier, that's being discussed on a different mailing list.
See <http://www.imc.org/imc-pfl/> for information about signing up for the
list and all the news that is known about the product.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Alan Lloyd'" <[email-masked]>
Cc: "'Warwick Ford'" <[email-masked]>, "'Steve Kent'" <[email-masked]>
Subject: RE: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 09:07:02 -0400
Sender: [email-masked]

Hi Alan,

The PKIX WG embarked on this spec well over a year ago with the primary
purpose being to standardize what was predominantly deployed at that time -
LDAPv2 for use to access PKI repositories. A minimum subset of the LDAPv2
protocol was profiled, in order to enable relying party and certification
authority systems to be able to access LDAP server PKI repositories without
needing all the code a typical LDAP client would have. We were not
attempting to standardize server to server communications, only a protocol
for clients (relying parties and CAs) to use to access the repository. 

While I personally agree with some of your views about the more
comprehensive functionality that can be provided in an X.500 based
distributed systems environment, that wasn't the task we undertook. 

As the work on LDAPv2 dragged on and on and on we qestioned several times
within the WG whether to drop this activity and concentrate instead on a
more 'modern' directory technology such as LDAPv3, but every time this was
raised, the PKIX WG agreed to proceed with the LDAPv2 specs and get them
progressed since this is still a very widely deployed protocol, even though
there is plenty of interest in LDAPv3 as well. The LDAPv2 protocol profile
completed PKIX WG last call in January and the schema spec just a short time
ago. No changes have been made to the protocol spec, the only reason it was
re-issued was because it was about to expire becasue the schema spec
(required for IESG approval of the protocol profile) took so long.

I hope this answers your questions on 'why' the LDAP activity. 
Sharon 

> ----------
> From: 	Alan Lloyd[SMTP:[email-masked]]
> Sent: 	September 27, 1998 6:24 PM
> To: 	[email-masked]'
> Subject: 	comments on draft-ietf-pkix-ipki2opp-08.txt
> 
> Comments: Internet X.509 Public Key Infrastructure 
>                             Operational Protocols - LDAPv2
> 
> Sorry for being my usual self. But what does this document do or solve.
> 
> All it states is use LDAP V2 to a PKI repository? and highlights the
> major failings of LDAP encoding when dealing with certificate attributes
> with multiple values. ie. In that the client gets the lot (every
> certificate - regardless) --  and if the client goes for CRLs as well  -
> and they are multi values of a CRL attribute - the client will get the
> lot as well.
> 
> Lets do some rough sums. A cert = 600 - 2k bytes average 1kb, 5-10 certs
> per user, 3 certs in a path.. transfer = 20- 30kb just to verify a
> signature. In addition CRLs - bad sites, and they could get large.
> And LDAP  accesses for the certs could be via referrals. Lets say that
> we could be looking at optimistically  at 10-30 seconds of validation
> time.
> I would be happy to be corrected here..
> 
> 
> Fundamental Problems with LDAP
> 
> LDAP servers are "string based" and non distributed - hence the need to
> use X.500 and migrate these LDAP servers to a distributed architecture.
> Not all certificates one wishes to deal with will be in your local ldap
> server - they will be in the directory system that one cooperates with.
> 
> X.500 has certficate matching rules to enable selection of certificates
> within a multi value attribute.
> 
> I am not sure what cert matching rules LDAP servers have or even if they
> support multi valued att matching or if they are compatible with X.500.
> Again the encoding restrictions in LDAP could imply the non use of
> these.
> 
> It is obvious to most that LDAP is not very good generally and in the
> case of PKI / certficate issues over a wider scale, totally unusable.
> 
> In addition the process one builds into an LDAP client to deal with
> referrals and LDAP certficate servers has to be lot larger and therefore
> problematic, than that that uses distributed directories with sound
> matching rules.
> 
> ie. the best it can get depends on the tools to hand.
> 
> I therefore beg why the document is being put forward because IMHO - it
> promotes systems to be built that will not provide the business utility
> demanded by companies using large scale EC/509 technologies. The result
> can only be commercial disasters and pain for both suppliers and the
> poor customer.
> 
> Oh well - 
> 
> regards alan
>    
> 

Date: Mon, 28 Sep 1998 22:11:42 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Mr. Santesson,

I am not necessarily against you.
I write all of my comments below
because I would like to contribute
to this issue.

Stefan Santesson wrote:

> Let me clarify my case.
>
> The problem I want to solve is how to pick 1 out of many certificates
> within an end user application.
>

I think that the real problem is how an application select a suitable
(or correct) certificate when there are multiple applications and
multiple certificates within one PC.

In your example below, S/MIME and another application (say,
application X) hold Cert 1 in common. If we limit the situation to
e-mail applications, this may be easy, but how do we realize it
in a generalized way ?

> An example.
>
> Alice has 4 certificates.
> 1) E-mail based ID with low security
> 2) Anonymous cert used for anonymous information services.
> 3) Qualified ID-certificate (with her social security number)
> 4) VISA SET-certificate.
>
> In this example:
> - Cert 1 and 2 are issued by the same CA and have the same key usage.
> - Cert 3 has key usage non-repudiation
>
> The problem is how to select the right certificate in every suitable
> occasion when several certificates is accessed by the same application.
> Clearly certificate 4 is no problem since it is used by a separate
> application (the SET wallet). So starting the SET wallet application
> automatically selects the right certificate.
>
> The problem in this case is not even S/MIME since Alice in this example
> only uses certificate 1 in her mail application.
>
> Here the problem is her web-based applications since she use certificate
> 1,2 and 3 with her browser. So every time she is asked to make a signature
> or authenticate via TLS, there is a risk that she will select and export
> the wrong certificate. In some cases maybe with a very unpleasant result.
>

In this example, I think the client application needs two kinds of
information: which application it is and which level of security it
needs.
Something like "application identifier" and "secuirty level
identifier" are necessary ?
(Honestly speaking, I myself don't like the idea, "let's register
 an object identifier for each application in the world".
Somebody has a good idea for this ?)
Or something like "security context" which can determine
a suitable certificate from among Cert 1, 2, or 3 ?

> server can help a client application to select one proper certificate out
> of many. In the example there is just 3 certificates to choose among but
> what if there is 20 or 30?
>

This is not limited to that a server can help a client application.
I think there is a case where a client application has to "think"
which certificate it must select for itself. (I mean, without help
from other party.)

I think there is a case where an application has to
select a certificate before it begins to communicate with other
party, especially in the case of peer to peer communication.

> The way to do this is, as I would suggest, a 2 step process:
> 1) To define a general selective mechanism (such as the X.500 match rule)
> 2) Get protocols, script languages and applications to support this.
>

Regretfully, the X.500 matching rule doesn't have "application identifer",
"security level identifer",  "security context", or something like that.

I think we have to think a new mechanism outside it, if we don't
modify or enhance it any more.

> So this is not about whether selection should be done based on issuer name,
> policy OID pr something else, but instead how to define a general
> mechanisms which allows customized selection rules within a broad range of
> applications and protocols. (In step 2 it is also about how a certificate
> can be stored and marked so it won't be exported by any application without
> the consent from its owner.)
>

For this purpose, too, I think we need a general mechanism to store
and to select (namely, to manage) certificates within one machine.

> I still think that The X.500 certificateMatch rule sounds interesting.
> Is there any will to go further in this process?
>

As I said, I think we have to think a new mechanism outside the X.500
matching rules.

I also think we can use the X.500 matching rules if we have some pieces
of information within a certificate, but that in the situation which we are
thinking, we are trying to select a certificate based on the information
outside the certificate. (This is the one reason that I think of the term,
"security context".)

> To us this is a MAJOR factor for succeeding with a broad CA business case
> and the vendors picking up this line will at least be in favor in those
> procurements that I'm involved in.
>
> /Stefan

(snip)

Actually I have designed a system where there are a few applications
and a few certificates in one PC. And I faced the problem how an
application could select a suitable or correct certificate.
In the end, I used something like "application identifier" for that system.
But as I said, to "register an object identifier for each
application in the world" don't seem to be a good idea.
I have kept seeking a good solution since then ...

Sorry that I can't show a clear and good solution,
but I hope my comments will be of some help.

Regards,

Jun Yoshitake

From: Sharon Boeyen <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Mon, 28 Sep 1998 08:13:13 -0400
Sender: [email-masked]

Hi Santosh, 

This mechanism does allow Delta CRLs to be included in pkiCA entries. Both
pkiCA and deltaCRL are auxiliary object classes. Multiple auxiliary object
classes can be present in the same directory entry. Only one structural
object class can be present in that same entry. 

For example, a CA entry could also be an organization entry. In that case,
organization would be the structural object class. pkiCA would be an
auxiliary class present in the same entry. If that CA used delta CRLs then
the deltaCRL auxiliary object class would also be present in the same entry.

The primary difference between structural and auxiliary object classes is
that the structural object class is the one that is used to base the naming
and the entry's location in in a directory tree structure, that's the reason
there can only be one present in each entry. Auxiliary classes do not have
this restriction. By defining the separate class for deltas we are now able
to add them, in a uniform way, to entries of other types in future (e.g.
possibly in attribute authority).  

Hope this helps. Happy to discuss further if required, give me a call.

Sharon

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 27, 1998 12:32 PM
> To: 	[email-masked]'
> Cc: 	[email-masked]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
> 
> I find the schema acceptable for the certificates.
> 
> I do not find the schema acceptable for delta CRL.  I thought we had a
> mechanism by which delta CRL could be stored in the object class pkiCA.
> It does not seem to be the case.  Sharon, I assume you recall the
> comment and resolution in this forum.
> 
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Thursday, September 24, 1998 10:27 AM
> > Cc:	[email-masked]
> > Subject:	I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
> > 
> > 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
> > LDAPv2 Schema
> > 	Author(s)	: S. Boeyen, T. Howes, P. Richard
> > 	Filename	: draft-ietf-pkix-ldapv2-schema-02.txt
> > 	Pages		: 7
> > 	Date		: 23-Sep-98
> > 	
> >      The schema defined in this document is a minimal schema to
> > support
> >      PKIX  in  an  LDAPv2  environment,  as  defined in
> > draft-ietf-pkix-
> >      ipki2opp-07.txt. Only PKIX-specific components are specified
> > here.
> >      LDAP  servers, acting as PKIX repositories should support the
> > auxi-
> >      liary object classes defined in this  specification  and
> > integrate
> >      this  schema  specification with the generic and other
> > application-
> >      specific schemas as appropriate, depending on the  services  to
> > be
> >      supplied by that server.
> >  
> >      The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD',
> > 'RECOMMENDED',
> >      and  'MAY'  in  this document are to be interpreted as described
> > in
> >      RFC 2119.
> >  
> >      Please send comments on this document to the [email-masked]
> > mail
> >      list.
> > 
> > Internet-Drafts are 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-ldapv2-schema-02.txt".
> > A URL for the Internet-Draft is:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.tx
> > t
> > 
> > Internet-Drafts directories are located at:
> > 
> > 	Africa:	ftp.is.co.za
> > 	
> > 	Europe: ftp.nordu.net
> > 		ftp.nis.garr.it
> > 			
> > 	Pacific Rim: munnari.oz.au
> > 	
> > 	US East Coast: ftp.ietf.org
> > 	
> > 	US West Coast: ftp.isi.edu
> > 
> > Internet-Drafts are also available by mail.
> > 
> > Send a message to:	[email-masked].  In the body type:
> > 	"FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.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. << Message: Untitled Attachment >> 
> 

Date: Mon, 28 Sep 1998 11:17:31 +0200
To: Alan Lloyd <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Sender: [email-masked]

Let me clarify my case.

The problem I want to solve is how to pick 1 out of many certificates
within an end user application.

An example.

Alice has 4 certificates. 
1) E-mail based ID with low security 
2) Anonymous cert used for anonymous information services. 
3) Qualified ID-certificate (with her social security number) 
4) VISA SET-certificate.

In this example: 
- Cert 1 and 2 are issued by the same CA and have the same key usage. 
- Cert 3 has key usage non-repudiation

The problem is how to select the right certificate in every suitable
occasion when several certificates is accessed by the same application.
Clearly certificate 4 is no problem since it is used by a separate
application (the SET wallet). So starting the SET wallet application
automatically selects the right certificate.

The problem in this case is not even S/MIME since Alice in this example
only uses certificate 1 in her mail application.

Here the problem is her web-based applications since she use certificate
1,2 and 3 with her browser. So every time she is asked to make a signature
or authenticate via TLS, there is a risk that she will select and export
the wrong certificate. In some cases maybe with a very unpleasant result.

In order to make this user friendly, we have to create a mechanism where a
server can help a client application to select one proper certificate out
of many. In the example there is just 3 certificates to choose among but
what if there is 20 or 30?

The way to do this is, as I would suggest, a 2 step process: 
1) To define a general selective mechanism (such as the X.500 match rule) 
2) Get protocols, script languages and applications to support this.

So this is not about whether selection should be done based on issuer name,
policy OID pr something else, but instead how to define a general
mechanisms which allows customized selection rules within a broad range of
applications and protocols. (In step 2 it is also about how a certificate
can be stored and marked so it won't be exported by any application without
the consent from its owner.)

I still think that The X.500 certificateMatch rule sounds interesting. 
Is there any will to go further in this process? 

To us this is a MAJOR factor for succeeding with a broad CA business case
and the vendors picking up this line will at least be in favor in those
procurements that I'm involved in.

/Stefan

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "'tyone '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 28 Sep 1998 18:16:45 +1000
Sender: [email-masked]

regards alan

----------
From: tyone
To: [email-masked]

Hi.

Takeshi Yoneda

environment
different

the
>general case.

From: Stefan_Salzmann/HAM/[email-masked]
To: [email-masked]
cc: Helmut_Speichermann/FRA/[email-masked], Boris_Baltzer/MUC1/[email-masked], Georg_Zyprian/FRA/[email-masked]
Date: Mon, 28 Sep 1998 09:51:59 +0200
Subject: Questions about PKIX
Sender: [email-masked]

Hi,

I have got some questions  concerning PKIX. So here they are:

When will be the code of the PKIX reference available at the MIT Web Pages?

What is Jonah in relation to PKIX?

When starts the PKIX developers converence in October?

Are there already White Papers available?

Thanks for answering,
Regards
Stefan

Date: Mon, 28 Sep 1998 11:19:19 +0900
From: tyone <[email-masked]>
To: [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

Hi.

Takeshi Yoneda

>using Issuer name as selection criteria, is hopelessly insufficient for the

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 08:24:56 +1000
Sender: [email-masked]

Comments: Internet X.509 Public Key Infrastructure 
                            Operational Protocols - LDAPv2

Sorry for being my usual self. But what does this document do or solve.

All it states is use LDAP V2 to a PKI repository? and highlights the
major failings of LDAP encoding when dealing with certificate attributes
with multiple values. ie. In that the client gets the lot (every
certificate - regardless) --  and if the client goes for CRLs as well  -
and they are multi values of a CRL attribute - the client will get the
lot as well.

Lets do some rough sums. A cert = 600 - 2k bytes average 1kb, 5-10 certs
per user, 3 certs in a path.. transfer = 20- 30kb just to verify a
signature. In addition CRLs - bad sites, and they could get large.
And LDAP  accesses for the certs could be via referrals. Lets say that
we could be looking at optimistically  at 10-30 seconds of validation
time.
I would be happy to be corrected here..

Fundamental Problems with LDAP

LDAP servers are "string based" and non distributed - hence the need to
use X.500 and migrate these LDAP servers to a distributed architecture.
Not all certificates one wishes to deal with will be in your local ldap
server - they will be in the directory system that one cooperates with.

X.500 has certficate matching rules to enable selection of certificates
within a multi value attribute.

I am not sure what cert matching rules LDAP servers have or even if they
support multi valued att matching or if they are compatible with X.500.
Again the encoding restrictions in LDAP could imply the non use of
these.

It is obvious to most that LDAP is not very good generally and in the
case of PKI / certficate issues over a wider scale, totally unusable.

In addition the process one builds into an LDAP client to deal with
referrals and LDAP certficate servers has to be lot larger and therefore
problematic, than that that uses distributed directories with sound
matching rules.

ie. the best it can get depends on the tools to hand.

I therefore beg why the document is being put forward because IMHO - it
promotes systems to be built that will not provide the business utility
demanded by companies using large scale EC/509 technologies. The result
can only be commercial disasters and pain for both suppliers and the
poor customer.

Oh well - 

regards alan

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Sun, 27 Sep 1998 12:32:11 -0400
Sender: [email-masked]

I find the schema acceptable for the certificates.

I do not find the schema acceptable for delta CRL.  I thought we had a
mechanism by which delta CRL could be stored in the object class pkiCA.
It does not seem to be the case.  Sharon, I assume you recall the
comment and resolution in this forum.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, September 24, 1998 10:27 AM
> Cc:	[email-masked]
> Subject:	I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
> 
> 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
> LDAPv2 Schema
> 	Author(s)	: S. Boeyen, T. Howes, P. Richard
> 	Filename	: draft-ietf-pkix-ldapv2-schema-02.txt
> 	Pages		: 7
> 	Date		: 23-Sep-98
> 	
>      The schema defined in this document is a minimal schema to
> support
>      PKIX  in  an  LDAPv2  environment,  as  defined in
> draft-ietf-pkix-
>      ipki2opp-07.txt. Only PKIX-specific components are specified
> here.
>      LDAP  servers, acting as PKIX repositories should support the
> auxi-
>      liary object classes defined in this  specification  and
> integrate
>      this  schema  specification with the generic and other
> application-
>      specific schemas as appropriate, depending on the  services  to
> be
>      supplied by that server.
>  
>      The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD',
> 'RECOMMENDED',
>      and  'MAY'  in  this document are to be interpreted as described
> in
>      RFC 2119.
>  
>      Please send comments on this document to the [email-masked]
> mail
>      list.
> 
> Internet-Drafts are 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-ldapv2-schema-02.txt".
> A URL for the Internet-Draft is:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.tx
> t
> 
> Internet-Drafts directories are located at:
> 
> 	Africa:	ftp.is.co.za
> 	
> 	Europe: ftp.nordu.net
> 		ftp.nis.garr.it
> 			
> 	Pacific Rim: munnari.oz.au
> 	
> 	US East Coast: ftp.ietf.org
> 	
> 	US West Coast: ftp.isi.edu
> 
> Internet-Drafts are also available by mail.
> 
> Send a message to:	[email-masked].  In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.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. << Message: Untitled Attachment >> 

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "'Stefan Santesson '" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Sun, 27 Sep 1998 09:30:02 +1000
Sender: [email-masked]

just thoughts
regards alan

----------
From: Stefan Santesson

All,

Comments, suggestions.

/Stefan Santesson

Date: Fri, 25 Sep 1998 09:24:36 -0700
To: Denis Pinkas <[email-masked]>, IETF-PXIX <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: Archive cutoff & Retention period
Sender: [email-masked]

Denis,

At 10:03 AM 9/23/98 -0700, Denis Pinkas wrote:
>
>The "retention period" should be supported by all OCSP responders
>and thus should be part of the standard response. Adding a
>"retentionPeriod" after the "produceAt" from the ResponseData would
>be simpler than defining an extension.

We didn't want to break the response syntax, especially in light of the
fact that support for long term retention of status data is not a core
requirement.

>Then, let us address the « Archive Cutoff » issue.
>
>If we were to support the archiving capability, with e.g. a 7 year
>retention, we would need an additional time parameter in the request
>to point to the equivalent of the right CRL issued at that time e.g.
>7 years ago. This parameter is currently not present. Unless it is
>added, the function cannot work. We thus have two options : add the
>missing parameter or delete this capability. Opinions ? 

As the public debate on this issue had concluded, the requirement is to
enable responders to assert a bound on the historical accuracy of their
responses.  The archive cutoff extension satisfies this requirement.  This
function speaks only to the most current status of the certificate, not to
its status at any point in time.

Mike

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-08.txt
Date: Fri, 25 Sep 1998 10:27:54 -0400
Sender: [email-masked]

--NextPart

Note: This revision reflects comments received during the last call period.

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 
                          Operational Protocols - LDAPv2
	Author(s)	: S. Boeyen, T. Howes, P. Richard
	Filename	: draft-ietf-pkix-ipki2opp-08.txt
	Pages		: 12
	Date		: 24-Sep-98
	
     The protocol described in this document is designed to satisfy some
     of  the  operational  requirements within the Internet X.509 Public
     Key Infrastructure (IPKI).  Specifically, this  document  addresses
     requirements  to  provide access to Public Key Infrastructure (PKI)
     repositories for the purposes of  retrieving  PKI  information  and
     managing  that  same  information.  The mechanism described in this
     document is based on  the  Lightweight  Directory  Access  Protocol
     (LDAP) v2, defined in RFC 1777, defining a profile of that protocol
     for use within the IPKI and updates encodings for certificates  and
     revocation  lists  from  RFC 1778. Additional mechanisms addressing
     PKIX operational requirements are specified in separate documents.
 
     The key words  'MUST',  'REQUIRED',  'SHOULD',  'RECOMMENDED',  and
     'MAY'  in  this  document are to be interpreted as described in RFC
     2119.
 
     Please send comments on this document to the [email-masked] mail
     list.

Internet-Drafts are 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-ipki2opp-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki2opp-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki2opp-08.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-ipki2opp-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki2opp-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 25 Sep 1998 13:34:29 +0200
To: "Miklos, Sue A." <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Sender: [email-masked]

Thank you Sue,

Comments, suggestions!

/Stefan Santesson 

Date: Fri, 25 Sep 1998 18:29:35 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

I have two comments.

1. I'd like to clarify the scope.

Is it limited to the case where one party
which to assist another party ?
I suggest that it include the case
where a person has multiple certificates
in his / her PC, WS, etc. It will be more
useful and more efficient if there is
a standardized mechanism for the case
like this rather than that each application
manages its certificates in its own way
on one machine. Some applications could
hold a certificate in common.

2. It would be better that we consider
the generation management of a certificate.

Suppose a certificate has expired and you
get the new certificate on your PC. Namely,
you have two certificates on your PC, the old
one and the new one. Attention should be paid
not to let an application select the old one.
(Of course, things are easy if the old one is deleted.
But is it really always good for all the cases, all applications,...?)
(Issuer and Serial Number is nice, but you need
the mechanism to record "this serial number is for
the new one" when you get it for the first time.)

Jun Yoshitake

Stefan Santesson wrote:

> Accurata Systems$BgL(Berhet AB
> 216 42  Malm$Bö (B                  Fax. +46-40 150790

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 24 Sep 1998 12:02:05 -0400
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_000_01BDE7B3.26345CD0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

>Weinstein, Netscape, the problem of certificate selection in an =
environment
>where the client is populated with many similar certificates for =
different
>S/MIME, Java, Java script, etc, where signing and encryption based on =
an
>using Issuer name as selection criteria, is hopelessly insufficient for =
the
>general case.
>
>In fact we can NEVER claim that we have an X.509 based architecture =
ready
>WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD =
START.
>could be used as a common base for enhancing TLS, Java, Java script, =
S/MIME
>server, server to server, client to client; I.e in any case where one =
party
>which to assist another party in selecting an appropriate certificate =
for
>Accurata Systems=E4kerhet AB    =20
>Lotsgatan 27 D                  Tel. +46-40 152211             =20
>216 42  Malm=F6                   Fax. +46-40 150790             =20

------ =_NextPart_000_01BDE7B3.26345CD0
Content-Type: application/msword; name="MATCH.DOC"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAAAgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////HgAAAP7///8fAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA
ACAAAAD+/////v///yEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA
LAAAAP7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8=

------ =_NextPart_000_01BDE7B3.26345CD0--

Date: Thu, 24 Sep 1998 08:05:20 -0700
From: Michael McNeil <[email-masked]>
Organization: GMT
To: Denis Pinkas <[email-masked]>
CC: Stephen Kent <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], Jeffrey Schiller <[email-masked]>
Subject: Re: meeting minutes
Sender: [email-masked]

Denis Pinkas wrote:
>Michael,
>As you say it, the minutes from the meeting are correct.

>>Stephen Kent wrote:
>>[snip]
>>>NEW TOPICS:
>>>- Timestamp & Notary proposals (Carlisle Adams)
>>>
>>>Several folks continuing work on these topics and have published
>>>an independent draft on these topics. The authors received a fair
>>>amount of private feedback, and hope to be able to bring forward a
>>>well-formed proposal. Jeff Schiller gave his permission to bring
>>>this into the WG, based on the WG having made substantial progress
>>>on the other work items. Thus we will expand the charter to
>>>encompass these topics.

>>This is what occurred during the PKIX sessions at the 42nd IETF
>>meeting with regards to timestamping; however the above is not
>>the whole story.
>>
>>Between sessions at the IETF meeting I talked with various people
>>about the new Internet-Draft (authored by Dave Mills, Todd Glassey,
>>and me) which extends the NTP protocol towards serving as a vehicle
>>for PKI certified and secured time ("ephemeral" time; "what time is
>>it *now*?" time), as well as also providing for *timestamps* of
>>data -- within the same protocol, essentially as gravy (a different
>>usage, I admit).

>From your short description,  people might think that the two drafts
>are equivalent.

Yes, thank you for pointing that out.  The two sets of drafts are quite
distinct, of course, as we're well aware.  I thought insufficiently of
the readers' perspective in wording the description unfortunately.

>Let me highlight some of the main differences:
>Let us call:
>
>"draft 1", the draft:
>ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt

Et al.

>and "draft 2", the draft:
>ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt
>
>Draft 1 is all in ASN1, as the rest of the other messages supported
>by PKIX, e.g. CMP. So it is in the spirit of the other documents. On
>the contrary, Draft 2 is supporting 32 bits words and is much more
>compact (unless that advantage will be lost by many extensions !)

We think not, but good point.

>The time formats are different between draft 1 and 2. Draft 1 is
>using the same time format as the rest of the PKIX documents, while
>draft 2 is using a 32 bits time representation.

NTP actually uses 64 bits of time, with 32 bits of fractional second
information.  The 32-bit seconds count will roll over in 2038; I have
suggested (Dave Mills and I disagree as to the desirability of this)
that 8-bit extensions to the time fields be added in an extension field.

>Draft 1 supports the time stamping of an imprint and as a side
>effect, may provide a trusted time when using the optional nonces.

The question is what would be the quality of the time (ephemeral time)
passed using that protocol.  A heavyweight protocol almost by definition
takes more time to convey than a lightweight one -- and it's the quality
of the time itself that we're interested in here (ignoring timestamps
for the moment).  A longer time to pass the time futzes the precision of
the time.  Moreover, draft 1 lacks the fractional seconds information
NTP maintains, lacks the extra fields NTP possesses which allow it to
communicate the accuracy of the time and the last time that the server's
time was updated from a reliable source.  These last deficiencies can be
fixed, of course, in the draft 1 proposal (though perhaps not the
"heavyweight" issue); any deficiencies in the draft 2 protocol noted
below can also be repaired (except perhaps the "lightweight" issue). ;-)

>Draft 2 is unclear about time stamping, in particular the indication
>of the hash function used for the imprint and its protection. It
>allows various extension fields and so the minimum format to be
>supported is left undefined.

Draft 2 is a work in progress (this last is the second version), and
admittedly is less finished in this regard than draft 1.  We expect to
have another Internet-Draft ready for publication, with details of the
important extensions fields fleshed out, by the 43rd IETF in December.

>It is also unclear about the replay protection when only the time
>is returned (unless that information is present is some other
>documents ?).

NTP has inherent replay resistance in that if your time is already
reasonably good, replay attacks are instantly visible as being old. 
Moreover, NTP normally (despite conveying an absolute time) only steers
the time -- it doesn't reset a machine to a radically different time,
appearing out of the blue within an NTP packet.  Even so, additional
authentication is desirable to present spurious NTP attacks; that is the
point of the "draft 2" Internet-Draft.  A more fundamental protection
against replay attacks, from a cryptographic point of view, is to
require that the client as a sanity check do a unicast probe of the
server every now and then, rather than depending on broadcast packets,
including random bits of its own in its request -- which then get echoed
back in the signed NTP reply from the server.  Detecting its bits in the
reply, the client knows it's in response to its own most recent request.

>>I spoke with Jeff Schiller about this.  After he'd had a chance
>>to look over the Internet-Draft (i.e.,
>><draft-mills-ntp-auth-coexist-01.txt>), we spoke again, very near
>>the end of the IETF meeting.  Jeff at that time suggested that
>>since it was now apparent to him that the issue of PKI and time
>>goes well beyond the question of timestamps to the issue of how
>>secure *time itself* can be conveyed over an insecure network, he
>>thought that perhaps the PKIX working group was not equipped to
>>properly address this expanded issue -- or at least Jeff thought
>>the IESG ought to be consulted first on the question before the
>>issue of PKIX handling it or a separate "time" working group
>>being set up is laid to rest.

>From what is above, "draft 2" would not be usable in a PKIX
>environment, where the compactness of the messages is not the
>issue, since the Time Stamp will be used mostly either in a
>store and forward environment or in a local environment.
>
>However, there may be some good reasons to have a 32 bits
>oriented and more compact protocol for acquiring a secure time
>for other environments and therefore it can make sense to have
>two protocols.

I agree.

>>Thus the issue stands as far as I know.  I've addressed two e-mails
>>to Jeff since the IETF meeting (on 8 and 21 September) but so far
>>have not received a reply (I assume it takes time to poll the IESG
>>membership).  I have no particular stake in which way the decision
>>goes (except I think *some* working group needs to address time
>>*and* timestamping),

>I am not sure that a *single* working group needs to address both
>time and timestamping.

Good point.

>As a good example, we have already have the PKIX and the SPKI
>working groups: PKIX is using ASN.1, while SPKI does not.
>A similar parallelism ! :-)

A parallelism I hope doesn't draw a rain of stones and bricks!  ;-)

>>but wished to alert you that despite the outcome of the PKIX sessions,
>>the question of whether PKIX handles it appears not quite settled.

Thank you for your comments, Denis!

Regards,
Michael McNeil
GMT
[email-masked]
1-831-438-7811

Date: Thu, 24 Sep 1998 16:26:50 +0200
From: Mark Shuttleworth <[email-masked]>
Reply-To: [email-masked]
Organization: Thawte Consulting
To: [email-masked]
Subject: Re: NEW Data type for certificate selection ?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms78C9DE34404C8A045EF33A31
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiya

--
Mark Shuttleworth
Thawte
--------------ms78C9DE34404C8A045EF33A31
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms78C9DE34404C8A045EF33A31--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Thu, 24 Sep 1998 10:27:24 -0400
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 LDAPv2 Schema
	Author(s)	: S. Boeyen, T. Howes, P. Richard
	Filename	: draft-ietf-pkix-ldapv2-schema-02.txt
	Pages		: 7
	Date		: 23-Sep-98
	
     The schema defined in this document is a minimal schema to  support
     PKIX  in  an  LDAPv2  environment,  as  defined in draft-ietf-pkix-
     ipki2opp-07.txt. Only PKIX-specific components are specified  here.
     LDAP  servers, acting as PKIX repositories should support the auxi-
     liary object classes defined in this  specification  and  integrate
     this  schema  specification with the generic and other application-
     specific schemas as appropriate, depending on the  services  to  be
     supplied by that server.
 
     The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
     and  'MAY'  in  this document are to be interpreted as described in
     RFC 2119.
 
     Please send comments on this document to the [email-masked] mail
     list.

Internet-Drafts are 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-ldapv2-schema-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.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-ldapv2-schema-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldapv2-schema-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dcs-00.txt
Date: Thu, 24 Sep 1998 10:26:39 -0400
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 
                          Data Certification Server Protocols
	Author(s)	: C. Adams, R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-00.txt
	Pages		: 14
	Date		: 23-Sep-98
	
This document describes a general data certification service and the
protocols to be used when communicating with it.  The Data Certification
Server  is a Trusted Third Party (TTP) that can be used as one component
in building reliable non-repudiation services (see [ISONR]).  Useful
Data Certification Server responsibilities in a PKI are to validate
signatures and to provide up-to-date information regarding the status of
public key certificates.  We give examples of how to use the Data
Certification Server to extend the lifetime of a signature beyond key
expiry or revocation and to query the Data Certification Server
regarding the status of a public key certificate.
 
      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 [RFC2119].

Internet-Drafts are 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-dcs-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-dcs-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-dcs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dcs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-00.txt
Date: Thu, 24 Sep 1998 10:26:34 -0400
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 
                          Time Stamp Protocols
	Author(s)	: C. Adams, P. Cain, B. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-00.txt
	Pages		: 15
	Date		: 23-Sep-98
	
This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]).  In order to reduce the amount of trust required of a TSA we
introduce (in Appendix C) the optional Temporal Data Authority (TDA)
whose function is to provide further corroborating evidence of the time
contained in the token.  We also give an example of how to place a
signature at a particular point in time, from which the appropriate
certificate status information (e.g. CRLs) may be checked.

Internet-Drafts are 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-time-stamp-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-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-time-stamp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-time-stamp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-11.txt
Date: Thu, 24 Sep 1998 10:26:08 -0400
Sender: [email-masked]

--NextPart

Note: This revision reflects comments received during the last call period.

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 Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, T. Polk, D. Solo
	Filename	: draft-ietf-pkix-ipki-part1-11.txt
	Pages		: 128
	Date		: 23-Sep-98
	
   This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
   in the Internet.  An overview of the approach and model are provided
   as an introduction.  The X.509 v3 certificate format is described in
   detail, with additional information regarding the format and
   semantics of Internet name forms (e.g., IP addresses). Standard
   certificate extensions are described, and a set of required
   extensions is defined.  The X.509 v2 CRL format is described and a
   required extension set is defined as well.  An algorithm for X.509
   certificate path validation is described. Supplemental information is
   provided describing the format of public keys and digital signatures
   in X.509 certificates for common Internet public key encryption
   algorithms (i.e., RSA, DSA, and Diffie-Hellman).  ASN.1 modules and
   examples are provided in the appendices.
 
   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.

Internet-Drafts are 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-ipki-part1-11.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-11.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-part1-11.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-ipki-part1-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part1-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 24 Sep 1998 09:56:50 -0400
To: "Todd S. Glassey" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Amending the PKIX-WG Charter to reflect the addition of timestamping
Cc: [email-masked]
Sender: [email-masked]

It looks okay to me.....

At 07:17 PM 9/22/98 -0700, you wrote:
>Hi All, back in February we were working to amend the PKI WG's charter to
>encompass timestamping and the certified timer resources that enable these
>facilities. Now that Jeff Schiller has OK'd PKIX's having its own
>timestamping/timebase facility we need to finish the charter update process.
>here then is a proposed charter for your review and comments.
>
>Thanks,
>
>-----
>
>Todd Glassey
>
>Stephen Kent's report of the meeting minutes - excerpt below -
>
>- Timestamp & Notary proposals (Carlisle Adams)
>
>Several folks continuing work on these topics and have published an
>independent draft on
>these topics. The authors received a fair amount of private feedback, and
>hope to be able to
>bring forward a well-formed proposal. Jeff Schiller gave his permission to
>bring this into
>the WG, based on the WG having made substantial progress on the other work
>items. Thus
>we will expand the charter to encompass these topics.
>
>
>----- BEGINNING OF CHARTER TEXT ----
>
>Public-Key Infrastructure (X.509) (PKIX)
>--------------------------------------------------
>
> Charter
> Last Modified: September 18, 1998
>
> Current Status: Active Working Group
>
>Chair(s):
>Stephen Kent <[email-masked]>
>Warwick Ford <[email-masked]>
>
>Security Area Director(s):
>Jeffrey Schiller <[email-masked]>
>Marcus Leech <[email-masked]>
>
>Security Area Advisor:
>Jeffrey Schiller <[email-masked]>
>
>Mailing Lists:
>General Discussion:[email-masked]
>To Subscribe: [email-masked]
>In Body: subscribe (In Body)
>Archive: http://www.imc.org/ietf-pkix
>
>Description of Working Group:
>Many Internet protocols and applications which use the Internet employ
>public-key technology for security purposes and require a public-key
>infrastructure (PKI) to securely manage public keys for widely-distributed
>users or systems.  The X.509 standard constitutes a widely-accepted basis
>for such
>an infrastructure, defining data formats and procedures related to
>distribution
>of public keys via certificates digitally signed by certification
>authorities
>(CAs).
>
>For example, RFC 1422 specified the basis of an X.509-based PKI, targeted
>primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).
>Since RFC 1422 was issued, application requirements for an Internet PKI have
>broadened tremendously, and the capabilities of X.509 have advanced with the
>development of standards defining the X.509 version 3 certificate and
>version 2 certificate revocation list (CRL).
>
>Charter of the Working Group:
>The charter of the working group will be to develop Internet standards
>needed to support the use of an X.509-based PKI.  The goal of this Working
>Group (WG)
>will be to further facilitate the use of X.509 certificates in applications
>that
>make use of the Internet and to promote interoperability between different
>implementations choosing to make use of X.509 certificates.
>
>The resulting PKI is intended to provide a framework, which will support a
>range of trust/hierarchy environments and a range of usage environments
>(RFC1422
>is an example of one such model).
>
>Candidate applications to be served by this PKI include, but are not limited
>to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), IPSEC protocols, Internet
>payment protocols, time based authentication, timestamping, and www
>protocols.
>
>This project will not preclude use of non-infrastructure public-key
>distribution techniques nor of non-X.509 PKIs by such applications.  Efforts
>will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
>project.
>
>The group will focus on tailoring and profiling the features available in
>the v3 X.509 certificate to best match the requirements and characteristics
>of the
>Internet environment.
>
>Other topics to be addressed potentially include:
>
>     * Alternatives for CA-to-CA certification links and structures,
>including
>       guidelines for constraints
>
>     * Revocation alternatives, including profiling of X.509 v2 CRL
>extensions
>     * Certificate and CRL distribution options (X.500-based,
>non-X.500-based)
>     * Guidelines for policy definition and registration
>     * Administrative protocols and procedures, including certificate
>       generation, revocation notification, cross-certification, and
>key-pair
>       updating
>     * Naming and name forms (how entities are identified, e.g., email
>       address, URN, DN, misc.)
>     * Generation of client key pairs by the PKI
>     * Services that support non-repudiation.  This can include sources of
>       credible time data and/or certificate path validation services.
>
>----- END OF CHARTER TEXT ----
>

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "'Denis Pinkas'" <[email-masked]>
Cc: [email-masked]
Subject: RE: X.509 Documentation
Date: Thu, 24 Sep 1998 08:51:15 -0400
Sender: [email-masked]

On the server that Denis pointed to, you'll find the final text of the 1997
edition of X.509 (as submitted to the ITU and ISO for publication) at:

ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

(the primary reason this is not yet available for purchase from either ITU
or ISO is that they will not publish or sell it until all the other parts of
the 1997 X.500 Series are also ready (soon we're told by the editor).

As for current work underway in X.509, there is a Working Document which is
currently being revised to reflect the outcome of the September meeting. The
previous version of that document is available at:

ftp://ftp.bull.com/pub/OSIdirectory/Phoenix98Output/CertificateExtensionsWD.
doc

When the revisions are complete (within 2 months) the new version will
likely be found in:

ftp://ftp.bull.com/pub/OSIdirectory/Beijing98/Vancouver98/

These two documents provide a complete picture of the X.509 activity except
of course for defect reports. These are recorded together with the defects
on the other parts of the X.500 Series at the bull.com site, but at present
it is somewhat out of date (should be updated within 2 months as well).

Hope this helps.
Sharon

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	September 24, 1998 2:59 PM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	Re: X.509 Documentation
> 
> [email-masked] a écrit:
> 
> > Ladies and Gentlemen,
> >
> > Some body posted an address of a site where a document for X.509 can be
> > obtained.
> > Can that kind person post the information again?
> 
> Take a look at :ftp://ftp.bull.com/pub/OSIdirectory/
> 
> Denis
> 
> > Thanks,
> >
> > CryptoNEWS
> 
> 
> 

Date: Thu, 24 Sep 1998 14:41:23 +0200
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: NEW Data type for certificate selection ?
Sender: [email-masked]

All,

Comments, suggestions.

/Stefan Santesson

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: basic constraint extension
Reply-To: [email-masked]
Date: Thu, 24 Sep 1998 23:59:34 (NZST)
Sender: [email-masked]

>the draft-ietf-pkix-ipki-part1-10 says the basic constraint extension MUST 
>appear as a critical extension in all CA certificates but it SHOULD NOT 
>appear in end entity certificates.
>
>Why should the basic constraint extension not appear in end entity 
>certificates? 
 
Looking back through the different versions, this has been in there since at 
least -08, although not worded quite as strongly as this.  It seems like a Bad 
Thing, since this clashes with the (US) federal profile and Australian profile 
and... well I'm not going to enumerate them all, but unless there's some 
really good reason for it I don't see why it should be absent, especially 
since the generally accepted way (other profiles notwithstanding) seems to be 
to encode it as an empty sequence in end-user certs.
 
Peter.

Date: Thu, 24 Sep 1998 11:59:24 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: X.509 Documentation
Sender: [email-masked]

[email-masked] a écrit:

> Ladies and Gentlemen,
>
> Some body posted an address of a site where a document for X.509 can be
> obtained.
> Can that kind person post the information again?

Take a look at :ftp://ftp.bull.com/pub/OSIdirectory/

Denis

> Thanks,
> CryptoNEWS

Date: Thu, 24 Sep 1998 11:28:15 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael McNeil <[email-masked]>
CC: Stephen Kent <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], Jeffrey Schiller <[email-masked]>
Subject: Re: meeting minutes
Sender: [email-masked]

Michael,

As you say it, the minutes from the meeting are correct.

> Stephen Kent wrote:
> [snip]
> >NEW TOPICS:
> >- Timestamp & Notary proposals (Carlisle Adams)
> >
> >Several folks continuing work on these topics and have published
> >an independent draft on these topics. The authors received a fair
> >amount of private feedback, and hope to be able to bring forward a
> >well-formed proposal. Jeff Schiller gave his permission to bring
> >this into the WG, based on the WG having made substantial progress
> >on the other work items. Thus we will expand the charter to
> >encompass these topics.
>
> This is what occurred during the PKIX sessions at the 42nd IETF meeting
> with regards to timestamping; however the above is not the whole story.
>
> Between sessions at the IETF meeting I talked with various people about
> the new Internet-Draft (authored by Dave Mills, Todd Glassey, and me)
> which extends the NTP protocol towards serving as a vehicle for PKI
> certified and secured time ("ephemeral" time; "what time is it *now*?"
> time), as well as also providing for *timestamps* of data -- within the
> same protocol, essentially as gravy (a different usage, I admit).

>From your short description,  people might think that the two drafts are
equivalent. Let me highlight some of the main differences:

Let us call:

"draft 1", the draft:
ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt and
"draft 2", the draft:
ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt

Draft 1 is all in ASN1, as the rest of the other messages supported by PKIX,
e.g. CMP. So it is in the spirit of the other documents. On the contrary,
Draft 2 is supporting 32 bits words and is much more compact (unless that
advantage will be lost by many extensions !)

The time formats are different between draft 1 and 2. Draft 1 is using the
same time format as the rest of the PKIX documents, while draft 2 is using a
32 bits time representation.

Draft 1 supports the time stamping of an imprint and as a side effect, may
provide a trusted time when using the optional nonces.

Draft 2 is unclear about time stamping, in particular the indication of the
hash function used for the imprint and its protection. It allows various
extension fields and so the minimum format to be supported is left
undefined. It is also unclear about the replay protection when only the time
is returned (unless that information is present is some other documents ?).

> I spoke with Jeff Schiller about this.  After he'd had a chance to look
> over the Internet-Draft (i.e., <draft-mills-ntp-auth-coexist-01.txt>),
> we spoke again, very near the end of the IETF meeting.  Jeff at that
> time suggested that since it was now apparent to him that the issue of
> PKI and time goes well beyond the question of timestamps to the issue of
> how secure *time itself* can be conveyed over an insecure network, he
> thought that perhaps the PKIX working group was not equipped to properly
> address this expanded issue -- or at least Jeff thought the IESG ought
> to be consulted first on the question before the issue of PKIX handling
> it or a separate "time" working group being set up is laid to rest.

>From what is above, "draft 2" would not be usable in a PKIX environment,
where the compactness of the messages is not the issue, since the Time Stamp
will be used mostly either in a store and forward environment or in a local
environment.

However, there may be some good reasons to have a 32 bits oriented and more
compact protocol for acquiring a secure time for other environments and
therefore it can make sense to have two protocols.

> Thus the issue stands as far as I know.  I've addressed two e-mails to
> Jeff since the IETF meeting (on 8 and 21 September) but so far have not
> received a reply (I assume it takes time to poll the IESG membership).
> I have no particular stake in which way the decision goes (except I
> think *some* working group needs to address time *and* timestamping),

I am not sure that a *single* working group needs to address both time and
timestamping. As a good example, we have already have the PKIX and the SPKI
working groups: PKIX is using ASN.1, while SPKI does not. A similar
parallelism ! :-)

Regards,

Denis

> but wished to alert you that despite the outcome of the PKIX sessions,
> the question of whether PKIX handles it appears not quite settled.
>
> Regards,
> Michael McNeil
> GMT
> [email-masked]
> 1-831-438-7811

From: [email-masked]
Date: Thu, 24 Sep 1998 05:11:36 EDT
To: [email-masked]
Subject: X.509 Documentation
Sender: [email-masked]

Ladies and Gentlemen,

Some body posted an address of a site where a document for X.509 can be
obtained.
Can that kind person post the information again?

Thanks,

CryptoNEWS

Date: Wed, 23 Sep 1998 20:39:10 -0700
From: Michael McNeil <[email-masked]>
Organization: GMT
To: Stephen Kent <[email-masked]>, Warwick Ford <[email-masked]>
CC: [email-masked], Jeffrey Schiller <[email-masked]>
Subject: Re: meeting minutes
Sender: [email-masked]

Stephen Kent wrote:
[snip]
>NEW TOPICS:
>- Timestamp & Notary proposals (Carlisle Adams)
>
>Several folks continuing work on these topics and have published
>an independent draft on these topics. The authors received a fair
>amount of private feedback, and hope to be able to bring forward a
>well-formed proposal. Jeff Schiller gave his permission to bring
>this into the WG, based on the WG having made substantial progress
>on the other work items. Thus we will expand the charter to
>encompass these topics.

This is what occurred during the PKIX sessions at the 42nd IETF meeting
with regards to timestamping; however the above is not the whole story.

Between sessions at the IETF meeting I talked with various people about
the new Internet-Draft (authored by Dave Mills, Todd Glassey, and me)
which extends the NTP protocol towards serving as a vehicle for PKI
certified and secured time ("ephemeral" time; "what time is it *now*?"
time), as well as also providing for *timestamps* of data -- within the
same protocol, essentially as gravy (a different usage, I admit).

I spoke with Jeff Schiller about this.  After he'd had a chance to look
over the Internet-Draft (i.e., <draft-mills-ntp-auth-coexist-01.txt>),
we spoke again, very near the end of the IETF meeting.  Jeff at that
time suggested that since it was now apparent to him that the issue of
PKI and time goes well beyond the question of timestamps to the issue of
how secure *time itself* can be conveyed over an insecure network, he
thought that perhaps the PKIX working group was not equipped to properly
address this expanded issue -- or at least Jeff thought the IESG ought
to be consulted first on the question before the issue of PKIX handling
it or a separate "time" working group being set up is laid to rest.

Thus the issue stands as far as I know.  I've addressed two e-mails to
Jeff since the IETF meeting (on 8 and 21 September) but so far have not
received a reply (I assume it takes time to poll the IESG membership). 
I have no particular stake in which way the decision goes (except I
think *some* working group needs to address time *and* timestamping),
but wished to alert you that despite the outcome of the PKIX sessions,
the question of whether PKIX handles it appears not quite settled.

Regards,
Michael McNeil
GMT
[email-masked]
1-831-438-7811

Date: Wed, 23 Sep 1998 11:05:32 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
Sender: [email-masked]

I thought this might be of interest to the PKIX WG.

--Paul Hoffman, Director
--Internet Mail Consortium

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
>Date: Wed, 23 Sep 1998 10:43:01 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Transport Layer Security Working Group of 
>the IETF.
>
>	Title		: An Internet AttributeCertificate Profile 
>                          for Authorization
>	Author(s)	: S. Farrell
>	Filename	: draft-ietf-tls-ac509prof-00.txt
>	Pages		: 11
>	Date		: 22-Sep-98
>	
>   Authorization support is required for various Internet
>   protocols, for example, TLS, CMS and their consumers,
>   and others. The X.509 AttributeCertificate provides a
>   structure which can form the basis for such services
>   [X.509]. This specification defines two profiles (a
>   simple one and a 'full' one)  for the use of X.509
>   AttributeCertificates to provide such authorization
>   services.
>
>Internet-Drafts are 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-tls-ac509prof-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nis.garr.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[email-masked].  In the body type:
>	"FILE /internet-drafts/draft-ietf-tls-ac509prof-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.
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-tls-ac509prof-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt>

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Steve Kent'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>
Subject: Revised LDAPv2 specs have been submitted
Date: Wed, 23 Sep 1998 09:57:43 -0400
Sender: [email-masked]

A revision of the PKIX LDAPv2 protocol profile has been submitted and notice
should appear shortly. The only reason for this revision is because the
previous one (in the hands of the IESG pending submission of an accompanying
schema spec) exires this month. No changes other than updating version
number, date and the name of the ietf-pkix mail list were made.

A revision of the PKIX LDAPv2 schema I-D has been submitted and notice
should appear shortly. This revision addresses the comments submitted during
PKIX WG last call.

Sharon

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Wed, 23 Sep 1998 13:32:27 +0200
To: Al Arsenault <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Al,

I totally agree with everything you say in this last mail.

/Stefan

At 08:15 AM 9/22/98 -0400, Al Arsenault wrote:
>At 06:25 AM 9/22/98 +0200, Stefan Santesson wrote:
>>Al,
>>
>>Just a short reply to CA disaster (See below).
>>
>>Thanks for your reply, I still disagree to the disaster part.
>>
>>CA2 does not have to be dismanteled, since CA 2:s key is intact.
>>What has to be done is that:
>>- CA1 is rebuilt with new key
>>- The compromise of CA1 and its new key has to be communicated with
>>out-of-band means
>>- CA1 cross certify CA2 (and other CA:s) using the new key
>>- New cross certificates to CA1 has to be issued and published by other
CA:s.
>>
>>Now all certificates issued by CA2 before the disaster of CA1 can be used
>>and trusted.
>>This since the disaster of CA1 didn't destroy CA2, just the link to CA2
>>from CA1.
>>
>>/Stefan
>
>Stefan,
>
>	The more I think about this, the more I realize we agree.  It's the words
>that need figuring out. Perhaps the words in the draft roadmap are too
>strong; we'll have to think about that.
>
>	First, let me note that when CA1 and CA2 are cross-certified - that is,
>have a peer relationship, with neither subordinate to the other - I agree
>with you about what happens when CA1's key is compromised.
>
>	Now, let us assume that there is a hierarchical relationship - CA2 is
>subordinate to CA1. This means to me that the trust anchor used by end
>entities below CA2 is  not CA2 - it's CA1.  When CA1's key is discovered to
>be compromised, what you do is:
>
>	1 - communicate out of band the compromise. This means that CA2 and all
>entities below it are essentially "out of action" temporarily; since CA1 is
>the trust anchor, there's no way to construct a valid cert path
>
>	2 - reconstitute CA1 with a new key;
>
>	3 - get CA2's key to CA1 for certification (most likely through
>out-of-band means). Yes, this can still be the same key; since CA2's key
>wasn't compromised, it can still be used, and it will make things easier in
>that you don't have to go re-signing end-entity certs with a new CA2 key.
>
>Now, you're back in action.  
>
>If you agree that this is right, we can figure out words that say that.
>The point I wanted to convey is that the entire PKI is dead in this case
>until CA1 is brought up and a new CA2 cert is signed, because you can't
>construct a valid path back to a valid trust anchor.
>
>(Of course, if trust anchor's compromised key happens to be on all
>end-entity hardware tokens in a form that can't easily be changed, you've
>still got a problem, but that's beyond the scope of PKIX :-)
>
>				Al Arsenault
>
>- the above opinions are my own.  They may or may not reflect the opinions
>of my employer or of any other organization with which I have a relationship.
>
>
>
>
>

Date: Wed, 23 Sep 1998 10:03:55 -0700
From: Denis Pinkas <[email-masked]>
To: IETF-PXIX <[email-masked]>
Subject: Archive cutoff & Retention period
Sender: [email-masked]

Archive cutoff & Retention period

This item has been separated from my list of other comments since it
might start a new thread.

On page 12 there is section 5.4.4. named « Archive Cutoff ».

In part PKIX-1 on page 12, we have the following sentence: 

   An entry may be removed from
   the CRL after appearing on one regularly scheduled CRL issued
beyond
   the revoked certificate's validity period.

This means that a revoked entry has to stay at least "little bit"
after the expiration date of the certificate. In practice this is a
few days, but not necessarily years because the size of the
information to keep would be pretty big. So we need to make a
difference between a "retention period" of a few days and a possible
archiving of the status information during years (see later).

The "retention period" should be supported by all OCSP responders
and thus should be part of the standard response. Adding a
"retentionPeriod" after the "produceAt" from the ResponseData would
be simpler than defining an extension.

Then, let us address the « Archive Cutoff » issue.

If we were to support the archiving capability, with e.g. a 7 year
retention, we would need an additional time parameter in the request
to point to the equivalent of the right CRL issued at that time e.g.
7 years ago. This parameter is currently not present. Unless it is
added, the function cannot work. We thus have two options : add the
missing parameter or delete this capability. Opinions ? 

Denis

Date: Wed, 23 Sep 1998 09:59:40 -0700
From: Denis Pinkas <[email-masked]>
To: IETF-PXIX <[email-masked]>
Subject: Minor comments on OCSP-06
Sender: [email-masked]

Here are a few minor/editorial comments on OCSP-06. An additional
comment (on "Archive cutoff") has been separated from this list of
comments since it might generate a new thread. Some of them might be
a duplication of comments already made.

1. On page 2, in the second paragraph of the section 3 a sentence
may let think that once the OCSP server replies « good » the
certificate can be accepted. The only thing that is known is « not
revoked ». A better rewording would be : « An OCSP client issues a
status request to an OCSP responder and obtains a revocation status
of the certificate in question. »
 
2. On page 3, third paragraph before the bottom of the page. The
term « produceAt » is used but not yet introduced. For clarity of
reading a rephrasing should be made. Hereafter is a proposal : « At
the minimum, this positive response indicates that the certificate
is not revoked, but does not necessarily mean that the certificate
was ever issued or that the current time is within the certificate’s
validity interval ».
 
3. On page 3, second paragraph before the bottom of the page. « On
hold » is reason code under « revoke ». In the explanations it would
be nice to remember here that « on hold » is under this category.
Here is a proposal: « The « revoked » state indicates that the
certificate has been definitively or temporarily revoked (i.e.
placed on hold). »
 
4. On page 4, in the fifth paragraph of the section 3.3. the
response « certRequired » is of no use any more since only a CertId
can be placed in the request. Therefore it should be deleted. [This
comment has already be made].
 
5. On page 6, the fifth item of the section 4.2. states : « The
response is in its validity period ». It is unclear to understand
what this means. It may be guessed that it is the time interval
between the « thisUpdate » and « nextUpdate ». However in section
5.2.2.1. pages 9/10, nextUpdate is optional so this test cannot be
done in general. By splitting this item into two items, a better
wording would be :
 
6.  The time at which the status being indicated is known to be 
    correct (thisUpdate) is sufficiently recent.
 
7.  When available, the time at or before which newer information 
    will be available about the status of the certificate 
    (nextUpdate)is greater than the current time.
 
8. On page 8, in the same way  « certRequired (4)  » should be
deleted. [This comment has already be made]
 
9. On page 9, CRLReason should be expanded so that the « on hold »
status can be made visible. This is pretty important since by trying
again it is possible to get later on a « good » result. 
 
10. On page 11, The section 5.4 "Extensions" should be renumbered 6
in order to have a section dealing with all the optional extensions. 

Denis

From: "Todd S. Glassey" <[email-masked]>
To: "Ietf-Pkix" <[email-masked]>
Subject: Amending the PKIX-WG Charter to reflect the addition of timestamping
Date: Tue, 22 Sep 1998 19:17:57 -0700
Importance: Normal
Sender: [email-masked]

Hi All, back in February we were working to amend the PKI WG's charter to
encompass timestamping and the certified timer resources that enable these
facilities. Now that Jeff Schiller has OK'd PKIX's having its own
timestamping/timebase facility we need to finish the charter update process.
here then is a proposed charter for your review and comments.

Thanks,

-----

Todd Glassey

Stephen Kent's report of the meeting minutes - excerpt below -

- Timestamp & Notary proposals (Carlisle Adams)

Several folks continuing work on these topics and have published an
independent draft on
these topics. The authors received a fair amount of private feedback, and
hope to be able to
bring forward a well-formed proposal. Jeff Schiller gave his permission to
bring this into
the WG, based on the WG having made substantial progress on the other work
items. Thus
we will expand the charter to encompass these topics.

----- BEGINNING OF CHARTER TEXT ----

Public-Key Infrastructure (X.509) (PKIX)
--------------------------------------------------

 Charter
 Last Modified: September 18, 1998

 Current Status: Active Working Group

Chair(s):
Stephen Kent <[email-masked]>
Warwick Ford <[email-masked]>

Security Area Director(s):
Jeffrey Schiller <[email-masked]>
Marcus Leech <[email-masked]>

Security Area Advisor:
Jeffrey Schiller <[email-masked]>

Mailing Lists:
General Discussion:[email-masked]
To Subscribe: [email-masked]
In Body: subscribe (In Body)
Archive: http://www.imc.org/ietf-pkix

Description of Working Group:
Many Internet protocols and applications which use the Internet employ
public-key technology for security purposes and require a public-key
infrastructure (PKI) to securely manage public keys for widely-distributed
users or systems.  The X.509 standard constitutes a widely-accepted basis
for such
an infrastructure, defining data formats and procedures related to
distribution
of public keys via certificates digitally signed by certification
authorities
(CAs).

For example, RFC 1422 specified the basis of an X.509-based PKI, targeted
primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).
Since RFC 1422 was issued, application requirements for an Internet PKI have
broadened tremendously, and the capabilities of X.509 have advanced with the
development of standards defining the X.509 version 3 certificate and
version 2 certificate revocation list (CRL).

Charter of the Working Group:
The charter of the working group will be to develop Internet standards
needed to support the use of an X.509-based PKI.  The goal of this Working
Group (WG)
will be to further facilitate the use of X.509 certificates in applications
that
make use of the Internet and to promote interoperability between different
implementations choosing to make use of X.509 certificates.

The resulting PKI is intended to provide a framework, which will support a
range of trust/hierarchy environments and a range of usage environments
(RFC1422
is an example of one such model).

Candidate applications to be served by this PKI include, but are not limited
to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), IPSEC protocols, Internet
payment protocols, time based authentication, timestamping, and www
protocols.

This project will not preclude use of non-infrastructure public-key
distribution techniques nor of non-X.509 PKIs by such applications.  Efforts
will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
project.

The group will focus on tailoring and profiling the features available in
the v3 X.509 certificate to best match the requirements and characteristics
of the
Internet environment.

Other topics to be addressed potentially include:

     * Alternatives for CA-to-CA certification links and structures,
including
       guidelines for constraints

     * Revocation alternatives, including profiling of X.509 v2 CRL
extensions
     * Certificate and CRL distribution options (X.500-based,
non-X.500-based)
     * Guidelines for policy definition and registration
     * Administrative protocols and procedures, including certificate
       generation, revocation notification, cross-certification, and
key-pair
       updating
     * Naming and name forms (how entities are identified, e.g., email
       address, URN, DN, misc.)
     * Generation of client key pairs by the PKI
     * Services that support non-repudiation.  This can include sources of
       credible time data and/or certificate path validation services.

----- END OF CHARTER TEXT ----

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Steve Kent'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Subject: text for attributes
Date: Tue, 22 Sep 1998 08:28:14 -0400
Sender: [email-masked]

Although we have not reached specific wording which is 100% agreed by
everyone, we have reached agreement on what the contents of the
cACertificate and crossCertificatePair attributes are to be used for. In
order to bring this to closure, Santosh and I plan to go with the advice of
our co-chairs and proceed with the word 'realm', along with the
clarification that its meaning is defined locally and hope everyone will be
willing to live with that.

Also, this will be liaised to the X.509 group as the PKIX recommendation to
resolve the associated defect report in that standard.

Thanks to everyone for their input and I assume I'm not the only one looking
forward to a reduced amount of email each morning :-)

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Tue, 22 Sep 1998 08:15:43 -0400
To: Stefan Santesson <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Al Arsenault <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

At 06:25 AM 9/22/98 +0200, Stefan Santesson wrote:
>Al,
>
>Just a short reply to CA disaster (See below).
>
>Thanks for your reply, I still disagree to the disaster part.
>
>CA2 does not have to be dismanteled, since CA 2:s key is intact.
>What has to be done is that:
>- CA1 is rebuilt with new key
>- The compromise of CA1 and its new key has to be communicated with
>out-of-band means
>- CA1 cross certify CA2 (and other CA:s) using the new key
>- New cross certificates to CA1 has to be issued and published by other CA:s.
>
>Now all certificates issued by CA2 before the disaster of CA1 can be used
>and trusted.
>This since the disaster of CA1 didn't destroy CA2, just the link to CA2
>from CA1.
>
>/Stefan

Stefan,

	The more I think about this, the more I realize we agree.  It's the words
that need figuring out. Perhaps the words in the draft roadmap are too
strong; we'll have to think about that.

	First, let me note that when CA1 and CA2 are cross-certified - that is,
have a peer relationship, with neither subordinate to the other - I agree
with you about what happens when CA1's key is compromised.

	Now, let us assume that there is a hierarchical relationship - CA2 is
subordinate to CA1. This means to me that the trust anchor used by end
entities below CA2 is  not CA2 - it's CA1.  When CA1's key is discovered to
be compromised, what you do is:

	1 - communicate out of band the compromise. This means that CA2 and all
entities below it are essentially "out of action" temporarily; since CA1 is
the trust anchor, there's no way to construct a valid cert path

	2 - reconstitute CA1 with a new key;

	3 - get CA2's key to CA1 for certification (most likely through
out-of-band means). Yes, this can still be the same key; since CA2's key
wasn't compromised, it can still be used, and it will make things easier in
that you don't have to go re-signing end-entity certs with a new CA2 key.

Now, you're back in action.  

If you agree that this is right, we can figure out words that say that.
The point I wanted to convey is that the entire PKI is dead in this case
until CA1 is brought up and a new CA2 cert is signed, because you can't
construct a valid path back to a valid trust anchor.

(Of course, if trust anchor's compromised key happens to be on all
end-entity hardware tokens in a form that can't easily be changed, you've
still got a problem, but that's beyond the scope of PKIX :-)

				Al Arsenault

- the above opinions are my own.  They may or may not reflect the opinions
of my employer or of any other organization with which I have a relationship.

From: Anders Rundgren <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: OCSP - Public Key Dstribution
Date: Tue, 22 Sep 1998 13:30:44 +0200
Sender: [email-masked]

Denis,
> something that is nontrivial.   And "Certificate Domain" is also missing.

???
Certificate Domain is some kind of indication of what kind of certificate(s)
you want to validate.  I.e. like SET-certificates, a National ID-card, OBI-trader etc.
This could be of interest in both the request and in the response.  I.e. a trusted OCSP
server may support overlapping or disjunct domains and a typical subscriber
may be interested in just one type.  To standardize this seems unnecessary
in the same sense as defining trust models in OCSP.  It is a *deployment* issue
like certificate policies and liabilities.

Other extensions, like certificate validation might be considered
once OCSP is closed.

I assume that the "closing" of OCSP will be pretty theoretical when the definition
of extensions starts.  Already an IETF agenda item it seems

Regards
Anders

Date: Tue, 22 Sep 1998 11:26:49 +0200
From: "Petra Glöckner" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: basic constraint extension
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms6C21A3596B2679A5F64C275F
Content-Type: multipart/mixed; boundary="------------C84E92343668538B0D7F006C"

This is a multi-part message in MIME format.
--------------C84E92343668538B0D7F006C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

the draft-ietf-pkix-ipki-part1-10 says the basic constraint extension 
MUST appear as a critical extension in all CA certificates but it 
SHOULD NOT appear in end entity certificates.

Why should the basic constraint extension not appear in end entity 
certificates ? Is it purely to safe some bits or is there another
reason, like keeping the draft more flexibel, e.g. to allow an
end entity to issue a certificate for his encryption key himself using
his signature key and certificate ?

In general, is it possible for an end entity to use his signature key 
and certificate to issue a certificate for his encryption key himself ?
Or do you have to have the CA bit set to true in your certificate in
order to be able to issue certificates for your own encryption keys ?

Any ideas and thoughts are welcome !

Best regards - Petra
--------------C84E92343668538B0D7F006C
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Petra Glöckner
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Petra Glöckner
n:              ;Petra Glöckner
org:            GMD-TKT
email;internet: [email-masked]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------C84E92343668538B0D7F006C--

--------------ms6C21A3596B2679A5F64C275F
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms6C21A3596B2679A5F64C275F--

Date: Tue, 22 Sep 1998 06:25:35 +0200
To: Al Arsenault <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Al,

Just a short reply to CA disaster (See below).

Thanks for your reply, I still disagree to the disaster part.

CA2 does not have to be dismanteled, since CA 2:s key is intact.
What has to be done is that:
- CA1 is rebuilt with new key
- The compromise of CA1 and its new key has to be communicated with
out-of-band means
- CA1 cross certify CA2 (and other CA:s) using the new key
- New cross certificates to CA1 has to be issued and published by other CA:s.

Now all certificates issued by CA2 before the disaster of CA1 can be used
and trusted.
This since the disaster of CA1 didn't destroy CA2, just the link to CA2
from CA1.

/Stefan

At 01:32 PM 9/21/98 -0400, Al Arsenault wrote:
>Stefan,
>
>	Thanks for your comments.  Responses in line (Sean can make changes to the
>draft as appropriate).
>
>
>At 04:19 PM 9/21/98 +0200, Stefan Santesson wrote:
>>Al,
>>
>>I finally got time to look a little bit deeper into the roadmap document.
>>I think it is very well formed but I have some minor disagreements.
>>
>>1) Concerning definition and use of the term Root CA
>>2) Result from CA compromise
>>3) Use of certificates.
>>
>>1 - Root CA
>>---------
>>Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives
>>the impression that Root CA is at the top of some hierarchy. 
>>
>>This does not seem to harmonize with the definition of root CA in
>>"Certificate Management Protocols"
>>
>>  "We use the term "root CA" to indicate a CA that is directly trusted by 
>>   an end entity; that is, securely acquiring the value of a root CA public 
>>   key requires some out-of-band step(s). This term is not meant to imply 
>>   that a root CA is necessarily at the top of any hierarchy, simply that 
>>   the CA in question is trusted directly."
>>
>>So in fact every CA in a domain is likely to be "root" for some of its
>>subscribers.
>>I personally prefer the rem "Top CA" when describing a hierarchy.
>>
>
>You are correct; I was using the term "rootCA" to indicate the top of a
>hierarchy (possibly, a hierarchy of depth one - two counting the end
>entity).  That is inconsistent with CMP.  We'll have to resolve that.  I
>personally prefer using the term "rootCA" to mean the top of a hierarchy,
>and "trust anchor" to mean the CA that the end-entity directly trusts.  But
>we'll figure out something - "topCA" is probably feasible for now.
>
>
>>
>>2 - CA compromise
>>------------------
>>In section 3.4.5 it is said that compromise of a root CA is always
>>catastrophic and that the entire infrastructure subordinate to that root CA
>>has to be dismantled and started over again. This gives the impression that
>>a subordinate CA has to be dismatled.
>>
>>My comment is that 
>>a) Since the rootCA does not denote any hierarchy we can't define which CA
>>that is subordinate or not to a specific root CA
>>b) A compromised CA does only require that particular CA to be dismantled.
>>No other non-compromised CA has to be dismantled. Other CA:s has to revoke
>>cross certificates to th compromised CA and all subscribers using the
>>compromised CA as root CA, are totally cut off until they get another
>>rootCA key, but that's another aspect.
>>
>
>Your comment (a) is correct, given the different meaning of "rootCA" that I
>didn't catch earlier.  However, I disagree with part of your comment (b).
>That to me goes to the heart of a "CA Certificate" vs. a
>"Cross-certificate".  
>
>Suppose that CA2 has no self-signed certificates (it might have a
>self-issued certificate for key management, but that's not relevant at this
>point). CA2's CA certificate is issued and signed by CA1.  Thus, CA2 is
>subordinate to CA1.  Now, if CA1's private key is compromised, then CA2
>must be "dismantled".  That is, there is no reliable way for an outside
>entity to know whether CA2's cert was legitimately issued prior to the
>compromise of CA1's key, or whether CA2's cert was signed by the malicious
>party now holding the copy of CA1's private key.  The only thing you can do
>is kill CA2 and start over with a new cert issued by the new, re-installed
>CA1.  (Not to mention the mechanical problem of constructing a valid cert
>path going through CA2 to the valid CA1:-). Of course, "dismantling" is a
>strong word; you'd have to rebuild CA1 with a new key, and sign a new
>certificate for CA2 using the new, un-compromised key.  You wouldn't
>necessarily need to erase CA2's database, train new people, buy a new
>hardware platform, etc. :-)
>
>With a cross-certificate, as you point out, there's no need to do anything
>over than revoke the cross-cert CA2 has issued for CA1 (if there is one).
>
>
>>3 - Certificate usage
>>---------------------
>>Section 3.1 states that:
>>"Certificates is used in the process of validating signed data."
>>This definition is leaving out any use for the purpose of encryption. I.e.
>>data encryption, key agreement and key exchange.
>>
>
>Agreed.
>
>
>				Al Arsenault
>
>- the above opinions are my own.  They may or may not reflect the opinions
>of my employer or of any other organization with which I have a relationship.
>
>
>
>
>

Date: Mon, 21 Sep 1998 13:32:57 -0400
To: Stefan Santesson <[email-masked]>, Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Al Arsenault <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Stefan,

	Thanks for your comments.  Responses in line (Sean can make changes to the
draft as appropriate).

At 04:19 PM 9/21/98 +0200, Stefan Santesson wrote:
>Al,
>
>I finally got time to look a little bit deeper into the roadmap document.
>I think it is very well formed but I have some minor disagreements.
>
>1) Concerning definition and use of the term Root CA
>2) Result from CA compromise
>3) Use of certificates.
>
>1 - Root CA
>---------
>Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives
>the impression that Root CA is at the top of some hierarchy. 
>
>This does not seem to harmonize with the definition of root CA in
>"Certificate Management Protocols"
>
>  "We use the term "root CA" to indicate a CA that is directly trusted by 
>   an end entity; that is, securely acquiring the value of a root CA public 
>   key requires some out-of-band step(s). This term is not meant to imply 
>   that a root CA is necessarily at the top of any hierarchy, simply that 
>   the CA in question is trusted directly."
>
>So in fact every CA in a domain is likely to be "root" for some of its
>subscribers.
>I personally prefer the rem "Top CA" when describing a hierarchy.
>

You are correct; I was using the term "rootCA" to indicate the top of a
hierarchy (possibly, a hierarchy of depth one - two counting the end
entity).  That is inconsistent with CMP.  We'll have to resolve that.  I
personally prefer using the term "rootCA" to mean the top of a hierarchy,
and "trust anchor" to mean the CA that the end-entity directly trusts.  But
we'll figure out something - "topCA" is probably feasible for now.

>
>2 - CA compromise
>------------------
>In section 3.4.5 it is said that compromise of a root CA is always
>catastrophic and that the entire infrastructure subordinate to that root CA
>has to be dismantled and started over again. This gives the impression that
>a subordinate CA has to be dismatled.
>
>My comment is that 
>a) Since the rootCA does not denote any hierarchy we can't define which CA
>that is subordinate or not to a specific root CA
>b) A compromised CA does only require that particular CA to be dismantled.
>No other non-compromised CA has to be dismantled. Other CA:s has to revoke
>cross certificates to th compromised CA and all subscribers using the
>compromised CA as root CA, are totally cut off until they get another
>rootCA key, but that's another aspect.
>

Your comment (a) is correct, given the different meaning of "rootCA" that I
didn't catch earlier.  However, I disagree with part of your comment (b).
That to me goes to the heart of a "CA Certificate" vs. a
"Cross-certificate".  

Suppose that CA2 has no self-signed certificates (it might have a
self-issued certificate for key management, but that's not relevant at this
point). CA2's CA certificate is issued and signed by CA1.  Thus, CA2 is
subordinate to CA1.  Now, if CA1's private key is compromised, then CA2
must be "dismantled".  That is, there is no reliable way for an outside
entity to know whether CA2's cert was legitimately issued prior to the
compromise of CA1's key, or whether CA2's cert was signed by the malicious
party now holding the copy of CA1's private key.  The only thing you can do
is kill CA2 and start over with a new cert issued by the new, re-installed
CA1.  (Not to mention the mechanical problem of constructing a valid cert
path going through CA2 to the valid CA1:-). Of course, "dismantling" is a
strong word; you'd have to rebuild CA1 with a new key, and sign a new
certificate for CA2 using the new, un-compromised key.  You wouldn't
necessarily need to erase CA2's database, train new people, buy a new
hardware platform, etc. :-)

With a cross-certificate, as you point out, there's no need to do anything
over than revoke the cross-cert CA2 has issued for CA1 (if there is one).

>3 - Certificate usage
>---------------------
>Section 3.1 states that:
>"Certificates is used in the process of validating signed data."
>This definition is leaving out any use for the purpose of encryption. I.e.
>data encryption, key agreement and key exchange.
>

Agreed.

				Al Arsenault

- the above opinions are my own.  They may or may not reflect the opinions
of my employer or of any other organization with which I have a relationship.

Date: Mon, 21 Sep 1998 12:20:00 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: meeting minutes
Sender: [email-masked]

--============_-1305727475==_ma============
Content-Type: text/plain; charset="us-ascii"

Folks,

I apologize for not having mailed these sooner, for review.  They were done
by Friday, of IETF week, but then got lost in an avalanche of travel and
e-mail.  Please review and respond to me with corrections by the end of
this week.

Thanks,

Steve

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

	PKIX WG Meeting Minutes 8/26-27/98

The PKIX WG met twice during the 42nd IETF and a approximately 190
individuals participated in these meetings.

The meeting began with a review of the status of all of the WG document,
presented by
Warwick Ford, WG co-chair. The following text summarizes the status of the
documents:

PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG
Last Call

KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to
completion by Editors

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for WG
last call

LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2 Schema

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last call

OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF
(draft-ietf-pkix-crmf-01.txt) - In hands
of IESG; pending IESG last call

CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt) -
In WG last
call

Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt)
- In SA Director's
hands, pending publication as Informational RFC

REVIEWS OF ESTABLISHED PROJECTS:

- PKIX Certificate and CRL Profile (Tim Polk)

Ready for IESG ballot, after receipt of minor editorial comments during
IETF last call.
Straw polls used to resolve last few contentious issues, specifically
mandating use of DNs
for all Issuers, and mandating use of strict subtrees for the
NameConstraints extension.
Jeff Schiller noted that the IETF web site has pointers to the Entrust
license required for
inclusion of CRL distribution point within this document.  The license is
easy to execute;
there is a reciprocity clause that requires licensing to Entrust  any
intellectual property
associated with CRL distribution, as a side effect of

- KEA and ECDS Algorithms (Tim Polk)

Work on these algorithm IDs continues, subject to resolution of some
intellectual property
issues.

- LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh Chokhani)

Most of the schema are not controversial; outstanding issues is whether all
CA certificates
should appear in the cross certificate directory attribute, or whether
certificates that are
internal to a domain should appear in the CA certificate attribute.  There
is consensus that
any self-signed CA certificates belong in the latter attribute.  The
disagreement here
revolves around alternative certificate validation algorithms; both
approaches have been
implemented and both work, each favoring a different PKI model. The CA
certificate
attribute has been a feature of X.509 for a long while, so the proposal to
move all (non-
self-signed) CA certificates to the cross CA certificate attribute
represents a non-backward
compatible change for systems not making use of cross certificates.  Still,
this is the
direction currently being pursued by the X.509 committee in resolving this
ambiguity in the
original standard.

Performance analysis of 6 different approaches, under varying assumptions
of PKI
models, shows that putting all (non-self signed) CA certificates in the
cross certificate
attribute results in worse performance.

We can make a decision now to get this long overdue schema out, or postpone
and discuss
more (since this is a newly discovered issue).  (Although this discussion
is taking place in
the context of LDAP v2, the same issue arises in LDAP v3.  However, v3 has
better
filtering capabilities and this it is believed that the issue would be less
of a concern, but this
is not universally agreed upon.) Work on LDAP v3 is progressing in the
IETF, and so if
we postpone action on this ID, it may be OBE and we will need to focus on
v3 instead.

Proposed compromise approach is to duplicate intra-domain CA certificates
in both
attributes (#4 in Santosh's analysis posted to the WG list), and which has
very good
overall performance. One objection raised to this is that it can result in
added data sent back
if one retrieves both attribute contents. Straw poll conducted resulted on
no clear winner,
but the two finalists are the proposed compromise and the older, backward
compatible
approach; the WG rejected the proposal from the current LDAP schema.

- OCSP (Tim Myers and Ambrish Malpani)

Various minor, but technically important, edits to many parts of the
document, in response
to comments from the WG list. Changes included a uniform key identifier,
optional use of
TLS/SSL for privacy protection of exchanges, etc. An objection was raised
to mandating
use of a signature, when a lower layer protocol might be used to provide
security.  A straw
poll overwhelmingly supported the mandatory use of signatures of in OCSP.
Thus there
appears to be no outstanding significant technical issues at this time. A
separate OCSP response extensions document will be created to define
additional responses

- CMP and CRMF

In IESG last call. No further status to report.

- CMMF and CMC (Mike Myers)

The CMMF draft has completed WG last call, minor changes have been made in
response to comments received during last call, it and will be forwarded to
the IESG. CMC also has completed WG last call, and undergone changes in
response to comments received during that process.  Pending approval of
secure initialization issues briefed at this meeting, the document will be
forwarded to the IESG. The secure initialization requirements for CMC
include use of a shared secret in a keyed hash calculation, with this
secret distributed via a confidentiality-secure channel.  However,
objections were raised to defining this as the only way to achieve secure
initialization, e.g., as opposed to use of SecurID cards or S-KEY
authentication in the context of an integrity and confidentiality secure
channel. It seems likely that additional mechanisms should be allowed, but
there is a desire to avoid an explosion of allowed user authentication
techniques, which would hinder interoperability or greatly burden CA
software.  This issue will be brought to the list for resolution.

- IBM PKIX Software Distribution (Charlie Kaufman)

IBM is implementing PKIX technology and making it available  for use in
products, as
well as in R&D environments.  Code is a mix of C++ software plus Java GUIs.
Provided
facilities include CMP, CRMF, LDAP, basic CA and RA functions, and client
certificate
processing.  No crypto is included in the distribution; the software makes
calls to a CAPI.
The first release relies on the Cylink cyrpto toolkit, which also will be
available via this
web site; later version will also make use of BSAFE. Initial distribution
is via an MIT web
site and is not exportable.  A pointer for a mailing list was provided:
[email-masked].

NEW TOPICS:

- Timestamp & Notary proposals (Carlisle Adams)

Several folks continuing work on these topics and have published an
independent draft on
these topics.  The authors received a fair amount of private feedback, and
hope to be able to
bring forward a well-formed proposal. Jeff Schiller gave his permission to
bring this into
the WG, based on the WG having made substantial progress on the other work
items. Thus
we will expand the charter to encompass these topics.

- Web-based Integrated CA services Protocol (Mine Sakurai)

This presentation describes use of HTTP as an underlying communication
protocol among CAs, RAs, etc.  The underlying model also defines issuing,
validation, and publishing authority modules within the CA.  ICAP has been
implemented for use with S/MIME in a medical information system in Japan.
An I-D has been published describing ICAP: draft-ietf-????.  It was noted
that the acronym "ICAP" is already in use by a calendar protocol, so
another protocol acronym would be appropriate.

- Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick Ford)

There is an I-D describing alternatives CRL distribution technique, which
was developed in response to the intellectual property problem that
temporarily prevented use of the CRL distribution point mechanism. The CRL
format can be extended to specify the scope of the CRL, e.g., by serial
number range, as an alternative to placing the pointer in the certificate.
To address the CRL location aspect of CRL distribution points, one also can
establish CRL managers that are either locally trusted or that represent a
separate CRL distribution channel, perhaps serving multiple CAs. By adding
two new CRL extensions, one can extend the CRL distribution model in
interesting new ways.  These suggestions are being forwarded to ISO for
consideration. See the latest I-D, under the PKIX, for more details.

- PKIX Roadmap (Al Arsenault)

The set of PKIX documents has become rather large and potentially
confusing.  An outline
was presented as a basis for a document that would become an informational
RFC, to help
explain the relationships among these documents, and to other efforts,
e.g., SPKI.  An
initial draft is ready and will be made available immediately after this
IETF meeting.

- Qualified Certificates (Stefan Santesson)

In EC a legal framework for "qualified certificates" is being developed,
referring to individual certificates that will be accepted for legally
binding, international transactions, and with legal liability implications
for the CAs issuing such certificates.  (These certificates are used only
for non-repudiation.) It is analogous to some of the work under UNICTRAL
for EDI. For PKIX, the potential work item would be a profile for such
certificates, specifying which extensions are mandatory and optional,
establishing values and semantics for some of the extensions. For example,
one might mandate use of the policy extension with a specific value to
identify such certificates, with policy qualifiers to express additional
characteristics of policy variants, appropriate key usage flags, naming
schema constraints, etc.
--============_-1305727475==_ma============
Content-Type: text/enriched; charset="us-ascii"

Folks,

I apologize for not having mailed these sooner, for review.  They were
done by Friday, of IETF week, but then got lost in an avalanche of
travel and e-mail.  Please review and respond to me with corrections by
the end of this week.

Thanks,

Steve

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

	<fontfamily><param>Times</param><bigger><bigger>PKIX WG Meeting
Minutes 8/26-27/98

The PKIX WG met twice during the 42nd IETF and a approximately 190

individuals participated in these meetings.

The meeting began with a review of the status of all of the WG
document, presented by 

Warwick Ford, WG co-chair. The following text summarizes the status of
the documents:

PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG
Last Call

KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to
completion by Editors

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for
WG last call

LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2
Schema

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last
call

OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF
(draft-ietf-pkix-crmf-01.txt) - In hands 

of IESG; pending IESG last call

CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt)
- In WG last 

call

Certificate Policy/Practices Guideline
(draft-ietf-pkix-ipki-part4-03.txt) - In SA Director's 

hands, pending publication as Informational RFC

REVIEWS OF ESTABLISHED PROJECTS:

- PKIX Certificate and CRL Profile (Tim Polk)

Ready for IESG ballot, after receipt of minor editorial comments during
IETF last call.  

Straw polls used to resolve last few contentious issues, specifically
mandating use of DNs 

for all Issuers, and mandating use of strict subtrees for the
NameConstraints extension. 

Jeff Schiller noted that the IETF web site has pointers to the Entrust
license required for 

inclusion of CRL distribution point within this document.  The license
is easy to execute; 

there is a reciprocity clause that requires licensing to Entrust  any
intellectual property 

associated with CRL distribution, as a side effect of 

- KEA and ECDS Algorithms (Tim Polk)

Work on these algorithm IDs continues, subject to resolution of some
intellectual property 

issues.

- LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh
Chokhani)

Most of the schema are not controversial; outstanding issues is whether
all CA certificates 

should appear in the cross certificate directory attribute, or whether
certificates that are 

internal to a domain should appear in the CA certificate attribute. 
There is consensus that 

any self-signed CA certificates belong in the latter attribute.  The
disagreement here 

revolves around alternative certificate validation algorithms; both
approaches have been 

implemented and both work, each favoring a different PKI model. The CA
certificate 

attribute has been a feature of X.509 for a long while, so the proposal
to move all (non-

self-signed) CA certificates to the cross CA certificate attribute
represents a non-backward 

compatible change for systems not making use of cross certificates. 
Still, this is the 

direction currently being pursued by the X.509 committee in resolving
this ambiguity in the 

original standard.

Performance analysis of 6 different approaches, under varying
assumptions of PKI 

models, shows that putting all (non-self signed) CA certificates in the
cross certificate 

attribute results in worse performance.

We can make a decision now to get this long overdue schema out, or
postpone and discuss 

more (since this is a newly discovered issue).  (Although this
discussion is taking place in 

the context of LDAP v2, the same issue arises in LDAP v3.  However, v3
has better 

filtering capabilities and this it is believed that the issue would be
less of a concern, but this 

is not universally agreed upon.) Work on LDAP v3 is progressing in the
IETF, and so if 

we postpone action on this ID, it may be OBE and we will need to focus
on v3 instead.

Proposed compromise approach is to duplicate intra-domain CA
certificates in both 

attributes (#4 in Santosh's analysis posted to the WG list), and which
has very good 

overall performance. One objection raised to this is that it can result
in added data sent back 

if one retrieves both attribute contents. Straw poll conducted resulted
on no clear winner, 

but the two finalists are the proposed compromise and the older,
backward compatible 

approach; the WG rejected the proposal from the current LDAP schema.

- OCSP (Tim Myers and Ambrish Malpani)

Various minor, but technically important, edits to many parts of the
document, in response 

to comments from the WG list. Changes included a uniform key
identifier, optional use of 

TLS/SSL for privacy protection of exchanges, etc. An objection was
raised to mandating 

use of a signature, when a lower layer protocol might be used to
provide security.  A straw 

poll overwhelmingly supported the mandatory use of signatures of in
OCSP.  Thus there 

appears to be no outstanding significant technical issues at this time.
A separate OCSP response extensions document will be created to define
additional responses 

- CMP and CRMF

In IESG last call. No further status to report.

- CMMF and CMC (Mike Myers)

The CMMF draft has completed WG last call, minor changes have been made
in response to comments received during last call, it and will be
forwarded to the IESG. CMC also has completed WG last call, and
undergone changes in  response to comments received during that
process.  Pending approval of secure initialization issues briefed at
this meeting, the document will be forwarded to the IESG. The secure
initialization requirements for CMC include use of a shared secret in a
keyed hash calculation, with this secret distributed via a
confidentiality-secure channel.  However, objections were raised to
defining this as the only way to achieve secure initialization, e.g.,
as opposed to use of SecurID cards or S-KEY authentication in the
context of an integrity and confidentiality secure channel. It seems
likely that additional mechanisms should be allowed, but there is a
desire to avoid an explosion of allowed user authentication techniques,
which would hinder interoperability or greatly burden CA software. 
This issue will be brought to the list for resolution.

- IBM PKIX Software Distribution (Charlie Kaufman)

IBM is implementing PKIX technology and making it available  for use in
products, as 

well as in R&D environments.  Code is a mix of C++ software plus Java
GUIs. Provided 

facilities include CMP, CRMF, LDAP, basic CA and RA functions, and
client certificate 

processing.  No crypto is included in the distribution; the software
makes calls to a CAPI. 

The first release relies on the Cylink cyrpto toolkit, which also will
be available via this 

web site; later version will also make use of BSAFE. Initial
distribution is via an MIT web 

site and is not exportable.  A pointer for a mailing list was provided:
[email-masked].

NEW TOPICS:

- Timestamp & Notary proposals (Carlisle Adams)

Several folks continuing work on these topics and have published an
independent draft on 

these topics.  The authors received a fair amount of private feedback,
and hope to be able to 

bring forward a well-formed proposal. Jeff Schiller gave his permission
to bring this into 

the WG, based on the WG having made substantial progress on the other
work items. Thus 

we will expand the charter to encompass these topics.

- Web-based Integrated CA services Protocol (Mine Sakurai)

This presentation describes use of HTTP as an underlying communication
protocol among CAs, RAs, etc.  The underlying model also defines
issuing, validation, and publishing authority modules within the CA. 
ICAP has been implemented for use with S/MIME in a medical information
system in Japan.  An I-D has been published describing ICAP:
draft-ietf-????.  It was noted that the acronym "ICAP" is already in
use by a calendar protocol, so another protocol acronym would be
appropriate.

- Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick
Ford)

There is an I-D describing alternatives CRL distribution technique,
which was developed in response to the intellectual property problem
that temporarily prevented use of the CRL distribution point mechanism.
The CRL format can be extended to specify the scope of the CRL, e.g.,
by serial number range, as an alternative to placing the pointer in the
certificate.  To address the CRL location aspect of CRL distribution
points, one also can establish CRL managers that are either locally
trusted or that represent a separate CRL distribution channel, perhaps
serving multiple CAs. By adding two new CRL extensions, one can extend
the CRL distribution model in interesting new ways.  These suggestions
are being forwarded to ISO for consideration. See the latest I-D, under
the PKIX, for more details.

- PKIX Roadmap (Al Arsenault)

The set of PKIX documents has become rather large and potentially
confusing.  An outline 

was presented as a basis for a document that would become an
informational RFC, to help 

explain the relationships among these documents, and to other efforts,
e.g., SPKI.  An 

initial draft is ready and will be made available immediately after
this IETF meeting.

- Qualified Certificates (Stefan Santesson)

In EC a legal framework for "qualified certificates" is being
developed, referring to individual certificates that will be accepted
for legally binding, international transactions, and with legal
liability implications for the CAs issuing such certificates.  (These
certificates are used only for non-repudiation.) It is analogous to
some of the work under UNICTRAL for EDI. For PKIX, the potential work
item would be a profile for such certificates, specifying which
extensions are mandatory and optional, establishing values and
semantics for some of the extensions. For example, one might mandate
use of the policy extension with a specific value to identify such
certificates, with policy qualifiers to express additional
characteristics of policy variants, appropriate key usage flags, naming
schema constraints, etc. </bigger></bigger></fontfamily>

--============_-1305727475==_ma============--

Date: Mon, 21 Sep 1998 16:19:49 +0200
To: Sean Turner <[email-masked]>, PKIX <[email-masked]>, "Arsenault, Al W." <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX Roadmap
Sender: [email-masked]

Al,

I finally got time to look a little bit deeper into the roadmap document.
I think it is very well formed but I have some minor disagreements.

1) Concerning definition and use of the term Root CA
2) Result from CA compromise
3) Use of certificates.

1 - Root CA
---------
Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives
the impression that Root CA is at the top of some hierarchy. 

This does not seem to harmonize with the definition of root CA in
"Certificate Management Protocols"

  "We use the term "root CA" to indicate a CA that is directly trusted by 
   an end entity; that is, securely acquiring the value of a root CA public 
   key requires some out-of-band step(s). This term is not meant to imply 
   that a root CA is necessarily at the top of any hierarchy, simply that 
   the CA in question is trusted directly."

So in fact every CA in a domain is likely to be "root" for some of its
subscribers.
I personally prefer the rem "Top CA" when describing a hierarchy.

2 - CA compromise
------------------
In section 3.4.5 it is said that compromise of a root CA is always
catastrophic and that the entire infrastructure subordinate to that root CA
has to be dismantled and started over again. This gives the impression that
a subordinate CA has to be dismatled.

My comment is that 
a) Since the rootCA does not denote any hierarchy we can't define which CA
that is subordinate or not to a specific root CA
b) A compromised CA does only require that particular CA to be dismantled.
No other non-compromised CA has to be dismantled. Other CA:s has to revoke
cross certificates to th compromised CA and all subscribers using the
compromised CA as root CA, are totally cut off until they get another
rootCA key, but that's another aspect.

3 - Certificate usage
---------------------
Section 3.1 states that:
"Certificates is used in the process of validating signed data."
This definition is leaving out any use for the purpose of encryption. I.e.
data encryption, key agreement and key exchange.

Regards
/Stefan

Date: Mon, 21 Sep 1998 09:18:44 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Anders Rundgren <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: OCSP - Public Key Dstribution
Sender: [email-masked]

Anders Rundgren a écrit:
 
> Salut Denis,

This sounds a little bit familiar to me. :-(
Please do not mix French and English.

> Pardon my ignorance but does a returned issuerKeyHash give you the
> possibility to verify a certificate signature *after* its status has been checked?

Yes.

> Don't you need the original (unhashed) issuer public key to to that?

You can get it after the OCSP request.

 > I.e. does this enhanced OCSP draft essentially support my
suggested OCSP++
> (previously I called it OCVP) system *without* requiring extensions?  That would be
> just fantastic!

I took a look at the URL address you are providing. Since the
description is pretty short, it is hard to answer your question.
However the text says "an easy-to-use system for checking status
and validity of a certificate." In this version of OCSP, there is
no intent for checking the validity of the certificate but only its
revocation/on-hold status. Checking the status would be far more
complicated and controversial.  

Denis

> http://www.jaybis.com/specifications/pkix/ocsp.html
> 
> Please enlighten me!
> 
> Regards
> Anders Rundgren
> 
> ----------
> From:  Denis Pinkas [SMTP:[email-masked]]
> Sent:  Saturday, September 19, 1998 02:15
> To:  Andreas Berger
> Cc:  Peter Sylvester; [email-masked]; [email-masked]
> Subject:  Re: fast review of draft-ietf-pkix-ocsp-06.txt
> 
> Andreas,
> 
> I share your concerns.
> 
> The current definition of CertId is as follows:
> 
>    CertID          ::=     SEQUENCE {
>        hashAlgorithm       AlgorithmIdentifier,
>        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
>        issuerKeyHash       OCTET STRING, -- Hash of Issuers public
> key
>        serialNumber        CertificateSerialNumber }
> 
> CertID is used both in the request and in the response.
> I would suggest to change it to:
> 
>    CertID          ::=     SEQUENCE {
>        hashAlgorithm       AlgorithmIdentifier,
>        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
>        issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of
> Issuers public key
>        serialNumber        CertificateSerialNumber }
> 
> making the issuerKeyHash optional.
> 
> The issuerKeyHash would be optional for a request but mandatory for
> a response. The rational is as follows: the requester needs "at
> some time" to get the public key of the issuer in order to verify
> the certificate. If we mandate that field to be always present
> thent it must get it *before* the request to the OCSP server. If we
> make it optional, then it may get it before or after the request to
> the OCSP server. This gives some flexibility, without too many
> options.
> 
> The OCSP server should anyway have the Issuers public key and thus
> its hash. The hash may allow the requester to disambigous some
> responses in case of anonymity.
> 
> Denis
> 
> > I agree with this discussion and would like to add some thoughts:
> >
> > Peter Sylvester wrote:
> > > > I actually think OCVP is a bigger thing than just making the hash
> > > > of the issuer's PUBLIC key NULL. That whole topic should be
> > > > addressed at one shot
> > > >
> > > I am *not* really talking about OCVP, I am talking about 'CertID',
> > > a short way to identify a certificate. The syntax
> > > for the identification should be flexible enough
> > >
> > > - not to require more than the original certificate in
> > >   order to construct the identification.
> > The is a very good assumption. While the authority key *may* be
> > available, it certainly isn´t always available.
> >
> > > - to allow identification of a certificate in a given context
> > >   ==> serial number for example or/and hash of cert
> > The serial number is a little bit weaker but supported by other parts of
> > X.509, PKIX and several mail protocols, using issuer/serial for
> > identification of a certificate. So issuer/serial or
> > issuer/certificate-hash look like valid combinations. It may be a good
> > idea to be able add a subject public key hash if necessary.
> >
> > > - to allow the OCSP provider to find the source of
> > >   information provider.
> > >   ==> name of issuer may be necessary, hash of issuer name
> > >       may not be sufficient.
> > So for identification of issuer we probably have a choice of issuer-name
> > or issuer-hash, probably in combination with issuer-public-key or
> > issuer-public-key-hash as an optional parameter.
> >
> > > - to ensure that the creator of the certificate really has
> > >   a copy of a cert.
> > >   ==> hash of cert for example, or serialnumber if authority
> > >       allocates them in a sparse way.
> > > If we assume that the orginal version of OCSP where it was
> > > possible to just have a cert did make sense, thus I do not
> > > see why there is a need for the issuer public key extract
> > > in the certID. At least it should be optional in some way.
> > >
> > > It seems useful to me to fix a syntax for CertID that
> > > is sufficiently open for extensions without requiring
> > > a new protocol version..
> >
> > The removal of the certificate proper as a means to "identify" a
> > certificate forced us to specify an extension to OCSP to do this
> > (transport the certificate in the request - optional, or in the reply -
> > optional). If the consensus is that OCSP should not be able to transport
> > the certificate proper, I think we should at least open the possibility
> > to transport a certitficate hash.
> >
> > That leads me back to the idea of making a lot of the identification
> > parameters in "CertID" optional. But we will get serious
> > interoperability issues. So either we build specific CertIDs with
> > specific purposes in mind or we need some profiling (and probably a
> > means for the responder to transport valid combinations back to the
> > client).
> >
> > Andreas
> > --
> > Fifty-three percent of Fortune 1000 executives think the
> > Arch Deluxe is something that helps to run a computer.
> > -- Jericho Communications
> 
> --
>  Denis Pinkas     Bull S.A.          mailto:[email-masked]
>  Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>  78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 21 Sep 1998 09:29:41 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

Michael,

I first suggest that you re-read my last proposal from Friday which
does not contradicts your rational but contradicts your conclusion.

> All,
> 
> The intent was to provide an alternative to CRLs.  Following that model,
> there's an underlying assumption that the end-entity is in possession of
> the CA's certificate (as would be needed to validate the signature on a CRL.)

Yes, the underlying assumption that the end-entity has to get the
CA's public key or certificate. But, we should not make any
assumption whether that information must be obtained BEFORE or
AFTER the OCSP request.
 
> OCSP never had a requirement to validate an end-entity certificate in the
> absence of the CA certificate at the requestor end.  It's not just a
> requirement on syntax at the request.  This would also imply path
> validation logic on the server.  The consensus has been conclusively
> established that full certificate validation is beyond the scope of this
> protocol.

I strongly agree with your last sentence.

> There's consequently no need to alter the request syntax.

I respectfully disagree with your conclusion.

Denis
 
> Mike

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

To: [email-masked]
Subject: Re: Testing the ASN.1 in Part 1
Date: Mon, 21 Sep 1998 10:08:16 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

Just another minor point: id-ad, id-ad-ocsp and id-ad-caIssuers are defined in
both PKIX1Implicit88 and PKIX1Explicit88.

-- 
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

From: Peter Sylvester <[email-masked]>
Date: Sun, 20 Sep 1998 19:41:58 +0200
To: [email-masked]
Subject: Re: OCSP - Public Key Dstribution
Cc: [email-masked]
Sender: [email-masked]

Anders,

the proposal of Denis solves a different problem. It makes the
syntax easier for the client, it doesn't require a field that
may be unnecessary. 

An interpretation of OCSP or OCVP is independant of the
syntax change. 

It is the interpretation of the RESULT that counts: 

- In OCSP you interprete 'good' as 'I have not information that it
  is NOT GOOD'.

- in OCSP you would interprete 'unknown' as 'I know that this CA
  has never issued the CA, or I do not know the CA'. 

Denis' proposal makes the proposal more lightweight.

You can even consider that an OCSP or OCVP does not need more 
than just a serial number (because it operated in a very
restricted environment of just one CA), but well, the protocol
should be able to cover a large range of applications.

From: Peter Sylvester <[email-masked]>
Date: Sun, 20 Sep 1998 19:41:28 +0200
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

> All,
You :-) ,

> 
> The intent was to provide an alternative to CRLs.  Following that model,
> there's an underlying assumption that the end-entity is in possession of
> the CA's certificate (as would be needed to validate the signature on a CRL.)
This is a description that is somewhat strange.

What is an alternative to CRLs? Read part1 of pkix. An alternative is 
something that replace completely the usage of CRLs. CRLs by definition
are one means to detect revoked certs, YOUR intention was to have just
access to a remotely manged CRL. 

There has been a lot of discussion that OCSP is a service that allows
what it says in its definition, online status verification, and not just
lookup of a remote CRL base. A lot of effort has been made to ensure that
a minimal OCSP service can actually implemented using CRLs, otherwise
one may have just used a certHash in the request, and not used the
serial number.

Anyway, an alternative has not a defined model, so what do we have to follow?
And why is there any underlying model. This is NOT documented in OCSP, and
the contrary seems to be indicated in pkix part 1. 

Splitting a local logic that looks into a list a CRLs into a client server
protocol MAY require additional security (as it is mentioned in pkix part1).

You MAY require that a request an a response to be signed by requestor
and the responder sign the response. A server MAY require that the client
proves in some way that it is actually in possession of a cert, or
whatever else you can image. 

Or: CRLs are ONE way to obtain status information of certs OCSP is not
a client server implemention of CRL lookup but a general mecanism to
obtain status information about certificates, and it CAN be implemented
using just CRLs on the server side but it is open to provide MORE service.

> 
> OCSP never had a requirement to validate an end-entity certificate in the
> absence of the CA certificate at the requestor end.  It's not just a
> requirement on syntax at the request.  This would also imply path
> validation logic on the server.  The consensus has been conclusively
> established that full certificate validation is beyond the scope of this
> protocol.
> 
The first version of the protocol allowed just to present a certificate
in a request. Whether the client actually has the corresponding cert
before or after the validation is left to the client.

Denis proposal does not put any requirement for path validation on the 
server, on the contrary,

The server otherwise tell: I know about ONE CA and it's public key hash
is what I return in the response. It the request needs to contain a key
hash, the server MUST validate the public key in order to return 'unknown'
if it doesn't match. Thus, in some sense the actual text requires
validation on the server, and Denis' proposal removes that requirement. 

The only TECHNICAL problem that can happen is that the server KNOWS about
more than ONE certificate having the SAME serial number and the same CA name.
In this case the server should return the status of all of them, 
and let the client decide. 

> There's consequently no need to alter the request syntax.

You can always deduce everything from an empty or false premises.

Peter 

From: Anders Rundgren <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: OCSP - Public Key Dstribution
Date: Sun, 20 Sep 1998 10:53:46 +0200
Sender: [email-masked]

Salut Denis,
Pardon my ignorance but does a returned issuerKeyHash give you the
possibility to verify a certificate signature *after* its status has been checked?
Don't you need the original (unhashed) issuer public key to to that?

I.e. does this enhanced OCSP draft essentially support my suggested OCSP++
(previously I called it OCVP) system *without* requiring extensions?  That would be
just fantastic!

http://www.jaybis.com/specifications/pkix/ocsp.html

Please enlighten me!

Regards
Anders Rundgren

----------
From:  Denis Pinkas [SMTP:[email-masked]]
Sent:  Saturday, September 19, 1998 02:15
To:  Andreas Berger
Cc:  Peter Sylvester; [email-masked]; [email-masked]
Subject:  Re: fast review of draft-ietf-pkix-ocsp-06.txt

Andreas,

I share your concerns.

The current definition of CertId is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public
key
       serialNumber        CertificateSerialNumber }

CertID is used both in the request and in the response.
I would suggest to change it to:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of
Issuers public key
       serialNumber        CertificateSerialNumber }

making the issuerKeyHash optional.

The issuerKeyHash would be optional for a request but mandatory for
a response. The rational is as follows: the requester needs "at
some time" to get the public key of the issuer in order to verify
the certificate. If we mandate that field to be always present
thent it must get it *before* the request to the OCSP server. If we
make it optional, then it may get it before or after the request to
the OCSP server. This gives some flexibility, without too many
options.

The OCSP server should anyway have the Issuers public key and thus
its hash. The hash may allow the requester to disambigous some
responses in case of anonymity. 

Denis
 
> I agree with this discussion and would like to add some thoughts:
> 
> Peter Sylvester wrote:
> > > I actually think OCVP is a bigger thing than just making the hash
> > > of the issuer's PUBLIC key NULL. That whole topic should be
> > > addressed at one shot
> > >
> > I am *not* really talking about OCVP, I am talking about 'CertID',
> > a short way to identify a certificate. The syntax
> > for the identification should be flexible enough
> >
> > - not to require more than the original certificate in
> >   order to construct the identification.
> The is a very good assumption. While the authority key *may* be
> available, it certainly isn´t always available.
> 
> > - to allow identification of a certificate in a given context
> >   ==> serial number for example or/and hash of cert
> The serial number is a little bit weaker but supported by other parts of
> X.509, PKIX and several mail protocols, using issuer/serial for
> identification of a certificate. So issuer/serial or
> issuer/certificate-hash look like valid combinations. It may be a good
> idea to be able add a subject public key hash if necessary.
> 
> > - to allow the OCSP provider to find the source of
> >   information provider.
> >   ==> name of issuer may be necessary, hash of issuer name
> >       may not be sufficient.
> So for identification of issuer we probably have a choice of issuer-name
> or issuer-hash, probably in combination with issuer-public-key or
> issuer-public-key-hash as an optional parameter.
> 
> > - to ensure that the creator of the certificate really has
> >   a copy of a cert.
> >   ==> hash of cert for example, or serialnumber if authority
> >       allocates them in a sparse way.
> > If we assume that the orginal version of OCSP where it was
> > possible to just have a cert did make sense, thus I do not
> > see why there is a need for the issuer public key extract
> > in the certID. At least it should be optional in some way.
> >
> > It seems useful to me to fix a syntax for CertID that
> > is sufficiently open for extensions without requiring
> > a new protocol version..
> 
> The removal of the certificate proper as a means to "identify" a
> certificate forced us to specify an extension to OCSP to do this
> (transport the certificate in the request - optional, or in the reply -
> optional). If the consensus is that OCSP should not be able to transport
> the certificate proper, I think we should at least open the possibility
> to transport a certitficate hash.
> 
> That leads me back to the idea of making a lot of the identification
> parameters in "CertID" optional. But we will get serious
> interoperability issues. So either we build specific CertIDs with
> specific purposes in mind or we need some profiling (and probably a
> means for the responder to transport valid combinations back to the
> client).
> 
> Andreas
> --
> Fifty-three percent of Fortune 1000 executives think the
> Arch Deluxe is something that helps to run a computer.
> -- Jericho Communications

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Reply-To: <[email-masked]>
From: "Amit Kapoor" <[email-masked]>
To: "PKIX" <[email-masked]>
Subject: Testing the ASN.1 in Part 1
Date: Sat, 19 Sep 1998 13:58:24 -0700
Importance: Normal
Sender: [email-masked]

	The following two in PKIX1Implicit93 (and 88):

	DistributionPoint ::= SEQUENCE {
        distributionPoint       [0]     DistributionPointName OPTIONAL,
        reasons         	  [1]     ReasonFlags OPTIONAL,
        cRLIssuer               [2]     GeneralNames OPTIONAL
	}

	DistributionPointName ::= CHOICE {
        fullName                [0]     GeneralNames,
        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName
	}

	Is the tagging correct for DistributionPointName in
	DistributionPoint considering the package is defined as IMPLICIT
	tagging?  How will will the decoder know which one of the two
	DistributionPointName (GeneralNames | RelativeDistinguishedName) is
	represented by [0]?  Similarly for IssuingDistPointSyntax.

	I recall a message from someone from OSS a while back on somewhat
	a similar subject but afraid could not locate it in the archives.

	Thanks.

Amit

Date: Fri, 18 Sep 1998 18:00:08 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

All,

The intent was to provide an alternative to CRLs.  Following that model,
there's an underlying assumption that the end-entity is in possession of
the CA's certificate (as would be needed to validate the signature on a CRL.)

OCSP never had a requirement to validate an end-entity certificate in the
absence of the CA certificate at the requestor end.  It's not just a
requirement on syntax at the request.  This would also imply path
validation logic on the server.  The consensus has been conclusively
established that full certificate validation is beyond the scope of this
protocol.

There's consequently no need to alter the request syntax.

Mike

Date: Fri, 18 Sep 1998 14:38:11 -0700
To: "Flanigan, Bill" <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: proposed text for attributes
Sender: [email-masked]

At 04:39 PM 9/18/98 -0400, Flanigan, Bill wrote:
>Hmm.  I'm starting to have a what-does-it really-say/mean problem with
>things like the "may" word, the "local policy" words, and, in fact, the
>wording of the entire paragraph on the cACertificate attribute.  What
>happened to the "shall" word, and what does "local policy" add in the way
>clarification?   
>	It's not what goes where (we seem to have rough consensus here), but
>rather how to express this with minimal ambiguity and number of words.  How
>about a single sentence along the lines of "The cACertificate attribute of a
>CA's directory entry shall be used to store self-issued certificates (if
>any) and certificates issued to this CA by CAs in the same realm as this
>CA"?

Why not replace "realm" (or domain or scope) with what the word(s) intend.
I take "CA's in the same realm/domain" to mean "CA's acting under a common
authority-to-issue".

Does this help?

___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: 510-422-3881             LLLLLLLL

From: "Flanigan, Bill" <[email-masked]>
To: [email-masked]
Subject: RE: proposed text for attributes
Date: Fri, 18 Sep 1998 16:39:58 -0400
Sender: [email-masked]

Hmm.  I'm starting to have a what-does-it really-say/mean problem with
things like the "may" word, the "local policy" words, and, in fact, the
wording of the entire paragraph on the cACertificate attribute.  What
happened to the "shall" word, and what does "local policy" add in the way
clarification?   
	It's not what goes where (we seem to have rough consensus here), but
rather how to express this with minimal ambiguity and number of words.  How
about a single sentence along the lines of "The cACertificate attribute of a
CA's directory entry shall be used to store self-issued certificates (if
any) and certificates issued to this CA by CAs in the same realm as this
CA"?

Bill Flanigan

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 681-2318
Defense Information Systems Agency      Fax:           (703) 681-2814 
Information Assurance Engineering       DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           (703) 681-2318   
Falls Church, VA 22041-2717        Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]
> Sent:	Friday, September 18, 1998 12:39 PM
> To:	[email-masked]
> Subject:	Re: proposed text for attributes
> 
> >Unless there are any other objections to the wording, I'll get the draft
> >revised with this wording and submitted by Monday. 
> 
> I'd like to echo David Kurn's concern that the wording with respect to the
> cACertificate attribute of a CA's directory entry. If you don't define
> "realm",
> then there doesn't seem much point to saying that "some things that person
> accessing the directory cannot determine will appear in the cACertificate
> attribute". Why is that still in the spec if it's up to local policy to
> decide
> what to put there?
> 
> Maybe better wording would be "The cACertificate attribute of a CA's
> directory
> entry may be populated with certificates defined by local policy" and
> leave
> the
> rest of the paragraph out.
> 
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Fri, 18 Sep 1998 21:15:06 +0300 (   )
From: Jan Willemson <[email-masked]>
To: [email-masked]
Subject: Who uses what?
Sender: [email-masked]

Hello!

Excuse me please for being yet-another-newbie and asking a newbie 
question. But this is the only way to get smart.

I have been reading ietf-pkix drafts for some time and found a lot of
proposed X.509 extensions. On the other hand there are many companies
(Netscape etc) producing cert-software that uses (as I understand) some of
these extensions and some extensions of their own. So - is there somewhere
out there an overview of who uses what? I believe there is, but my
webcrawling has not been able to find it yet. I would be grateful for all
hints/links etc.

Thank you:)

Jan

Date: Fri, 18 Sep 1998 13:29:49 -0400
To: Dean Povey <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Testing the ASN.1 in Part 1 
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

<html>
You found a minor editorial error in the document, but not an ASN.1
error.<br>
<br>
For some reason, CertificatePolicies is defined here and where it should
be.<br>
<br>
The two lines with '*' at the front should be deleted:<br>
<br>
<font face="Courier New, Courier">&nbsp;&nbsp; id-ce-policyConstraints
OBJECT IDENTIFIER ::=&nbsp; { id-ce 36 }<br>
<br>
*&nbsp; CertificatePoliciesSyntax ::=<br>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SEQUENCE SIZE (1..MAX) OF PolicyInformation<br>
<br>
&nbsp;&nbsp; PolicyConstraints ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
requireExplicitPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[0] SkipCerts OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
inhibitPolicyMapping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[1] SkipCerts OPTIONAL }<br>
<br>
&nbsp;&nbsp; SkipCerts ::= INTEGER (0..MAX)<br>
<br>
<br>
</font>Russ<br>
<br>
<br>
<br>
At 03:47 PM 9/18/98 +1000, Dean Povey wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt;Anyone who plans to get around to checking the ASN.1 after
part 1 becomes<br>
&gt;&gt;&gt;an RFC: could you do it now instead? This would be a great
help to us all.<br>
&gt;&gt;&gt;Thanks!<br>
&gt;&gt;&gt;<br>
&gt;<br>
&gt;More bugs in PKIX1ImplictXX<br>
&gt;<br>
&gt;The ASN.1 for PolicyConstraints is incorrect. In both the 88 and 93
versions <br>
&gt;it is specified as a SEQUENCE SIZE(1..MAX) OF SEQUENCE { ... }.&nbsp;
This is <br>
&gt;inconsistent with the X.509 definition and it also doesn't make any
sense for <br>
&gt;it to be a SEQUENCE OF.&nbsp; The definition of PolicyConstraints
should&nbsp; be:<br>
&gt;<br>
&gt;PolicyConstraints ::= SEQUENCE {<br>
&gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>requireExplicitPolicy<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>[0]
SkipCerts OPTIONAL,<br>
&gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>inhibitPolicyMapping<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[1]
SkipCerts OPTIONAL }<br>
&gt;<br>
&gt;Also the authorityInfoAccess OID is missing in the 88 module, it
should be:<br>
&gt;<br>
&gt;id-pe-authorityInfoAccess&nbsp; OBJECT IDENTIFIER ::= { id-pe 1
}<br>
&gt;<br>
&gt;More as I find 'em :-).<br>
&gt;<br>
&gt;<br>
&gt;-- <br>
&gt;Dean Povey,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | e-m:
[email-masked]&nbsp;&nbsp;&nbsp;&nbsp; | Cryptozilla:<br>
&gt;Research Scientist&nbsp; | ph:&nbsp; +61 7 3864
5120&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
<a href="http://www.cryptozilla.org/" eudora="autourl">www.cryptozilla.org/</a><br>
&gt;Security Unit, DSTC | fax: +61 7 3864
1282&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Oscar - PKI Toolkit:<br>
&gt;Brisbane, Australia | www: security.dstc.edu.au/ |&nbsp;
oscar.dstc.qut.edu.au/<br>
&gt;<br>
&gt;<br>
</html>

Date: Fri, 18 Sep 1998 09:39:16 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: proposed text for attributes
Sender: [email-masked]

>Unless there are any other objections to the wording, I'll get the draft
>revised with this wording and submitted by Monday. 

I'd like to echo David Kurn's concern that the wording with respect to the
cACertificate attribute of a CA's directory entry. If you don't define
"realm",
then there doesn't seem much point to saying that "some things that person
accessing the directory cannot determine will appear in the cACertificate
attribute". Why is that still in the spec if it's up to local policy to decide
what to put there?

Maybe better wording would be "The cACertificate attribute of a CA's directory
entry may be populated with certificates defined by local policy" and leave
the
rest of the paragraph out.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 17:41:07 +0200
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I support the suggestion from Denis.

I suggest that one adds an optional hash of the certificate.
it MAY be returned by the OCSP server, and it MAY be
requested by the OCSP server. one could use the now obsolete
error code certrequired (rename it certhashrequired).

Whenever a client actually has the cert I would expect that
it always sets the certHash in the request, the OCSP server
may remove the certHash in the response if the certHash
value was not used in order for identification, e.g. when
only the serialNumber was used. 

   CertID          ::=     SEQUENCE {
        hashAlgorithm       AlgorithmIdentifier,
        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
        issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of Issuers public key
        serialNumber        CertificateSerialNumber 
        certHash            OCTET STRING OPTIONAL, -- hash of the certificate.

   }

Date: Fri, 18 Sep 1998 17:14:48 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Andreas Berger <[email-masked]>
CC: Peter Sylvester <[email-masked]>, [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

Andreas,

I share your concerns.

The current definition of CertId is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public
key
       serialNumber        CertificateSerialNumber }

CertID is used both in the request and in the response.
I would suggest to change it to:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING OPTIONAL, -- Hash of
Issuers public key
       serialNumber        CertificateSerialNumber }

making the issuerKeyHash optional.

The issuerKeyHash would be optional for a request but mandatory for
a response. The rational is as follows: the requester needs "at
some time" to get the public key of the issuer in order to verify
the certificate. If we mandate that field to be always present
thent it must get it *before* the request to the OCSP server. If we
make it optional, then it may get it before or after the request to
the OCSP server. This gives some flexibility, without too many
options.

The OCSP server should anyway have the Issuers public key and thus
its hash. The hash may allow the requester to disambigous some
responses in case of anonymity. 

Denis
 
> I agree with this discussion and would like to add some thoughts:
> 
> Peter Sylvester wrote:
> > > I actually think OCVP is a bigger thing than just making the hash
> > > of the issuer's PUBLIC key NULL. That whole topic should be
> > > addressed at one shot
> > >
> > I am *not* really talking about OCVP, I am talking about 'CertID',
> > a short way to identify a certificate. The syntax
> > for the identification should be flexible enough
> >
> > - not to require more than the original certificate in
> >   order to construct the identification.
> The is a very good assumption. While the authority key *may* be
> available, it certainly isn´t always available.
> 
> > - to allow identification of a certificate in a given context
> >   ==> serial number for example or/and hash of cert
> The serial number is a little bit weaker but supported by other parts of
> X.509, PKIX and several mail protocols, using issuer/serial for
> identification of a certificate. So issuer/serial or
> issuer/certificate-hash look like valid combinations. It may be a good
> idea to be able add a subject public key hash if necessary.
> 
> > - to allow the OCSP provider to find the source of
> >   information provider.
> >   ==> name of issuer may be necessary, hash of issuer name
> >       may not be sufficient.
> So for identification of issuer we probably have a choice of issuer-name
> or issuer-hash, probably in combination with issuer-public-key or
> issuer-public-key-hash as an optional parameter.
> 
> > - to ensure that the creator of the certificate really has
> >   a copy of a cert.
> >   ==> hash of cert for example, or serialnumber if authority
> >       allocates them in a sparse way.
> > If we assume that the orginal version of OCSP where it was
> > possible to just have a cert did make sense, thus I do not
> > see why there is a need for the issuer public key extract
> > in the certID. At least it should be optional in some way.
> >
> > It seems useful to me to fix a syntax for CertID that
> > is sufficiently open for extensions without requiring
> > a new protocol version..
> 
> The removal of the certificate proper as a means to "identify" a
> certificate forced us to specify an extension to OCSP to do this
> (transport the certificate in the request - optional, or in the reply -
> optional). If the consensus is that OCSP should not be able to transport
> the certificate proper, I think we should at least open the possibility
> to transport a certitficate hash.
> 
> That leads me back to the idea of making a lot of the identification
> parameters in "CertID" optional. But we will get serious
> interoperability issues. So either we build specific CertIDs with
> specific purposes in mind or we need some profiling (and probably a
> means for the responder to transport valid combinations back to the
> client).
> 
> Andreas
> --
> Fifty-three percent of Fortune 1000 executives think the
> Arch Deluxe is something that helps to run a computer.
> -- Jericho Communications

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: proposed text for attributes
Date: Fri, 18 Sep 1998 07:59:42 -0400
Sender: [email-masked]

Santosh and I prefer the use of 'realm'. Scope, although not as bad as
domain, also has some other meanings associated with it in the PKI area.

Unless there are any other objections to the wording, I'll get the draft
revised with this wording and submitted by Monday. I also will be submitting
a new version of the LDAPv2 protocol profile, but this is only because the
current draft expires this month. There are no changes to it and it passed
last call back in January (for those who weren't following this list at that
time, the IESG would not allow it to progress to RFC without this
accompanying schema).

Sharon

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Fri, 18 Sep 1998 12:06:44 +0200
From: Andreas Berger <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

I agree with this discussion and would like to add some thoughts:

Peter Sylvester wrote:
> > I actually think OCVP is a bigger thing than just making the hash
> > of the issuer's PUBLIC key NULL. That whole topic should be
> > addressed at one shot
> >
> I am *not* really talking about OCVP, I am talking about 'CertID',
> a short way to identify a certificate. The syntax
> for the identification should be flexible enough
> 
> - not to require more than the original certificate in
>   order to construct the identification.
The is a very good assumption. While the authority key *may* be
available, it certainly isn´t always available.
 
> - to allow identification of a certificate in a given context
>   ==> serial number for example or/and hash of cert
The serial number is a little bit weaker but supported by other parts of
X.509, PKIX and several mail protocols, using issuer/serial for
identification of a certificate. So issuer/serial or
issuer/certificate-hash look like valid combinations. It may be a good
idea to be able add a subject public key hash if necessary.

> - to allow the OCSP provider to find the source of
>   information provider.
>   ==> name of issuer may be necessary, hash of issuer name
>       may not be sufficient.
So for identification of issuer we probably have a choice of issuer-name
or issuer-hash, probably in combination with issuer-public-key or
issuer-public-key-hash as an optional parameter.

> - to ensure that the creator of the certificate really has
>   a copy of a cert.
>   ==> hash of cert for example, or serialnumber if authority
>       allocates them in a sparse way.
> If we assume that the orginal version of OCSP where it was
> possible to just have a cert did make sense, thus I do not
> see why there is a need for the issuer public key extract
> in the certID. At least it should be optional in some way.
> 
> It seems useful to me to fix a syntax for CertID that
> is sufficiently open for extensions without requiring
> a new protocol version..

The removal of the certificate proper as a means to "identify" a
certificate forced us to specify an extension to OCSP to do this
(transport the certificate in the request - optional, or in the reply -
optional). If the consensus is that OCSP should not be able to transport
the certificate proper, I think we should at least open the possibility
to transport a certitficate hash.

That leads me back to the idea of making a lot of the identification
parameters in "CertID" optional. But we will get serious
interoperability issues. So either we build specific CertIDs with
specific purposes in mind or we need some profiling (and probably a
means for the responder to transport valid combinations back to the
client).

Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 11:02:53 +0200
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

> I thought the issue with this was that in a case of a request where the
> certificate was sent in place of the certID, a response could not be
> formed unless the responder already had the issuer cert (or at least
> knew its key hash).  This has been dealt with, since request now must
> have a certID for each requested cert.  Was there some additional issue
> I wasn't aware of?

The original text provided to USE a certificate and nothing else
to form a request. This is no longer possible.

CertID in its current form cannot be used as a replacement for a
certificate in the case where the client does not have the issuer cert.
 
The syntax for CertID has not been discussed in the context where
this is the ONLY way to identify a cert. 

Peter

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 10:56:24 +0200
To: [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [email-masked]
Sender: [email-masked]

> > 
> 
> I actually think OCVP is a bigger thing than just making the hash
> of the issuer's PUBLIC key NULL. That whole topic should be
> addressed at one shot
> 
I am *not* really talking about OCVP, I am talking about 'CertID',
a short way to identify a certificate. The syntax
for the identification should be flexible enough  

- not to require more than the original certificate in
  order to construct the identification.

- to allow identification of a certificate in a given context
  ==> serial number for example or/and hash of cert

- to allow the OCSP provider to find the source of 
  information provider.
  ==> name of issuer may be necessary, hash of issuer name
      may not be sufficient. 

- to ensure that the creator of the certificate really has
  a copy of a cert.
  ==> hash of cert for example, or serialnumber if authority
      allocates them in a sparse way.

If we assume that the orginal version of OCSP where it was
possible to just have a cert did make sense, thus I do not
see why there is a need for the issuer public key extract 
in the certID. At least it should be optional in some way.

It seems useful to me to fix a syntax for CertID that
is sufficiently open for extensions without requiring
a new protocol version..

Peter

Date: Fri, 18 Sep 1998 01:41:01 -0700
From: Dan Weinstein <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

>some remarks about the lastest OCSP draft:
>
>- It seems that the remarks about not knowing the public
>  key of an issuer are not addressed. 
>
>  It seems sufficient to ME to allow that the
>  hash of the issure private key MAY be a length 0 octet string,
>  something like that, or one might add the public
>  key of the OCSP responder instead. 
>
>  Thoughts?

I thought the issue with this was that in a case of a request where the
certificate was sent in place of the certID, a response could not be
formed unless the responder already had the issuer cert (or at least
knew its key hash).  This has been dealt with, since request now must
have a certID for each requested cert.  Was there some additional issue
I wasn't aware of?

Dan Weinstein
[email-masked]

cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Testing the ASN.1 in Part 1 
Date: Fri, 18 Sep 1998 15:47:57 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

>
>
>>Anyone who plans to get around to checking the ASN.1 after part 1 becomes
>>an RFC: could you do it now instead? This would be a great help to us all.
>>Thanks!
>>

More bugs in PKIX1ImplictXX

The ASN.1 for PolicyConstraints is incorrect. In both the 88 and 93 versions 
it is specified as a SEQUENCE SIZE(1..MAX) OF SEQUENCE { ... }.  This is 
inconsistent with the X.509 definition and it also doesn't make any sense for 
it to be a SEQUENCE OF.  The definition of PolicyConstraints should  be:

PolicyConstraints ::= SEQUENCE {
	requireExplicitPolicy	[0] SkipCerts OPTIONAL,
	inhibitPolicyMapping	[1] SkipCerts OPTIONAL }

Also the authorityInfoAccess OID is missing in the 88 module, it should be:

id-pe-authorityInfoAccess  OBJECT IDENTIFIER ::= { id-pe 1 }

More as I find 'em :-).

-- 
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

Date: Thu, 17 Sep 1998 14:53:31 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

Peter,
    Great catches - comments follow:

Peter Sylvester wrote:
> 
> hello,
> 
> some remarks about the lastest OCSP draft:
> 
> - It seems that the remarks about not knowing the public
>   key of an issuer are not addressed.
> 
>   It seems sufficient to ME to allow that the
>   hash of the issure private key MAY be a length 0 octet string,
>   something like that, or one might add the public
>   key of the OCSP responder instead.
> 
>   Thoughts?
> 

I actually think OCVP is a bigger thing than just making the hash
of the issuer's PUBLIC key NULL. That whole topic should be
addressed at one shot

> 
> - the remark
> 
>    " Response extensions may be used to
>    convey additional information on assertions made by the responder
>    regarding the status of the certificate such as positive statement
>    about issuance, validity, etc."
> 
>    should be removed behind all possible responses since extensions
>    can also be used to indicate additional interpretations for
>    revoked, notknown.
> 
> 
> -  >  The response "certRequired" is returned in cases where the server
>    >  requires the client to supply the certificate data itself in order to
>    >  construct a response.
> 
>    This paragraph should be removed
> 
>    etc for the ASN.1 response code
>       certRequired          (4),  --Must supply certificate

Agreed - will be fixed. Thanks for catching this

> 
> -  A.1.1 : "Where privacy is a
>    requirement, OCSP transactions exchanged using HTTP SHOULD be protected
>    using either TLS or SSL."
> 
>    Shouldn't the SHOULD be a MAY ?
> 
>    one could also use a VPN for example

Agreed.

> 
>    Or just add 'or by lower layer protection'.
> 
> have fun.

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 17 Sep 1998 18:36:01 +0200
To: [email-masked]
Subject: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [email-masked]

hello,

some remarks about the lastest OCSP draft:

- It seems that the remarks about not knowing the public
  key of an issuer are not addressed. 

  It seems sufficient to ME to allow that the
  hash of the issure private key MAY be a length 0 octet string,
  something like that, or one might add the public
  key of the OCSP responder instead. 

  Thoughts?

- the remark 
   
   " Response extensions may be used to
   convey additional information on assertions made by the responder
   regarding the status of the certificate such as positive statement
   about issuance, validity, etc."
 
   should be removed behind all possible responses since extensions
   can also be used to indicate additional interpretations for
   revoked, notknown. 

-  >  The response "certRequired" is returned in cases where the server
   >  requires the client to supply the certificate data itself in order to
   >  construct a response.

   This paragraph should be removed

   etc for the ASN.1 response code      
      certRequired          (4),  --Must supply certificate

-  A.1.1 : "Where privacy is a
   requirement, OCSP transactions exchanged using HTTP SHOULD be protected
   using either TLS or SSL."

   Shouldn't the SHOULD be a MAY ?

   one could also use a VPN for example

   Or just add 'or by lower layer protection'.  

have fun.

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 12:23:15 -0400
Sender: [email-masked]

I'm flexible on the term and have passed that on to Santosh (awaiting his
reply).  I see nothing wrong with scope or realm and am open to suggestion.
I agree that it would be good to select a term that doesn't have a
predefined meaning in the IETF. 
It is important to keep the definition of the specific criteria for its use
as a local matter so this mechanism can be used in different environments
with different criteria for the 'hints' provided by the CA to relying
parties, regardless of whether relying parties choose to examine those hints
or not. That, we've been in agreement on thoughout this debate, but I'm
quite agreeable to a different 'less loaded' term.

> ----------
> From: 	bgmiller[SMTP:[email-masked]]
> Sent: 	September 16, 1998 10:26 PM
> To: 	[email-masked]
> Subject: 	Re: Storage of CA Certificates in LDAP and X.500 Directory
> Attributes
> 
> 
> 
> Paul Hoffman / IMC wrote:
> 
> > I agree with David. The word "domain" has a specific meaning in the
> IETF,
> > and this definition doesn't match it. Could you use "realm" instead? Or
> are
> > there better words?
> 
> How about "scope"?
> 

From: "Kurn, David" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 08:43:54 -0700
Sender: [email-masked]

I think the actual choice of word here is not the issue.  You can call it
"Kingdom", but the flaw in the specification persists, since the last
sentence implies that the word has a definition that depends upon the
personal interpretation of the implementor.  This doesn't make for portable
programs.

I think the reason the specification needs the word is so that the spec can
give guidance about when to put a cross-cert in one bucket or in another
bucket.  And this, if I follow the recent conversations, has to do with
advice about how to do path development. (I'm stepping out on shaky ground
here).

*IF* we wish to say to those writing path evaluation programs:
  "You should look in the first bucket (caCertificates) first, and then in
the second bucket"
then we can give some guidance about how to populate the two buckets, which
could in effect would say:

You should put certificates in the appropriate bucket according to your
expectation about how to optimize the path development given that clients
will look in the caCertificates first.  Your choice will affect efficiency,
not correctness.

I go back to something I remember from learning about Object-Oriented
programming .... don't ask "what is it", but rather "what does it do".

David Kurn
Compaq Computer Corp

-----Original Message-----
From: bgmiller [mailto:[email-masked]]
Sent: Wednesday, September 16, 1998 7:27 PM
To: [email-masked]
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory
Attributes

Paul Hoffman / IMC wrote:

> I agree with David. The word "domain" has a specific meaning in the IETF,
> and this definition doesn't match it. Could you use "realm" instead? Or
are
> there better words?

How about "scope"?

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-06.txt
Date: Thu, 17 Sep 1998 10:09:49 -0400
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		: X.509 Internet Public Key Infrastructure 
                          Online Certificate Status Protocol - OCSP
	Author(s)	: M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams
	Filename	: draft-ietf-pkix-ocsp-06.txt
	Pages		: 20
	Date		: 16-Sep-98
	
   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs. Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents.
 
   An overview of the protocol is provided in section 3. Functional
   requirements are specified in section 4. Details of the protocol are
   in section 5. We cover security issues with the protocol in section
   6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
   syntactic elements and appendix C specifies the mime types for the
   messages.
 
   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
   'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
   document (in uppercase, as shown) are to be interpreted as described
   in [RFC2119].

Internet-Drafts are 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-ocsp-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-06.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ocsp-06.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-ocsp-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 16 Sep 1998 22:26:37 -0400
From: bgmiller <[email-masked]>
Reply-To: [email-masked]
Organization: Jones Internet Channel
To: [email-masked]
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Sender: [email-masked]

Paul Hoffman / IMC wrote:

> I agree with David. The word "domain" has a specific meaning in the IETF,
> and this definition doesn't match it. Could you use "realm" instead? Or are
> there better words?

How about "scope"?

Date: Wed, 16 Sep 1998 15:49:01 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Sender: [email-masked]

At 03:22 PM 9/16/98 -0700, Kurn, David wrote:
>I still think the use of "domain" is very confusing, and should be removed
>from the text.

I agree with David. The word "domain" has a specific meaning in the IETF,
and this definition doesn't match it. Could you use "realm" instead? Or are
there better words?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Wed, 16 Sep 1998 15:22:03 -0700
Sender: [email-masked]

I still think the use of "domain" is very confusing, and should be removed
from the text.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, September 16, 1998 2:23 PM
To: [email-masked]
Subject: Storage of CA Certificates in LDAP and X.500 Directory
Attributes

Based on the pkix co-chair request, Sharon and I jointly propose the
following text:

"The cACertificate attribute of a CA's directory entry shall be used to
store certificates issued to this CA by CAs in the same domain as this
CA.  If there are any self-issued certificates and they require
publication, the caCertificate attribute shall be used to store them.

The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all certificates issued to this
CA, which are not self-issued.  Optionally, the reverse elements of the
crossCertificatePair attribute, of a CA's directory entry may contain a
subset of certificates issued by this CA to other CAs.  When both the
forward and the reverse elements are present in a single attribute
value, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.  When a reverse element is present, the
forward element value and the reverse element value need not be stored
in the same attribute value; in other words, they can be stored in
either a single attribute value or two attribute values.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
[email-masked]
http://www.cygnacom.com

From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Subject: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Date: Wed, 16 Sep 1998 17:22:55 -0400
Sender: [email-masked]

Based on the pkix co-chair request, Sharon and I jointly propose the
following text:

"The cACertificate attribute of a CA's directory entry shall be used to
store certificates issued to this CA by CAs in the same domain as this
CA.  If there are any self-issued certificates and they require
publication, the caCertificate attribute shall be used to store them.

The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all certificates issued to this
CA, which are not self-issued.  Optionally, the reverse elements of the
crossCertificatePair attribute, of a CA's directory entry may contain a
subset of certificates issued by this CA to other CAs.  When both the
forward and the reverse elements are present in a single attribute
value, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.  When a reverse element is present, the
forward element value and the reverse element value need not be stored
in the same attribute value; in other words, they can be stored in
either a single attribute value or two attribute values.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
[email-masked]
http://www.cygnacom.com

Date: Tue, 15 Sep 1998 13:52:32 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Schema Straw Poll Closure
Sender: [email-masked]

Well, thank you all for the enthusiastic balloting and commenting.  Steve
and I have at last managed to synch up, and here is how we interpret the
Straw Poll result.

There was no clear concensus winner in either Option 1 or Option 2.  There
was significant support for both options, at least on the basis of
installed product, plus various positions on technical grounds.  

We clearly need to accommodate the requirements of option 1 supporters by
permitting the population of the cACertificate attribute with self-issued
certificates and certificates issued by another CA to this CA within the
context of a locally defined domain.  In fairness to all, we feel we should
also accommodate the requirement of option 2 supporters to have all
certificates issued by CAs to this CA (which are placed in the subject CA
entry at all), regardless of the definition of domain, populated in the
crossCertificatePair attribute forward element.  

As secondary points, there appears to be consensus that population of the
reverse element is always optional. Text regarding optional, mutual
cross-certification also needs to be finalized but this will hopefully not
be contentious. 

This resolution should allow relying parties to operate under either option
successfully; the main negative in this resolution seems to be that, in
option 1 environments, there would necessarily be some duplication of data
in the directory.

This essentially means a compromise that hopefully all parties can live
with, although we know it will not go down in history as the most brilliant
technical decision of all time.

In the absence of violent objections, we propose that Sharon and Santosh
jointly craft text that follows this resolution, and that we seek to close
debate on this topic ASAP.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

From: Trevor Sosebee <[email-masked]>
Date: Tue, 15 Sep 1998 11:02:01 -0500 (CDT)
To: [email-masked]
Subject: UTF8String definition in PKIX-3
Sender: [email-masked]

In PKIX-3, UTF8String is defined as

	UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING.

I was wondering I someone could point me to the version of X.680 where 
UTF8String is defined.

Thanks,
Trevor

To: Paul Hoffman / IMC <[email-masked]>
cc: [email-masked]
Subject: Re: Testing the ASN.1 in Part 1 
Date: Tue, 15 Sep 1998 14:29:01 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

>Anyone who plans to get around to checking the ASN.1 after part 1 becomes
>an RFC: could you do it now instead? This would be a great help to us all.
>Thanks!
>

*grr* I was putting this off :-)

I am using the 88ish syntax

PKIX1Explicit88 parses fine, but there are stuff ups in the imports in
PKIX1Implicit88 

To the IMPORTS section in PKIX1Implicit88 add the following:

id-pkix, BMPString, UniversalString, UTF8String

And delete the following two redundant definitions:

id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 } 

Other than that it looks like so far so good.  I'll have to do some more work 
until this is fully tested.

-- 
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

Date: Mon, 14 Sep 1998 10:18:54 -0700
Subject: Re: Testing the ASN.1 in Part 1
From: "Aram Perez" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, [email-masked]
Sender: [email-masked]

Hi Paul,

Check the web site of Open Systems Solutions (http://www.oss.com). They do free
ASN.1 syntax checking for groups such as IETF.

Regards,
Aram Perez
Apple Computer, Inc.

>Greetings, all. I know that all this discussion of LDAP is fascinating, but
>I'd like to come back to draft-ietf-pkix-ipki-part1 for a second. It is in
>IESG last call, almost ready (we hope) to become an RFC. Tim has just made
>minor tweaks to it (it is now -10.txt), and we're almost there.
>
>Has anyone tested the full ASN.1 in part 1 lately? Given the anti-ASN.1
>sentiment in the IETF, it would be Very Embarassing if we got an RFC and
>had to revise it due to an ASN.1 error. Worse yet, it would be bad if there
>was an error and two implementors did different things to get around it.
>
>Anyone who plans to get around to checking the ASN.1 after part 1 becomes
>an RFC: could you do it now instead? This would be a great help to us all.
>Thanks!
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Mon, 14 Sep 1998 10:09:39 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Andreas Berger <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: OCSP ASN.1 comments
Sender: [email-masked]

Hi Andreas,
    Thanks for the comment - it has already been fixed.

Regards,
Ambarish

Andreas Berger wrote:
> 
> Hi,
> 
> I am forwarding here parts of a comment of Mr. Thomas Garnatz, Security
> Networks GmbH:
> 
> There is a context sensitive coding in ResponseData and ResponderID
> 
> ResponseData          ::= SEQUENCE {
>       version                 [0]     EXPLICIT Version DEFAULT v1,
>       reponderID                      ResponderID,
>       ...
> }
> 
> ResponderID                   ::=     CHOICE {
>       byName          [0]     Name,
>       byKey                   [1]     KeyHash
> }
> 
> Since the version field is optional (i.e. not present for version 1) it
> is not very easy to distinguish between version (explicit [0]) and
> byName [0]. The suggested idea is to either remove the DEFAULT or not to
> use [0] for byName.
> 
> I hope I got the translation right and made some sense to the ASN.1
> gurus (myself not being one).
> 
> Andreas Berger
> --
> Fifty-three percent of Fortune 1000 executives think the
> Arch Deluxe is something that helps to run a computer.
> -- Jericho Communications

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

Date: Mon, 14 Sep 1998 08:36:12 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Testing the ASN.1 in Part 1
Sender: [email-masked]

Greetings, all. I know that all this discussion of LDAP is fascinating, but
I'd like to come back to draft-ietf-pkix-ipki-part1 for a second. It is in
IESG last call, almost ready (we hope) to become an RFC. Tim has just made
minor tweaks to it (it is now -10.txt), and we're almost there.

Has anyone tested the full ASN.1 in part 1 lately? Given the anti-ASN.1
sentiment in the IETF, it would be Very Embarassing if we got an RFC and
had to revise it due to an ASN.1 error. Worse yet, it would be bad if there
was an error and two implementors did different things to get around it.

Anyone who plans to get around to checking the ASN.1 after part 1 becomes
an RFC: could you do it now instead? This would be a great help to us all.
Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 14 Sep 1998 15:01:43 +0200
From: Andreas Berger <[email-masked]>
To: pkix <[email-masked]>
Subject: OCSP ASN.1 comments
Sender: [email-masked]

Hi,

I am forwarding here parts of a comment of Mr. Thomas Garnatz, Security
Networks GmbH:

There is a context sensitive coding in ResponseData and ResponderID

ResponseData          ::= SEQUENCE {
      version                 [0]     EXPLICIT Version DEFAULT v1,
      reponderID                      ResponderID,
      ...
}

ResponderID                   ::=     CHOICE {
      byName          [0]     Name,
      byKey                   [1]     KeyHash
}

Since the version field is optional (i.e. not present for version 1) it
is not very easy to distinguish between version (explicit [0]) and
byName [0]. The suggested idea is to either remove the DEFAULT or not to
use [0] for byName.

I hope I got the translation right and made some sense to the ASN.1
gurus (myself not being one).

Andreas Berger
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

Date: Sun, 13 Sep 1998 00:25:48 +0200
To: Mike Smith <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Mike,

First of all. I truly hope that I didn't offend you with my remark.
I certainly didn't want that.

Yes, the problem you raise is both real and relevant. I just don't share
the same belief in automation through policy definition codings in
certificate extensions.

I do believe that it MAY work sufficient in a fairly closed environment
where one organization has the control over interpretations and
implementations. But international standard, no way. 

Actually I believe that the policy OID in certificates may serve automation
just fine in real life. If trust automation is developing to be an
competitive edge in a certain community, then CA:s will try to adopt to
well known policies and indicate them in the certificates. So in that case
there will just be a limited space of policy OID:s to consider. Whether
this will happen or not is up to the market but the market sure has the
tools needed if there is money to be made through interoperability.

Over specifying things before the true need has emerged is always
dangerous. And I'm sorry to say that we Europeans have some quite extensive
experiences along that line.

/Stefan

At 10:11 AM 9/11/98 -0600, Mike Smith wrote:
>OK, the quagmire consensus is taken for what it is.  I first proposed
enhancing automating some trust decisions using a new extension, then using
the existing policy qualifier.  The overwhelming response from people whose
comments I respect is that we should consider the policy OID sufficient.
>
>If this is to be technological solution for automated processing, then we
need to step backwards a few years and look at the definition of "to
process" with regard to the actual CPS that the OID points towards.
>
>Maybe the old PKIX 1 needs to be restructured to retain its contents and
menaing, but to specify a parsable structure and standardize (define
rigidly) the terms used in the policies and practices or concept of
operations (whatever people are using the OID to point towards).
>
>The goal here is not to reopen old wounds or pull people into yet another
quagmire (my cletic genetics may predispose me to jumping inot bogs,
however).  The question that folks seem to be attemoting to address is the
automation of trust domains.  
>
>The feedback I get is not really "you are off track", but that "the
problem is too big to solve", or that this group is incapable of solving
this problem in a timely manner.
>
>I disagree.  This group is comprised of the most experienced and, IMO,
brightest technologists in the industry.  
>
>So, I pose the question to the best and brightest:  How do you suggest,
then that we automate domain or trust processing?
>
>I think I know how we are going to operate across domains of trust  in the
finanical industry.  I suggest that we in the IETF apply our great
resources building AUTOMATED systems that have a high assurance of working
together across the Internet.
>
>If, as some have suggested , I need to write a draft covering these
issues, I am up for that (if Warwick and Stephen think it is worth the
group's time).
>
>Michael
>
>>>> Stefan Santesson <[email-masked]> 09/11 8:44 AM >>>
>******************  InterScan Message (on zbc2)
>
>noname is scanned and no virus found
>*********************************************************
>

    !
>!

From: Charles Moore <[email-masked]>
To: "'Peter Lipp'" <[email-masked]>, Paul Koning <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Sun, 13 Sep 1998 07:31:56 +1000
Sender: [email-masked]

All, we ( Australian National Standards Group) have been working on a
simular problem. 
I.e how does a relying party know what evidence of Identity that the
RA/CA makes a statement about when performing the registration process.
There are assocaited issues, but lets start with this one.

We have a working draft that proposes the use of a policy qualifier as
below:

pkaf-policy-Identification CERT-POLICY-QUALIFIER ::= {
	POLICY-QUALIFIER-ID	id-pkaf-policy-Identification
	QUALIFIER-TYPE		Identification }

Identification ::= BIT STRING {
	driversLicense	(0),
	passport	(1),
	creditCard	(2),
	organisationIDBadge	(3),
	governmentIDBadge	(4),
	articlesOfIncorp	(5),
	companySeal	(6),
	notarizedDoc	(7),
	biometricThumb	(8),
	biometricVoice	(9),
	biometricFace	(10),
	biometricRetina	(11) }

We have not used A CP ( or any reference to a CPS) alone to do this as
experience is that within a given policy there is no direct mapping to
the level of identification needed. Identification is not the driver for
a CP or CPS, but rather a qualifier of these. 

Hope this assists the discussion.

Regards
Charles Moore
SPYRUS Pty Ltd
Phone: +61 73 256 7465, Extension 101

From: "Peter Lipp" <[email-masked]>
To: "Paul Koning" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Fri, 11 Sep 1998 21:59:08 +0200
Importance: Normal
Sender: [email-masked]

> I very much doubt that a mapping from natural language legal
> terminology to formal logic will be defined anytime in the next 10
> years.  Come to think of it, thinking of Goedel makes me wonder if
> it's even theoretically possible.

But that would not be necessary. I could well imagine defining a set of
attributes describing the most important elements of such statements like

... passport needed ....
... anything that looks like an ID with photo sufficient ...
... we don't check anything at all ....

or things like that. The problem I see is in all cases the trust into 
the truthfulness of such statements - it does not help anybody if my
machine can verify that indeed the CA claims to having seen a passport
if I don't trust the CA not to lie in the first place. This needs checks
by myself or trusted representatives in any case, and no formal logic will
help.

Peter

Date: Fri, 11 Sep 1998 12:33:22 -0600
From: Mike Smith <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

I think you've got it.  

As far as being ahead of state of the art, I've been in meetings with many of the folks on this list several years ago when the same issues of parsing the CPS in order to automate were brought up.

By the way, I was not suggesting parsing a free-form CPS, but structuring the CPS for automated processing, which might need then both a human and machine readable form or sections of the same CPS.

The saying goes (Warren Miller, Ski Film producer):  "If you don't do it now, You'll only be another year older when you do".

Michael

>>> Paul Koning <[email-masked]> 09/11 12:07 PM >>>
>>>>> "Mike" == Mike Smith <[email-masked]> writes:

 Mike> ...Maybe the old PKIX 1 needs to be restructured to retain its
 Mike> contents and menaing, but to specify a parsable structure and
 Mike> standardize (define rigidly) the terms used in the policies and
 Mike> practices or concept of operations (whatever people are using
 Mike> the OID to point towards).

 Mike> ...The feedback I get is not really "you are off track", but that
 Mike> "the problem is too big to solve", or that this group is
 Mike> incapable of solving this problem in a timely manner.

 Mike> I disagree.  This group is comprised of the most experienced
 Mike> and, IMO, brightest technologists in the industry.

 Mike> So, I pose the question to the best and brightest: How do you
 Mike> suggest, then that we automate domain or trust processing?

I think the question you pose is not a little, but vastly beyond the
state of the art.

As I understand it, the goal you're posing is: define a way for the CA 
to encode into the cert information that the relying party can use to
decide whether the subject of that cert was authenticated by means
strong enough to be satisfactory to the relying party.

A somewhat analogous question (though not applicable to a particular
cert) is whether the CA's CPS is strong enough for the relying party.

It seems to me that this latter question is one you drop onto your
company's lawyer to settle.  It involves parsing natural language
(well, anyway, legal language) to see what it means, and whether that
meaning is satisfactory to your corporate requirements.

I very much doubt that a mapping from natural language legal
terminology to formal logic will be defined anytime in the next 10
years.  Come to think of it, thinking of Goedel makes me wonder if
it's even theoretically possible.

The above would seem to be just as applicable to the cert subject
authentication statement as it is to the CPS.  After all, the
authentication used in creating a particular cert is basically just
the application of the CPS to that particular subject.

 paul

Date: Fri, 11 Sep 1998 14:07:42 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

>>>>> "Mike" == Mike Smith <[email-masked]> writes:

 Mike> ...Maybe the old PKIX 1 needs to be restructured to retain its
 Mike> contents and menaing, but to specify a parsable structure and
 Mike> standardize (define rigidly) the terms used in the policies and
 Mike> practices or concept of operations (whatever people are using
 Mike> the OID to point towards).

 Mike> ...The feedback I get is not really "you are off track", but that
 Mike> "the problem is too big to solve", or that this group is
 Mike> incapable of solving this problem in a timely manner.

 Mike> I disagree.  This group is comprised of the most experienced
 Mike> and, IMO, brightest technologists in the industry.

 Mike> So, I pose the question to the best and brightest: How do you
 Mike> suggest, then that we automate domain or trust processing?

I think the question you pose is not a little, but vastly beyond the
state of the art.

As I understand it, the goal you're posing is: define a way for the CA 
to encode into the cert information that the relying party can use to
decide whether the subject of that cert was authenticated by means
strong enough to be satisfactory to the relying party.

A somewhat analogous question (though not applicable to a particular
cert) is whether the CA's CPS is strong enough for the relying party.

It seems to me that this latter question is one you drop onto your
company's lawyer to settle.  It involves parsing natural language
(well, anyway, legal language) to see what it means, and whether that
meaning is satisfactory to your corporate requirements.

I very much doubt that a mapping from natural language legal
terminology to formal logic will be defined anytime in the next 10
years.  Come to think of it, thinking of Goedel makes me wonder if
it's even theoretically possible.

The above would seem to be just as applicable to the cert subject
authentication statement as it is to the CPS.  After all, the
authentication used in creating a particular cert is basically just
the application of the CPS to that particular subject.

	paul

Date: Fri, 11 Sep 1998 10:16:37 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

OK, the quagmire consensus is taken for what it is.  I first proposed automating some trust decisions using a new extension, then using the existing policy qualifier.  The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient.

If this is to be the technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards.

Maybe the old PKIX 1 needs to be restructured to retain its contents and meaning, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies ,  practices or concept of operations (whatever people are using the OID to point towards).

The goal here is not to reopen old wounds or pull people into yet another quagmire (my Celtic genetics may predispose me to jumping inot bogs, however).  The question that folks seem to be attempting to address is the automation of trust domains.  

The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner.

I disagree.  This group is comprised of the most experienced and, IMO, brightest technologists in the industry.  

So, I pose the question to the best and brightest:  How do you suggest, then, that we automate domain or trust processing?

I think I know how we are going to operate across domains of trust  in the finanical industry.  I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet.

If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time).

Michael

>>> Stefan Santesson <[email-masked]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************

Date: Fri, 11 Sep 1998 10:11:04 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

OK, the quagmire consensus is taken for what it is.  I first proposed enhancing automating some trust decisions using a new extension, then using the existing policy qualifier.  The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient.

If this is to be technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards.

Maybe the old PKIX 1 needs to be restructured to retain its contents and menaing, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies and practices or concept of operations (whatever people are using the OID to point towards).

The goal here is not to reopen old wounds or pull people into yet another quagmire (my cletic genetics may predispose me to jumping inot bogs, however).  The question that folks seem to be attemoting to address is the automation of trust domains.  

The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner.

I disagree.  This group is comprised of the most experienced and, IMO, brightest technologists in the industry.  

So, I pose the question to the best and brightest:  How do you suggest, then that we automate domain or trust processing?

I think I know how we are going to operate across domains of trust  in the finanical industry.  I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet.

If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time).

Michael

>>> Stefan Santesson <[email-masked]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************

Date: Fri, 11 Sep 1998 11:06:33 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: [email-masked]
CC: Santosh Chokhani <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: forward & reverse elements - population
Sender: [email-masked]

Dennis,
	
	See comments below.

Denis Pinkas wrote:
> 
> Santosh,
> 
> Here is my answer to your question.
> 
> > Denis:
> 
> > I agree with you.  Clarification of the text is easy.
> 
> ???
> 
> > However, I have a
> > question.  Must a certificate issued to a CA appear in the forward
> > element, caCertificate or can it be missing altogether?
> 
> "MUST" is the wrong verb. A certificate issued by another CA is not
> mandated to be present at all. It MAY be present.
> 
> Let me now re-phrase your question: May a certificate issued to a CA by
> another CA appear in the forward element, caCertificate or can it be
> missing altogether?
> 
> My answer is the following: It may only appear in the forward element of
> a crossCertificatePair.
> 
> I was quite happy (and still am I !) with the original text. I still
> wonder with the rational of the two buckets.
> 

	The problem with the original text is that it breaks the
implementations
that used the certificationAuthority-V2 object class.  That object class
stated
the caCertificate was mandatory.  

	This has been established and accepted, therefore the original text
is not an option anymore.

	We have heard arguments from both sides for option 1 and option 2. Each
of which have their own pros and cons.  I suggest we stick with those
two options
and move forward.

	Furthermore, Santosh has submitted strong technical arguments for
the two bucket approach.  The two bucket approach allows you to
logically
distinguish between two types of CA Certs without mandating that a CA
define
its policies with respect to bucket population.  If the CA publishes it
in 
the "wrong" bucket it will NOT compromise security and it will NOT cause
a 
denial of service, as long as clients look at both attributes.  It lead 
to inefficient path construction in the worst case, but that's a given
if you
have a one bucket approach.  

	Another issue is the duplication of certificates.  After profiling
at least one directory server we know that performance degrades after an
entry reaches a certain size.  In other words you can usually get
excellent
sub second response time out of a server ( in fact many responses per
second )
if the entry stays small.  As the entry grows in size, the response gets
slower.
We have tested with entries up to several megabytes in size and have
proved this.  Additionally, many companies still use small pipes for
their network infrastructure, and those pipes can be easily saturated. 
We should make a conscious decision to
attempt to minimize the amount of data a client will retrieve from a
single entry
while satisfying both option 1 and option 2 proponents.

> Up to now, none of the arguments about the notion of "local domain" has
> proven to be non-controversy. If the notion of local domain is important
> (I still wonder about it), there might be a different way to look at the
> issue. LDAPv2 allows to query any server that offers that interface, so
> different set of queries could be considered:
> 
>   1) Queries made to one or more local domain servers,
>   2) Queries made to one or more public domain servers.
> 
> As the name indicates it, local domain servers may not be publicly
> accessible, e.g. protected by firewalls or some other access control
> methods. Local domain servers would publish only what is relevant for
> their notion of local domain. They must publish everything that is
> relevant.
> 
> Public domain servers would have no notion of "local domain". They must
> publish everything certificate that is pertinent to a CA entry that they
> publish. If entries for CA1, CA4 and CA5 are present, then all
> certificates issued by these CAs must be present and all
> cross-certificates, if any, between these CAs must also be present.
> However, a cross-certificate issued by the CA 7 for the CA 1 would not
> need to be present.

	Are you saying the schema/or the DIT structure will be different
for a CA in a public directory vs a private directory?  If so, I think
we are going down a dangerous path.  Given a globally unique DN why
would you want to do this?

Dave Horvath

> 
> Denis
> 
> > I think the text in terms of saying that the forward element need not be
> > present in all cases is easy.
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [SMTP:[email-masked]]
> > > Sent: Wednesday, September 09, 1998 8:44 PM
> > > To:   Santosh Chokhani
> > > Cc:   'Sharon Boeyen'; [email-masked]'
> > > Subject:      Re: forward & reverse elements - population
> > >
> > > Santosh,
> > >
> > > Your new proposed text does not address my concern correctly.
> > >
> > > For a crossCertificatePair Attribute, either the forward element only
> > > MAY be present, or the reverse element only MAY be present, or the
> > > reverse and the forward elements may be both present.
> > >
> > > Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward
> > > element
> > > shall not be mandated to be present in a crossCertificatePair
> > > Attribute.
> > >
> > > Denis
> > >
> > > > Sharon:
> > >
> > > > I can agree to the following text for the two option instead.
> > > Please
> > > > note that I have further clarified cross-certificate by tying the DN
> > > and
> > > > public keys.
> > > >
> > > > I think the following texts are consistent with and further
> > > > clarifications of the two options.
> > > >
> > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > >
> > > > NEW PROPOSED TEXT FOR OPTION 1
> > > >
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in the
> > > same
> > > > domain as this CA.
> > > >
> > > > The forward element of the crossCertificatePair attribute, held in a
> > > > particular CA's directory entry, shall be used to store certificates
> > > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > > element of the crossCertificatePair attribute, held in a particular
> > > CA's
> > > > directory entry, may contain a subset of certificates issued by this
> > > CA
> > > > to other CAs.  When both the forward and the reverse elements are
> > > > present, issuer name in one certificate shall match the subject name
> > > in
> > > > the other and vice versa, and the subject public key in one
> > > certificate
> > > > shall be capable of verifying the digital signature on the other
> > > > certificate and vice versa.
> > > >
> > > > In the case of V3 certificates, none of the above CA certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to FALSE.
> > > >
> > > > The definition of domain is purely a matter of local policy.
> > > >
> > > > NEW PROPOSED TEXT FOR OPTION 2
> > > >
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in the
> > > same
> > > > domain as this CA.
> > > >
> > > > The forward element of the crossCertificatePair attribute, held in a
> > > > particular CA's directory entry, shall be used to store all
> > > certificates
> > > > issued to this CA.  Optionally, the reverse element of the
> > > > crossCertificatePair attribute, held in a particular CA's directory
> > > > entry, may contain a subset of certificates issued by this CA to
> > > other
> > > > CAs.  When both the forward and the reverse elements are present,
> > > issuer
> > > > name in one certificate shall match the subject name in the other
> > > and
> > > > vice versa, and the subject public key in one certificate shall be
> > > > capable of verifying the digital signature on the other certificate
> > > and
> > > > vice versa.
> > > >
> > > > In the case of V3 certificates, none of the above CA certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to FALSE.
> > > >
> > > > The definition of domain is purely a matter of local policy.
> > > >
> > > > > -----Original Message-----
> > > > > From: Sharon Boeyen [SMTP:[email-masked]]
> > > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > > To:   [email-masked]'; 'Santosh Chokhani'
> > > > > Subject:      RE: forward & reverse elements - population
> > > > >
> > > > >
> > > > >
> > > > > > ----------
> > > > > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > > > > Sent:       September 8, 1998 10:05 AM
> > > > > > To:         'Sharon Boeyen'; [email-masked]'
> > > > > > Subject:    RE: forward & reverse elements - population
> > > > > >
> > > > >       --stuff deleted
> > > > > > >
> > > > > >     []  I agree.  I do not have problem with the following
> > > language.
> > > > > > " A certificate issued to a CA by another shall be stored either
> > > in
> > > > > the
> > > > > > caCertificate or forward component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the subject CA.  Optionally, a subset of certificates issued by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA."
> > > > > >
> > > > > >     Please note that to me subset includes none, some, or all.
> > > If
> > > > > > folks want further clarification, it is ok by me.
> > > > > >
> > > > > Santosh, the only issue I have with this text is that (at least
> > > with
> > > > > the
> > > > > rationale behind option 2) any cert that appears in the
> > > cACertificate
> > > > > attribute of a given CA
> > > > > entry, should also appear in the crossCertificatePair attribute in
> > > the
> > > > > same
> > > > > CA entry.
> > > > >  What about deleting the reference to the cACertificate attribute
> > > from
> > > > > your
> > > > > text and proposing this as new text just for the
> > > crossCertificatePair
> > > > > attribute?
> > > > >
> > > > > Both Jan and David have indicated reasons to keep the "pair"
> > > together
> > > > > in the
> > > > > mutual case, so we should also consider adding the last paragraph
> > > of
> > > > > the
> > > > > text David proposed for that.
> > > > >
> > > > > Here's what the resulting text proposal would look like:
> > > > >
> > > > > > " A certificate issued to a CA by another shall be stored in the
> > > > > > forward component of crossCertificatePair attribute of
> > > > > > the subject CA.  Optionally, a subset of certificates issued by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA. When both elements are present in the same
> > > value,
> > > > > the
> > > > > > value shall represent a mutual cross-certification of the two
> > > CAs. "
> > > > > >
> > > > > If we can come to consensus on that attribute, then let's see what
> > > we
> > > > > can do
> > > > > with the cACertificate attribute text.
> > > > >
> > > > > I agree with your view on what a subset is and I think that same
> > > > > definition
> > > > > would apply to the contents of the cACertificate attribute as a
> > > subset
> > > > > of
> > > > > the crossCertificatePair forward elements in option 2.
> > >
> > > --
> > >       Denis Pinkas     Bull S.A.          mailto:[email-masked]
> > >       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
> > >       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> 
> --
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Fri, 11 Sep 1998 16:44:21 +0200
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

This is really fascinating.

When I read the proposal for a new extension I said to my self:
Good this man i brave. I wonder how many seconds he will live before he is
gunned down.
Not because the idea is stupid. Just because of the obvious "quagmire"
syndrome.

I have recently studied one extensive trial to specify such extensions and
I just want to join to the consensus here. 

- This is a quagmire and not suited for standardization (at least not
within PKIX).
- The policy OID solves the problem as far needed.

And according to changing CPS:es. One CPS may change many times as long as it
reflects the same policy. If security drops below policy requirements then
a new
policy OID has to be identified. So minimum security level is defined by
policy 
and not by CPS.

/Stefan

At 01:48 PM 9/10/98 -0400, Phillip M Hallam-Baker wrote:
>
>> If we have standard identifiers, one byte each, provides 0 to 255 
>> specific categories, with say, ten as internet standards.
>> 
>> With initial authentication method, maybe we start with (decimal):
>>     0 as anonymous, 
>>     1 as self-authenticated, 
>>     2 as driver license or government ID card
>>     3 as passport
>>     4 as military
>
>This is heading straight into the quagmire I spoke about...
>
>Decimal numbers is just about the worst approach since it means that 
>a central registry has to be kept - yet another task for IANA! and
>the arbitrary limit of 255 sounds guaranteed to ensure that the
>namespace will quickly become cluttered with ad hoc private 
>definitions being used on an 'experimental' basis.
>
>I don't see any value in the taxonomy presented. What is a 'military'
>identification method? Is identification by the US army equivalent to
>that of the Taleban in Afghanistan?
>
>The drivers license is particularly dubious. My UK drivers license
>has no photograph and is valid until sometime after 2020.
>
>Are there CAs who actually want to specify their exact authorization 
>processes? Are such processes objectively definable? A commercial
>CA does not define authorization procedures for every concievable
>document they might accept in their CPS. The first time a US CA
>decides on acceptable forms of authentication for a Monaco 
>corporation is likely to be when they get a purchase request.
>
>
>If you want to take the matter further I suggest you write an
>Internet Draft and see if the working group chairs want to 
>make it a work item.
>
>		Phill
>
>

Date: Fri, 11 Sep 1998 11:23:10 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Santosh Chokhani <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: forward & reverse elements - population
Sender: [email-masked]

Santosh,

Here is my answer to your question.

> Denis:

> I agree with you.  Clarification of the text is easy.  

???

> However, I have a
> question.  Must a certificate issued to a CA appear in the forward
> element, caCertificate or can it be missing altogether?

"MUST" is the wrong verb. A certificate issued by another CA is not
mandated to be present at all. It MAY be present. 

Let me now re-phrase your question: May a certificate issued to a CA by
another CA appear in the forward element, caCertificate or can it be
missing altogether?

My answer is the following: It may only appear in the forward element of
a crossCertificatePair.

I was quite happy (and still am I !) with the original text. I still
wonder with the rational of the two buckets.

Up to now, none of the arguments about the notion of "local domain" has
proven to be non-controversy. If the notion of local domain is important
(I still wonder about it), there might be a different way to look at the
issue. LDAPv2 allows to query any server that offers that interface, so
different set of queries could be considered:

  1) Queries made to one or more local domain servers,
  2) Queries made to one or more public domain servers.

As the name indicates it, local domain servers may not be publicly
accessible, e.g. protected by firewalls or some other access control
methods. Local domain servers would publish only what is relevant for
their notion of local domain. They must publish everything that is
relevant. 

Public domain servers would have no notion of "local domain". They must
publish everything certificate that is pertinent to a CA entry that they
publish. If entries for CA1, CA4 and CA5 are present, then all
certificates issued by these CAs must be present and all
cross-certificates, if any, between these CAs must also be present.
However, a cross-certificate issued by the CA 7 for the CA 1 would not
need to be present.

Denis
 
> I think the text in terms of saying that the forward element need not be
> present in all cases is easy.
> 
> > -----Original Message-----
> > From: Denis Pinkas [SMTP:[email-masked]]
> > Sent: Wednesday, September 09, 1998 8:44 PM
> > To:   Santosh Chokhani
> > Cc:   'Sharon Boeyen'; [email-masked]'
> > Subject:      Re: forward & reverse elements - population
> >
> > Santosh,
> >
> > Your new proposed text does not address my concern correctly.
> >
> > For a crossCertificatePair Attribute, either the forward element only
> > MAY be present, or the reverse element only MAY be present, or the
> > reverse and the forward elements may be both present.
> >
> > Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward
> > element
> > shall not be mandated to be present in a crossCertificatePair
> > Attribute.
> >
> > Denis
> >
> > > Sharon:
> >
> > > I can agree to the following text for the two option instead.
> > Please
> > > note that I have further clarified cross-certificate by tying the DN
> > and
> > > public keys.
> > >
> > > I think the following texts are consistent with and further
> > > clarifications of the two options.
> > >
> > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > >
> > > NEW PROPOSED TEXT FOR OPTION 1
> > >
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > >
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store certificates
> > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > element of the crossCertificatePair attribute, held in a particular
> > CA's
> > > directory entry, may contain a subset of certificates issued by this
> > CA
> > > to other CAs.  When both the forward and the reverse elements are
> > > present, issuer name in one certificate shall match the subject name
> > in
> > > the other and vice versa, and the subject public key in one
> > certificate
> > > shall be capable of verifying the digital signature on the other
> > > certificate and vice versa.
> > >
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > >
> > > The definition of domain is purely a matter of local policy.
> > >
> > > NEW PROPOSED TEXT FOR OPTION 2
> > >
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > >
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store all
> > certificates
> > > issued to this CA.  Optionally, the reverse element of the
> > > crossCertificatePair attribute, held in a particular CA's directory
> > > entry, may contain a subset of certificates issued by this CA to
> > other
> > > CAs.  When both the forward and the reverse elements are present,
> > issuer
> > > name in one certificate shall match the subject name in the other
> > and
> > > vice versa, and the subject public key in one certificate shall be
> > > capable of verifying the digital signature on the other certificate
> > and
> > > vice versa.
> > >
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > >
> > > The definition of domain is purely a matter of local policy.
> > >
> > > > -----Original Message-----
> > > > From: Sharon Boeyen [SMTP:[email-masked]]
> > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > To:   [email-masked]'; 'Santosh Chokhani'
> > > > Subject:      RE: forward & reverse elements - population
> > > >
> > > >
> > > >
> > > > > ----------
> > > > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > > > Sent:       September 8, 1998 10:05 AM
> > > > > To:         'Sharon Boeyen'; [email-masked]'
> > > > > Subject:    RE: forward & reverse elements - population
> > > > >
> > > >       --stuff deleted
> > > > > >
> > > > >     []  I agree.  I do not have problem with the following
> > language.
> > > > > " A certificate issued to a CA by another shall be stored either
> > in
> > > > the
> > > > > caCertificate or forward component of crossCertificatePair
> > attribute
> > > > of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA."
> > > > >
> > > > >     Please note that to me subset includes none, some, or all.
> > If
> > > > > folks want further clarification, it is ok by me.
> > > > >
> > > > Santosh, the only issue I have with this text is that (at least
> > with
> > > > the
> > > > rationale behind option 2) any cert that appears in the
> > cACertificate
> > > > attribute of a given CA
> > > > entry, should also appear in the crossCertificatePair attribute in
> > the
> > > > same
> > > > CA entry.
> > > >  What about deleting the reference to the cACertificate attribute
> > from
> > > > your
> > > > text and proposing this as new text just for the
> > crossCertificatePair
> > > > attribute?
> > > >
> > > > Both Jan and David have indicated reasons to keep the "pair"
> > together
> > > > in the
> > > > mutual case, so we should also consider adding the last paragraph
> > of
> > > > the
> > > > text David proposed for that.
> > > >
> > > > Here's what the resulting text proposal would look like:
> > > >
> > > > > " A certificate issued to a CA by another shall be stored in the
> > > > > forward component of crossCertificatePair attribute of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA. When both elements are present in the same
> > value,
> > > > the
> > > > > value shall represent a mutual cross-certification of the two
> > CAs. "
> > > > >
> > > > If we can come to consensus on that attribute, then let's see what
> > we
> > > > can do
> > > > with the cACertificate attribute text.
> > > >
> > > > I agree with your view on what a subset is and I think that same
> > > > definition
> > > > would apply to the contents of the cACertificate attribute as a
> > subset
> > > > of
> > > > the crossCertificatePair forward elements in option 2.
> >
> > --
> >       Denis Pinkas     Bull S.A.          mailto:[email-masked]
> >       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
> >       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Graham Bland <[email-masked]>
Date: Fri, 11 Sep 1998 8:49:49 +0000
To: [email-masked]
Subject: RE: RE: New Extension Proposed: Method O
Sender: [email-masked]

I think this is impossible to achieve for the following reasons

1. 255 categories would be far too few, in practice they would expand to 
thousands.

2. With each category there are wide variations, drivers licences for example 
contain different details, have different validity periods, some have photos, 
some don't and they are issued by Governments (some of whom I would not 
trust). Are photocopies acceptable? Must the driving licence be presented in 
person or can it be posted? Need it be current?  All these have a substantial 
bearing on the degree of trust I can place in a certificate.

3. It would take us years to agree on the categories and the meanings

For these reasons this could not replace a CPS.

Graham Bland

> -----Original Message-----
> From: [email-masked]
> Sent: 10 September 1998 18:06
> To: Ian Roberts; Graham Bland; Chris Wright; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: RE: New Extension Proposed: Method O
>
>
> --------------------------------------------------------------
> --------------
> Maybe "new" extension is too strong a phrase.  How about
> defining the policy
> qulifiers to have some standard" meanings, then:
>
>    reliance limit
>    licensure, licensing body
>    authentication method
>    etc.
>
> If we have standard identifiers, one byte each, provides 0 to
> 255 specific
> categories, with say, ten as internet standards.
>
> With initial authentication method, maybe we start with (decimal):
>     0 as anonymous,
>     1 as self-authenticated,
>     2 as driver license or government ID card
>     3 as passport
>     4 as military
>
> then start with combinations including common attributes,
> such as credit
> bureau rating as of issuance, etc.
>
> I do understand that, while policy OIDs may be supported some largely
> deployed systems do not support the policy qualifiers, but
> the standards do,
> so why don't we use them to improve our automation needs.
> Any time we need
> to rely on individ
> uals obtaining, reading and being held accountable to a two
> hundred page
> contract (CPS), we limit its usability.
>
> Having standard definitions for the most common usages and
> having these
> signed as part of the cert by the issuer should facilitate
> automatic policy
> acceptance across those domains with multiple policies (if I
> have accepted
> all of the Verisig
> n roots, then all of the categories of authentication are
> accepted.  If each
> cert has the main characteristics of trust (initial authentication, CA
> licensure, reliance liits, CPS location/OID, etc.), then I
> should be able to
> set my acceptanc
> e on user selected criteria,
> without re-reading the two hundred pages of each of the CAs
> my company does
> business with.
>
> Michael
>
> >>> Santosh Chokhani <[email-masked]> 09/09 1:25 PM >>>
> The certificate policy is supposed to the represented in the
> certificate
> as an object identifier.  The amendment to X.509 defines how the
> applications process that field to determine if a certificate is
> acceptable, including certificate policy and associated authentication
> mechanism.
>
> X.509 amendment offer a rich set of capabilities in this area in terms
> of what goes in a certificate, and how applications perform path
> validation.
>
> > -----Original Message-----
> > From: Tony Bartoletti [SMTP:[email-masked]]
> > Sent: Wednesday, September 09, 1998 3:12 PM
> > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: New Extension Proposed: Method Of Authentication
> >
> > At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
> > >The subscriber authentication at the various stages (such
> as initial
> > >registration, registration after revocation, revocation request,
> > normal
> > >rekey, etc.) is supposed to be described in the certificate policy.
> > >Thus, the certificate policy asserted points to the authentication
> > >method.
> >
> > True, but this certainly places a limit upon the degree of
> automation
> > that can be employed in the future, at least until we have software
> > that can read a CPS and base decisions upon it.  No time soon.
> >
> > Granted, some 20 bits describing authentication method(s) would be
> > contentious, but the very exercise would reveal much about where and
> > how trust is really anchored, and the degree to which
> automated agents
> > could evolve.
> >
> > >There is NO need for another extension.
> >
> > Have enough work already? ;)
> >
> > ___tony___
> >
> > >> -----Original Message-----
> > >> From: Phillip M Hallam-Baker [SMTP:[email-masked]]
> > >> Sent: Wednesday, September 09, 1998 1:16 PM
> > >> To: Mike Smith; [email-masked]; [email-masked]
> > >> Cc: [email-masked]
> > >> Subject: RE: New Extension Proposed: Method Of Authentication
> > >>
> > >> > In using certificates, it is useful to know what form of
> > >> > authentication is used by a CA to identify a new certificate
> > >> > requester.  A certificate extension seems the best
> place to store
> >
> > >> > this information.
> > >>
> > >> This sounds to me like a trip into a quagmire. I don't think that
> > >> it is possible to charaterize authentication mechanisms usefully
> > >> in a set of binary flags.
> > >>
> > >> For example two CAs may be requiring presentation of a driving
> > >> license for authentication, only one CA may be using a state of
> > >> MA license with photo ID and another a UK driving license without
> > >> photo ID.
> > >>
> > >> Even with documents such as passports there is considerable
> > >> variation between countries in the strictness of their
> proceedures.
> > >>
> > >> Then there are proceedural variations, is the applicant present
> > >> in person or were the credentials merely faxed...
> > >>
> > >>
> > >> Nor is the mechanism of authentication by itself particularly
> > >> usefull unless there is an evaluation of the reliability of the
> > >> party performing it.
> > >>
> > >> Of course one can start to characterise these characteristics
> > >> as well but to do so merely throws up yet more information which
> > >> might be relevant, factors which become increasingly subjective.
> > >>
> > >>
> > >> This is a hard AI problem - establishing a shared vocabulary of
> > >> terms which permits exchange of concepts whose semantics are
> > >> not embedded in the communication mechanism or indeed any
> > >> mechanism for which a formal description is available.
> > >>
> > >>   Phill
> > >
> > >
> >
> > 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: 510-422-3881             LLLLLLLL
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

From: "Fillingham,  David W." <[email-masked]>
To: "'Mike Smith'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 15:21:09 -0400
Sender: [email-masked]

I agree with Phillip.

My folder containing the debate on the meaning of the non-repudiation
key usage bit contains 97 messages from people trying to define what
that one bit is supposed to mean.  Trying to convey security policies
via a similar method strikes me as doomed from the start.

Dave Fillingham

>----------
>From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent: 	Thursday, September 10, 1998 1:48 PM
>To: 	Mike Smith; [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Cc: 	[email-masked]
>Subject: 	RE: RE: New Extension Proposed: Method Of Authentication
>
>
>> If we have standard identifiers, one byte each, provides 0 to 255 
>> specific categories, with say, ten as internet standards.
>> 
>> With initial authentication method, maybe we start with (decimal):
>>     0 as anonymous, 
>>     1 as self-authenticated, 
>>     2 as driver license or government ID card
>>     3 as passport
>>     4 as military
>
>This is heading straight into the quagmire I spoke about...
>
>Decimal numbers is just about the worst approach since it means that 
>a central registry has to be kept - yet another task for IANA! and
>the arbitrary limit of 255 sounds guaranteed to ensure that the
>namespace will quickly become cluttered with ad hoc private 
>definitions being used on an 'experimental' basis.
>
>I don't see any value in the taxonomy presented. What is a 'military'
>identification method? Is identification by the US army equivalent to
>that of the Taleban in Afghanistan?
>
>The drivers license is particularly dubious. My UK drivers license
>has no photograph and is valid until sometime after 2020.
>
>Are there CAs who actually want to specify their exact authorization 
>processes? Are such processes objectively definable? A commercial
>CA does not define authorization procedures for every concievable
>document they might accept in their CPS. The first time a US CA
>decides on acceptable forms of authentication for a Monaco 
>corporation is likely to be when they get a purchase request.
>
>
>If you want to take the matter further I suggest you write an
>Internet Draft and see if the working group chairs want to 
>make it a work item.
>
>		Phill
>

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 13:48:20 -0400
Importance: Normal
Sender: [email-masked]

> If we have standard identifiers, one byte each, provides 0 to 255 
> specific categories, with say, ten as internet standards.
> 
> With initial authentication method, maybe we start with (decimal):
>     0 as anonymous, 
>     1 as self-authenticated, 
>     2 as driver license or government ID card
>     3 as passport
>     4 as military

This is heading straight into the quagmire I spoke about...

Decimal numbers is just about the worst approach since it means that 
a central registry has to be kept - yet another task for IANA! and
the arbitrary limit of 255 sounds guaranteed to ensure that the
namespace will quickly become cluttered with ad hoc private 
definitions being used on an 'experimental' basis.

I don't see any value in the taxonomy presented. What is a 'military'
identification method? Is identification by the US army equivalent to
that of the Taleban in Afghanistan?

The drivers license is particularly dubious. My UK drivers license
has no photograph and is valid until sometime after 2020.

Are there CAs who actually want to specify their exact authorization 
processes? Are such processes objectively definable? A commercial
CA does not define authorization procedures for every concievable
document they might accept in their CPS. The first time a US CA
decides on acceptable forms of authentication for a Monaco 
corporation is likely to be when they get a purchase request.

If you want to take the matter further I suggest you write an
Internet Draft and see if the working group chairs want to 
make it a work item.

		Phill

Date: Thu, 10 Sep 1998 09:59:21 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Maybe "new" extension is too strong a phrase.  How about defining the policy qulifiers to have some standard" meanings, then:

   reliance limit
   licensure, licensing body
   authentication method
   etc.

If we have standard identifiers, one byte each, provides 0 to 255 specific categories, with say, ten as internet standards.

With initial authentication method, maybe we start with (decimal):
    0 as anonymous, 
    1 as self-authenticated, 
    2 as driver license or government ID card
    3 as passport
    4 as military

then start with combinations including common attributes, such as credit bureau rating as of issuance, etc.

I do understand that, while policy OIDs may be supported some largely deployed systems do not support the policy qualifiers, but the standards do, so why don't we use them to improve our automation needs.  Any time we need to rely on individuals obtaining, reading and being held accountable to a two hundred page contract (CPS), we limit its usability.

Having standard definitions for the most common usages and having these signed as part of the cert by the issuer should facilitate automatic policy acceptance across those domains with multiple policies (if I have accepted all of the Verisign roots, then all of the categories of authentication are accepted.  If each cert has the main characteristics of trust (initial authentication, CA licensure, reliance liits, CPS location/OID, etc.), then I should be able to set my acceptance on user selected criteria, without re-reading the two hundred pages of each of the CAs my company does business with.

Michael

>>> Santosh Chokhani <[email-masked]> 09/09 1:25 PM >>>
The certificate policy is supposed to the represented in the certificate
as an object identifier.  The amendment to X.509 defines how the
applications process that field to determine if a certificate is
acceptable, including certificate policy and associated authentication
mechanism.

X.509 amendment offer a rich set of capabilities in this area in terms
of what goes in a certificate, and how applications perform path
validation.

> -----Original Message-----
> From: Tony Bartoletti [SMTP:[email-masked]] 
> Sent: Wednesday, September 09, 1998 3:12 PM
> To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [email-masked]; [email-masked] 
> Cc: [email-masked] 
> Subject: RE: New Extension Proposed: Method Of Authentication
> 
> At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
> >The subscriber authentication at the various stages (such as initial
> >registration, registration after revocation, revocation request,
> normal
> >rekey, etc.) is supposed to be described in the certificate policy.
> >Thus, the certificate policy asserted points to the authentication
> >method.
> 
> True, but this certainly places a limit upon the degree of automation
> that can be employed in the future, at least until we have software
> that can read a CPS and base decisions upon it.  No time soon.
> 
> Granted, some 20 bits describing authentication method(s) would be
> contentious, but the very exercise would reveal much about where and
> how trust is really anchored, and the degree to which automated agents
> could evolve.
> 
> >There is NO need for another extension.
> 
> Have enough work already? ;)
> 
> ___tony___
> 
> >> -----Original Message-----
> >> From: Phillip M Hallam-Baker [SMTP:[email-masked]] 
> >> Sent: Wednesday, September 09, 1998 1:16 PM
> >> To: Mike Smith; [email-masked]; [email-masked] 
> >> Cc: [email-masked] 
> >> Subject: RE: New Extension Proposed: Method Of Authentication
> >> 
> >> > In using certificates, it is useful to know what form of 
> >> > authentication is used by a CA to identify a new certificate 
> >> > requester.  A certificate extension seems the best place to store
> 
> >> > this information.
> >> 
> >> This sounds to me like a trip into a quagmire. I don't think that
> >> it is possible to charaterize authentication mechanisms usefully
> >> in a set of binary flags.
> >> 
> >> For example two CAs may be requiring presentation of a driving
> >> license for authentication, only one CA may be using a state of
> >> MA license with photo ID and another a UK driving license without
> >> photo ID.
> >> 
> >> Even with documents such as passports there is considerable 
> >> variation between countries in the strictness of their proceedures.
> >> 
> >> Then there are proceedural variations, is the applicant present
> >> in person or were the credentials merely faxed...
> >> 
> >> 
> >> Nor is the mechanism of authentication by itself particularly 
> >> usefull unless there is an evaluation of the reliability of the
> >> party performing it. 
> >> 
> >> Of course one can start to characterise these characteristics
> >> as well but to do so merely throws up yet more information which
> >> might be relevant, factors which become increasingly subjective.
> >> 
> >> 
> >> This is a hard AI problem - establishing a shared vocabulary of
> >> terms which permits exchange of concepts whose semantics are
> >> not embedded in the communication mechanism or indeed any 
> >> mechanism for which a formal description is available.
> >> 
> >>   Phill
> >
> >
> 
> 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: 510-422-3881             LLLLLLLL

Date: Thu, 10 Sep 1998 08:49:00 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
Sender: [email-masked]

This draft may interest people in the PKIX group. It is also available from
<http://www.imc.org/draft-ietf-ipsec-pki-req>.

--Paul Hoffman, Director
--Internet Mail Consortium

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
>Date: Thu, 10 Sep 1998 10:34:19 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the IP Security Protocol Working Group of the
IETF.
>
>	Title		: PKI Requirements for IP Security
>	Author(s)	: R. Thayer
>	Filename	: draft-ietf-ipsec-pki-req-00.txt
>	Pages		: 22
>	Date		: 09-Sep-98
>	
>          The IP Security (IPSec) protocol set now being defined in the
>          IETF uses public key cryptography for authentication in it's key
>          management protocol.  This document defines the requirements that
>          IPSec has for Public Key Infrastructure (PKI) protocols, formats,
>          and services.
> 
>          The key words 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and
>          'MAY' in this document are to be interpreted as described in RFC
>          2119.
> 
>          Please send comments on this document to the [email-masked]
>          mailing list.
>
>Internet-Drafts are 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-ipsec-pki-req-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-00.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nis.garr.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[email-masked].  In the body type:
>	"FILE /internet-drafts/draft-ietf-ipsec-pki-req-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.
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ipsec-pki-req-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-00.txt>
> 

From: Eric Murray <[email-masked]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [email-masked] (Paul Koning)
Date: Thu, 10 Sep 1998 08:19:49 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Paul Koning writes:
 
> 
> Incidentally, as an aside -- this discussion made me worry about the
> potential for unrestrained growth of certificates.  As someone
> involved in building diskless (embedded) systems, megabyte-sized certs 
> worry me a lot.

Me too.  Our company also does embedded systems which need to
accept and verify certs.
Please keep your certs small if you really want
them to be ubiquitous.  I'd much rather see a URI and perhaps
a hash in the cert instead of the entire CPS.

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

Date: Thu, 10 Sep 1998 09:21:30 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

>>>>> "Tony" == Tony Bartoletti <[email-masked]> writes:
>...
 Tony> Still, suppose the certificate did contain the CPS hash.
 Tony> Imagine that a client system, in the course of validating
 Tony> certificates, determines that a particular CPS has changed.
 Tony> That is, some of the certs point to the older CPS, and some to
 Tony> a brand new CPS.  Assume further that it can (securely)
 Tony> retrieve both the older and newer CPS at will.  It can still
 Tony> validate the older certs, but it can do nothing with the newer
 Tony> ones until a human steps in to read the new CPS, and then
 Tony> determine its sufficiency for the purpose(s) at hand.

 Tony> In terms of automation, "the bits stop here."

I think that's as it should be.  Whether a new CPS is sufficient for
the purposes at hand, in any situation where someone cares enough to
look at the CPS at all, is a question that undoubtedly involves
lawyers, or even people involved in still less formal processes.

Until and unless someone comes up with a mapping from legal english to 
formal logic (unlikely given Goedel's theorem) I believe the bits HAVE 
to stop where you said.

Incidentally, as an aside -- this discussion made me worry about the
potential for unrestrained growth of certificates.  As someone
involved in building diskless (embedded) systems, megabyte-sized certs 
worry me a lot.

	paul

From: "Shailesh" <[email-masked]>
To: <[email-masked]>
Subject: PKIX transports using HTTP
Date: Thu, 10 Sep 1998 18:38:54 +0530
Sender: [email-masked]

1. What is more standard way of communicating PKIX
messages on HTTP : 

Put them as a part of URL
OR Put them in the "Entity (optional) part of the request and response"

2. What extensions of the HTTP or part of the core protocol
talks about polling? How does one poll using HTTP?

Thanks with best regards

Shailesh

Date: Thu, 10 Sep 1998 14:53:26 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Eric Murray <[email-masked]>
CC: [email-masked]
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Eric Murray wrote:
 
> Santosh Chokhani writes:

> > The subscriber authentication at the various stages (such as initial
> > registration, registration after revocation, revocation request, normal
> > rekey, etc.) is supposed to be described in the certificate policy.
> > Thus, the certificate policy asserted points to the authentication
> > method.

> > There is NO need for another extension.
 
> I agree that putting the policy into an extension is a quagmire.
 
> However, given that most CPSs will be on web sites, and those
> CPSs can be changed at any time, should there be a way to
> indicate which CPS is in effect at any given time during
> the certificate's life?
 
> Say Fred is issued a cert by Carl the CA.  Carl signs Fred's
> cert under the then-current CPS 1.2, which required Carl
> to verify Fred's identity using dental charts.   Sometime
> later, Carl changes his CPS to version 1.3, which no longer requires
> dental charts as a form of identification, but instead
> accepts a state driver's license.
 
> Fred would like to sign a contract to purchase a house.  The lender
> requires a high-quality signature, and a cert with only a state
> driver's license as identification isn't good enough.  How does Fred
> indicate that his cert was issued under the older, more rigorous CPS?

You are adressing an important issue. When you sign a contract, you
usually look at the back of the page where there is either the full
terms of the contract or a short form of them with a pointer to a full
form. It is thus important to know whether you agree or not with these:
if yes, you sign, if not you don't. 

The equivalent in electronic terms is to point to a security policy and
sign it (i.e. add the security policy to the core of the signed message
and sign the whole). Different pointers may be used. Here are two
examples: an OID, a URL address. If the policy changes, the pointer must
change. A hash of the policy has to be used to make sure which terms you
were agreeing with. 

These terms will indicate which CAs are adequate to be used by the
signers and which security policies from that CA will be adequate to be
used, relative to these terms.

> One way to deal with this is to revoke all certs issued under a
> given CPS when it is changed.  I'm not sure that that provides any assurance
> that a given cert was issued under the current CPS though- a receiving
> party would have to depend on the current CPS stating that such
> is the policy.  And it's obviously very undesireable from a CA standpoint.

Indeed !

> Another way would be to require the CA to sign their CPSs and include
> version numbers, and to include in the cert extension which points to
> the CPS, the version number of the CPS which was in effect when the cert
> was issued.  This will prevent CAs from updating CPSs "out from
> underneath" existing certs.  That may or may not be a desired effect.

:-(

> I did a very quick read of the draft and didn't see anything that
> handles this problem.  But I have not been following the discussion very
> much and have not studied the draft, so I could well have missed it.  If
> there's already something in the draft to deal with this, or this
> subject has already been discussed on the list, please accept my
> apologies.

You did not missed it, the draft is silent on this kind of topic, but it
would not be the right place anyway to place it. At the Chicago meeting,
we talked about expanding the work to handle non repudiation in more
details. If such an extension of the work happens, then we could
possibly deal with this kind of topic.

Denis
 
> --
> Eric Murray          N*Able Technologies                    www.nabletech.com
> (email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Thu, 10 Sep 1998 14:25:40 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Mike Smith <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Mike Smith wrote:
> 
> In using certificates, it is useful to know what form of 
> authentication is used by a CA to identify a new certificate 
> requester.  A certificate extension seems the best place to store 
> this information.
> 
> At one time, Bob Jeuneman prepared a paper proposing this extension 
> and detailing many categories, from anonymous, self-authenticated, 
> self authenticated with data verifired (or with credit account, etc.),
> authenticated in person, in person with governement-issued picture ID, 
> multiple forms of government picture IDs with current credit reports 
> and corporate D&B, etc.
 
> The current practice, I beleive, is to embed the authentication 
> mechanism in a CA operations or policy statement tha may or may not 
> be online for someone to peruse and make their own judgement.  
> Putting a clear indicator in the signed cert would help.
 
> Comments?  Bob?

If we were going in that direction then we might need to indicate
whether one or more of the following has been presented: a driving
license, a passport, an ID card, a bill from an Electricity supplier, a
bill from a Telephone company, a bill from a Water supplier, etc ... We
already have (too) many extensions. The policy statement is enough.
There is no need for a verifier to understand the details of the policy,
but only to know whether the policy is acceptable for the application. 

Denis
 
> Michael
-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Abhay Kulkarni" <[email-masked]>
To: <[email-masked]>
Subject: PKIX Certificate Management Protocols
Date: Thu, 10 Sep 1998 17:54:53 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01BDDCE4.1D99E100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello everybody,
Where do we find extra information about how to use HTTP protocol as the =
lower layer in the PKI certificate management protocol ?
Thanks in advance.
Regards.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Abhay Kulkarni
Systems Engineer
Frontier Computers Pvt. Ltd.
EMail:  [email-masked]
Web: http://www.fcpl.co.in
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

------=_NextPart_000_0028_01BDDCE4.1D99E100
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.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT color=3D#000000 size=3D2>Hello everybody,</FONT></DIV>
<DIV><FONT size=3D2>Where do we find extra information about how to use =
HTTP=20
protocol as the lower layer in the PKI certificate management protocol=20
?</FONT></DIV>
<DIV><FONT size=3D2>Thanks in advance.</FONT></DIV>
<DIV><FONT size=3D2>Regards.</FONT></DIV>
<DIV><FONT color=3D#000000 =
size=3D2>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<BR>Abhay=20
Kulkarni<BR>Systems Engineer<BR>Frontier Computers Pvt. =
Ltd.<BR>EMail:&nbsp; <A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR>Web: <A=20
href=3D"http://www.fcpl.co.in">http://www.fcpl.co.in</A><BR>%%%%%%%%%%%%%=
%%%%%%%%%%%%%%%%%%%%%</FONT></DIV></BODY></HTML>

------=_NextPart_000_0028_01BDDCE4.1D99E100--

Date: Thu, 10 Sep 1998 08:07:16 -0400
From: William Dziadyk <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

---------------------------------------------------------------------------------
   William Dziadyk, PEng
   IT Security Services, DOMUS Software, Ottawa, Ontario, Canada 
   (613) 230-6285  ext 342  ----   [email-masked] 
 ---------------------------------------------------------------------------------

Date: Thu, 10 Sep 1998 12:27:57 +0530
From: Narayan Raghu <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

Hello, 

Ultimately, it is the verifier of a certificate who decides if a
certification authority is to be trusted. Hence, the onus is on him to
verify the policies of the CA and decide whether to designate that CA as
the trusted root. 

IF a CA changes it's policy, it could simply generate another keypair,
which signes certificates verifed by the new method.  That way, the
verifier can decide whether to designate the new CA certificate as
trusted root or not, depending upon the new policy of the CA. The
verifier can thus choose to trust all those certified by the old CA
Certificate/Keypair, since the old policy was acceptable. 
The key here is that we link a new CA policy with a mandatory new CA
signing keypair.

I dont think it's required to mention the verifying method in the
certificate, since it's the certificate verifier's responsibility.

narayan 
ibm bangalore
india

Paul Hoffman / IMC wrote:
> 
> At 04:20 PM 9/9/98 -0700, Tony Bartoletti wrote:
> >There are two significant shortcomings with the existing situation,
> >nonetheless.  First, as pointed out by Eric Murray, is that this
> >"pointer to the certificate policy" is a weak link in a critical
> >chain to the foundation of trust.
> 
> Then don't validate certs with CPSs; only validate ones with OIDs that
> you
> understand.
> 
> Remember, these policies are for CAs who you have already decided you
> trust
> to sign someone else's key. If you don't trust them not to change
> their
> CPS, why do you trust that they are even following the CPS you looked
> up
> once? Any reasonable CA who changes their CPS will keep the old one at
> the
> original URL and create a new CPS with a new URL, and put the new URL
> in
> certs that conform to the new policy.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: Santosh Chokhani <[email-masked]>
To: "'Tony Bartoletti'" <[email-masked]>, Phillip M Hallam-Baker <[email-masked]>, Santosh Chokhani <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked], Eric Murray <[email-masked]>
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 20:00:00 -0400
Sender: [email-masked]

Tony:

I think certificate policies are supposed to take care of this.  Clients
need not read CP or CPS.  One may put CPS digest in an already defined
extension in the certificate.

> -----Original Message-----
> From:	Tony Bartoletti [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 7:20 PM
> To:	Phillip M Hallam-Baker; Santosh Chokhani; Mike Smith;
> [email-masked]; [email-masked]; Eric Murray
> Cc:	[email-masked]
> Subject:	RE: New Extension Proposed: Method Of Authentication
> 
> At 03:39 PM 9/9/98 -0400, Phillip M Hallam-Baker wrote:
> >
> >> The subscriber authentication at the various stages (such as
> initial
> >> registration, registration after revocation, revocation request,
> normal
> >> rekey, etc.) is supposed to be described in the certificate policy.
> >> Thus, the certificate policy asserted points to the authentication
> >> method.
> >
> >True. What I interpreted the proposal to be however was an abstract
> >syntax for describing certificate policy in a form that would allow
> >automated evaluation. There is a big difference between putting a 
> >pointer to the certificate policy into a cert and attempting to
> encode 
> >the certificate policy within the certificate itself.
> >
> >While such a facility would be 'nice to have' my experience is that
> >it is a very hard AI problem, at least as hard as the problem of
> >natural language understanding.
> 
> Phill,
> 
> I do understand, and would expect any attempt to address the stated
> shortcomings via an extension (or any other method) to be a multi-year
> effort:)
> 
> There are two significant shortcomings with the existing situation,
> nonetheless.  First, as pointed out by Eric Murray, is that this
> "pointer to the certificate policy" is a weak link in a critical
> chain to the foundation of trust.  I recall (two years ago!) this
> very subject was debated on this list, with some calls to have the
> cert contain a hash of the CPS in effect at the time of certificate
> creation, so there could be no subtle (or not so subtle) rewording
> of the CPS after the fact.  Alas, no such provisions were included.
> 
> Still, suppose the certificate did contain the CPS hash.  Imagine
> that a client system, in the course of validating certificates,
> determines that a particular CPS has changed.  That is, some of the
> certs point to the older CPS, and some to a brand new CPS.  Assume
> further that it can (securely) retrieve both the older and newer CPS
> at will.  It can still validate the older certs, but it can do nothing
> with the newer ones until a human steps in to read the new CPS, and
> then determine its sufficiency for the purpose(s) at hand.
> 
> In terms of automation, "the bits stop here."
> 
> Its just an observation...
> 
> ___tony___
> 
> >There is a project in the International Chamber of Commerce called 
> >ETerms which addresses the problem of providing a CPS repository
> >and which has as a long term goal the establishment of a shared
> >vocabulary of contract terms.
> >
> >This enterprise is best described as 'chock full o' lawyers'. Many
> >of the issues being delt with involve subtle and obscure points
> >of international law - such as the fact that the criteria for
> >establishing constructive notice vary according to the jurisdiction.
> >
> >Significantly the E-Terms project is not attempting to establish a
> >taxonomy of trade terms in common use. I don't think such a 'top
> >down' approach is feasible. Instead what is being attempted is a 
> >convergence of the user community towards the use of a common 
> >vocabulary which is itself a product of the process. This is more
> >of a bottom-up, evolutionary approach.
> >
> >		Phill
> >
> >
> >
> >
> >
> 
> 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: 510-422-3881             LLLLLLLL

Date: Wed, 09 Sep 1998 16:58:57 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

At 04:20 PM 9/9/98 -0700, Tony Bartoletti wrote:
>There are two significant shortcomings with the existing situation,
>nonetheless.  First, as pointed out by Eric Murray, is that this
>"pointer to the certificate policy" is a weak link in a critical
>chain to the foundation of trust.

Then don't validate certs with CPSs; only validate ones with OIDs that you
understand.

Remember, these policies are for CAs who you have already decided you trust
to sign someone else's key. If you don't trust them not to change their
CPS, why do you trust that they are even following the CPS you looked up
once? Any reasonable CA who changes their CPS will keep the old one at the
original URL and create a new CPS with a new URL, and put the new URL in
certs that conform to the new policy.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 09 Sep 1998 16:20:25 -0700
To: "Phillip M Hallam-Baker" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>, Eric Murray <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: <[email-masked]>
Sender: [email-masked]

At 03:39 PM 9/9/98 -0400, Phillip M Hallam-Baker wrote:
>
>> The subscriber authentication at the various stages (such as initial
>> registration, registration after revocation, revocation request, normal
>> rekey, etc.) is supposed to be described in the certificate policy.
>> Thus, the certificate policy asserted points to the authentication
>> method.
>
>True. What I interpreted the proposal to be however was an abstract
>syntax for describing certificate policy in a form that would allow
>automated evaluation. There is a big difference between putting a 
>pointer to the certificate policy into a cert and attempting to encode 
>the certificate policy within the certificate itself.
>
>While such a facility would be 'nice to have' my experience is that
>it is a very hard AI problem, at least as hard as the problem of
>natural language understanding.

Phill,

I do understand, and would expect any attempt to address the stated
shortcomings via an extension (or any other method) to be a multi-year
effort:)

There are two significant shortcomings with the existing situation,
nonetheless.  First, as pointed out by Eric Murray, is that this
"pointer to the certificate policy" is a weak link in a critical
chain to the foundation of trust.  I recall (two years ago!) this
very subject was debated on this list, with some calls to have the
cert contain a hash of the CPS in effect at the time of certificate
creation, so there could be no subtle (or not so subtle) rewording
of the CPS after the fact.  Alas, no such provisions were included.

Still, suppose the certificate did contain the CPS hash.  Imagine
that a client system, in the course of validating certificates,
determines that a particular CPS has changed.  That is, some of the
certs point to the older CPS, and some to a brand new CPS.  Assume
further that it can (securely) retrieve both the older and newer CPS
at will.  It can still validate the older certs, but it can do nothing
with the newer ones until a human steps in to read the new CPS, and
then determine its sufficiency for the purpose(s) at hand.

In terms of automation, "the bits stop here."

Its just an observation...

___tony___

>There is a project in the International Chamber of Commerce called 
>ETerms which addresses the problem of providing a CPS repository
>and which has as a long term goal the establishment of a shared
>vocabulary of contract terms.
>
>This enterprise is best described as 'chock full o' lawyers'. Many
>of the issues being delt with involve subtle and obscure points
>of international law - such as the fact that the criteria for
>establishing constructive notice vary according to the jurisdiction.
>
>Significantly the E-Terms project is not attempting to establish a
>taxonomy of trade terms in common use. I don't think such a 'top
>down' approach is feasible. Instead what is being attempted is a 
>convergence of the user community towards the use of a common 
>vocabulary which is itself a product of the process. This is more
>of a bottom-up, evolutionary approach.
>
>		Phill
>
>
>
>
>

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: 510-422-3881             LLLLLLLL

From: "Corcoran, Dan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 9 Sep 1998 17:19:49 -0400 
Sender: [email-masked]

From: "Fillingham,  David W." <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, "'Mike Smith'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Tony Bartoletti'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:44:32 -0400
Sender: [email-masked]

Tony:

I agree with Santosh and Phillip on this matter - I don't think an
additional extension would help.

The method of verifying a subscriber's identity is one element of a
certificate policy that factors in the assurance of the binding between
an identity and a public key - but only one.  It seems we could go down
a path of defining another extension for liability limits, which may be
more important to many users, and another for technical security
mechanisms (e.g., is the private key protected using hardware, or
software), and another for "authorized certificate applications" (e.g.,
only good for Company X applications) and so on.

I see no need to automatically read CPS documents - X.509 already
specifies how the certificate policy extension should be processed.  If
a policy, including the subscriber I&A process, is acceptable to a
relying party for a specific application, then the certificate
processing application can accept the certificate asserting that policy.
 Some human being reads the policy, and makes this determination, based
on the entire policy, and then asserts the policy as one that is
"acceptable" for the application.  

If a public key system implementor wants to define a certificate policy
based exclusively on the initial subscriber registration identification
mechanism, they could do so.  I don't think this would be a good idea,
but it's certainly allowed by the standards, including the IETF
Certificate Policy and CPS Framework, and to my mind, is preferable to
defining another extension.

Dave Fillingham

>----------
>From: 	Tony Bartoletti[SMTP:[email-masked]]
>Sent: 	Wednesday, September 09, 1998 3:12 PM
>To: 	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
>[email-masked]; [email-masked]
>Cc: 	[email-masked]
>Subject: 	RE: New Extension Proposed: Method Of Authentication
>
>At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
>>The subscriber authentication at the various stages (such as initial
>>registration, registration after revocation, revocation request, normal
>>rekey, etc.) is supposed to be described in the certificate policy.
>>Thus, the certificate policy asserted points to the authentication
>>method.
>
>True, but this certainly places a limit upon the degree of automation
>that can be employed in the future, at least until we have software
>that can read a CPS and base decisions upon it.  No time soon.
>
>Granted, some 20 bits describing authentication method(s) would be
>contentious, but the very exercise would reveal much about where and
>how trust is really anchored, and the degree to which automated agents
>could evolve.
>
>>There is NO need for another extension.
>
>Have enough work already? ;)
>
>___tony___
>
>>> -----Original Message-----
>>> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
>>> Sent:	Wednesday, September 09, 1998 1:16 PM
>>> To:	Mike Smith; [email-masked]; [email-masked]
>>> Cc:	[email-masked]
>>> Subject:	RE: New Extension Proposed: Method Of Authentication
>>> 
>>> > In using certificates, it is useful to know what form of 
>>> > authentication is used by a CA to identify a new certificate 
>>> > requester.  A certificate extension seems the best place to store 
>>> > this information.
>>> 
>>> This sounds to me like a trip into a quagmire. I don't think that
>>> it is possible to charaterize authentication mechanisms usefully
>>> in a set of binary flags.
>>> 
>>> For example two CAs may be requiring presentation of a driving
>>> license for authentication, only one CA may be using a state of
>>> MA license with photo ID and another a UK driving license without
>>> photo ID.
>>> 
>>> Even with documents such as passports there is considerable 
>>> variation between countries in the strictness of their proceedures.
>>> 
>>> Then there are proceedural variations, is the applicant present
>>> in person or were the credentials merely faxed...
>>> 
>>> 
>>> Nor is the mechanism of authentication by itself particularly 
>>> usefull unless there is an evaluation of the reliability of the
>>> party performing it. 
>>> 
>>> Of course one can start to characterise these characteristics
>>> as well but to do so merely throws up yet more information which
>>> might be relevant, factors which become increasingly subjective.
>>> 
>>> 
>>> This is a hard AI problem - establishing a shared vocabulary of
>>> terms which permits exchange of concepts whose semantics are
>>> not embedded in the communication mechanism or indeed any 
>>> mechanism for which a formal description is available.
>>> 
>>> 		Phill
>>
>>
>
>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: 510-422-3881             LLLLLLLL
>

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:39:46 -0400
Importance: Normal
Sender: [email-masked]

> The subscriber authentication at the various stages (such as initial
> registration, registration after revocation, revocation request, normal
> rekey, etc.) is supposed to be described in the certificate policy.
> Thus, the certificate policy asserted points to the authentication
> method.

True. What I interpreted the proposal to be however was an abstract
syntax for describing certificate policy in a form that would allow
automated evaluation. There is a big difference between putting a 
pointer to the certificate policy into a cert and attempting to encode 
the certificate policy within the certificate itself.

While such a facility would be 'nice to have' my experience is that
it is a very hard AI problem, at least as hard as the problem of
natural language understanding.

There is a project in the International Chamber of Commerce called 
ETerms which addresses the problem of providing a CPS repository
and which has as a long term goal the establishment of a shared
vocabulary of contract terms.

This enterprise is best described as 'chock full o' lawyers'. Many
of the issues being delt with involve subtle and obscure points
of international law - such as the fact that the criteria for
establishing constructive notice vary according to the jurisdiction.

Significantly the E-Terms project is not attempting to establish a
taxonomy of trade terms in common use. I don't think such a 'top
down' approach is feasible. Instead what is being attempted is a 
convergence of the user community towards the use of a common 
vocabulary which is itself a product of the process. This is more
of a bottom-up, evolutionary approach.

		Phill

From: Santosh Chokhani <[email-masked]>
To: "'Tony Bartoletti'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:25:47 -0400
Sender: [email-masked]

The certificate policy is supposed to the represented in the certificate
as an object identifier.  The amendment to X.509 defines how the
applications process that field to determine if a certificate is
acceptable, including certificate policy and associated authentication
mechanism.

X.509 amendment offer a rich set of capabilities in this area in terms
of what goes in a certificate, and how applications perform path
validation.

> -----Original Message-----
> From:	Tony Bartoletti [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 3:12 PM
> To:	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: New Extension Proposed: Method Of Authentication
> 
> At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
> >The subscriber authentication at the various stages (such as initial
> >registration, registration after revocation, revocation request,
> normal
> >rekey, etc.) is supposed to be described in the certificate policy.
> >Thus, the certificate policy asserted points to the authentication
> >method.
> 
> True, but this certainly places a limit upon the degree of automation
> that can be employed in the future, at least until we have software
> that can read a CPS and base decisions upon it.  No time soon.
> 
> Granted, some 20 bits describing authentication method(s) would be
> contentious, but the very exercise would reveal much about where and
> how trust is really anchored, and the degree to which automated agents
> could evolve.
> 
> >There is NO need for another extension.
> 
> Have enough work already? ;)
> 
> ___tony___
> 
> >> -----Original Message-----
> >> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> >> Sent:	Wednesday, September 09, 1998 1:16 PM
> >> To:	Mike Smith; [email-masked]; [email-masked]
> >> Cc:	[email-masked]
> >> Subject:	RE: New Extension Proposed: Method Of Authentication
> >> 
> >> > In using certificates, it is useful to know what form of 
> >> > authentication is used by a CA to identify a new certificate 
> >> > requester.  A certificate extension seems the best place to store
> 
> >> > this information.
> >> 
> >> This sounds to me like a trip into a quagmire. I don't think that
> >> it is possible to charaterize authentication mechanisms usefully
> >> in a set of binary flags.
> >> 
> >> For example two CAs may be requiring presentation of a driving
> >> license for authentication, only one CA may be using a state of
> >> MA license with photo ID and another a UK driving license without
> >> photo ID.
> >> 
> >> Even with documents such as passports there is considerable 
> >> variation between countries in the strictness of their proceedures.
> >> 
> >> Then there are proceedural variations, is the applicant present
> >> in person or were the credentials merely faxed...
> >> 
> >> 
> >> Nor is the mechanism of authentication by itself particularly 
> >> usefull unless there is an evaluation of the reliability of the
> >> party performing it. 
> >> 
> >> Of course one can start to characterise these characteristics
> >> as well but to do so merely throws up yet more information which
> >> might be relevant, factors which become increasingly subjective.
> >> 
> >> 
> >> This is a hard AI problem - establishing a shared vocabulary of
> >> terms which permits exchange of concepts whose semantics are
> >> not embedded in the communication mechanism or indeed any 
> >> mechanism for which a formal description is available.
> >> 
> >> 		Phill
> >
> >
> 
> 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: 510-422-3881             LLLLLLLL

From: Eric Murray <[email-masked]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [email-masked] (Santosh Chokhani)
Date: Wed, 9 Sep 1998 12:24:18 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Santosh Chokhani writes:
> 
> The subscriber authentication at the various stages (such as initial
> registration, registration after revocation, revocation request, normal
> rekey, etc.) is supposed to be described in the certificate policy.
> Thus, the certificate policy asserted points to the authentication
> method.
> 
> There is NO need for another extension.

I agree that putting the policy into an extension is a quagmire.

However, given that most CPSs will be on web sites, and those
CPSs can be changed at any time, should there be a way to
indicate which CPS is in effect at any given time during
the certificate's life?

Say Fred is issued a cert by Carl the CA.  Carl signs Fred's
cert under the then-current CPS 1.2, which required Carl
to verify Fred's identity using dental charts.   Sometime
later, Carl changes his CPS to version 1.3, which no longer requires
dental charts as a form of identification, but instead
accepts a state driver's license.

Fred would like to sign a contract to purchase a house.  The lender
requires a high-quality signature, and a cert with only a state
driver's license as identification isn't good enough.  How does Fred
indicate that his cert was issued under the older, more rigorous CPS?

One way to deal with this is to revoke all certs issued under a
given CPS when it is changed.  I'm not sure that that provides any assurance
that a given cert was issued under the current CPS though- a receiving
party would have to depend on the current CPS stating that such
is the policy.  And it's obviously very undesireable from a CA standpoint.

Another way would be to require the CA to sign their CPSs and include
version numbers, and to include in the cert extension which points to
the CPS, the version number of the CPS which was in effect when the cert
was issued.  This will prevent CAs from updating CPSs "out from
underneath" existing certs.  That may or may not be a desired effect.

I did a very quick read of the draft and didn't see anything that
handles this problem.  But I have not been following the discussion very
much and have not studied the draft, so I could well have missed it.  If
there's already something in the draft to deal with this, or this
subject has already been discussed on the list, please accept my
apologies.

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

Date: Wed, 09 Sep 1998 12:12:19 -0700
To: Santosh Chokhani <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: [email-masked]
Sender: [email-masked]

At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
>The subscriber authentication at the various stages (such as initial
>registration, registration after revocation, revocation request, normal
>rekey, etc.) is supposed to be described in the certificate policy.
>Thus, the certificate policy asserted points to the authentication
>method.

True, but this certainly places a limit upon the degree of automation
that can be employed in the future, at least until we have software
that can read a CPS and base decisions upon it.  No time soon.

Granted, some 20 bits describing authentication method(s) would be
contentious, but the very exercise would reveal much about where and
how trust is really anchored, and the degree to which automated agents
could evolve.

>There is NO need for another extension.

Have enough work already? ;)

___tony___

>> -----Original Message-----
>> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
>> Sent:	Wednesday, September 09, 1998 1:16 PM
>> To:	Mike Smith; [email-masked]; [email-masked]
>> Cc:	[email-masked]
>> Subject:	RE: New Extension Proposed: Method Of Authentication
>> 
>> > In using certificates, it is useful to know what form of 
>> > authentication is used by a CA to identify a new certificate 
>> > requester.  A certificate extension seems the best place to store 
>> > this information.
>> 
>> This sounds to me like a trip into a quagmire. I don't think that
>> it is possible to charaterize authentication mechanisms usefully
>> in a set of binary flags.
>> 
>> For example two CAs may be requiring presentation of a driving
>> license for authentication, only one CA may be using a state of
>> MA license with photo ID and another a UK driving license without
>> photo ID.
>> 
>> Even with documents such as passports there is considerable 
>> variation between countries in the strictness of their proceedures.
>> 
>> Then there are proceedural variations, is the applicant present
>> in person or were the credentials merely faxed...
>> 
>> 
>> Nor is the mechanism of authentication by itself particularly 
>> usefull unless there is an evaluation of the reliability of the
>> party performing it. 
>> 
>> Of course one can start to characterise these characteristics
>> as well but to do so merely throws up yet more information which
>> might be relevant, factors which become increasingly subjective.
>> 
>> 
>> This is a hard AI problem - establishing a shared vocabulary of
>> terms which permits exchange of concepts whose semantics are
>> not embedded in the communication mechanism or indeed any 
>> mechanism for which a formal description is available.
>> 
>> 		Phill
>
>

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: 510-422-3881             LLLLLLLL

From: [email-masked]
To: [email-masked]
Date: Wed, 9 Sep 1998 14:51:15 -0500
Subject: For Option 2
Sender: [email-masked]

For Option 2

From: Santosh Chokhani <[email-masked]>
To: "'Kurn, David'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 14:04:50 -0400
Sender: [email-masked]

You seem to have captured the essence.

Please note that the preference could be reversed depending on the
application need and/or the environment.

You have to try a search to the end.  I do not think in graphs like this
there is an a priory way of encoding which links will lead to which
paths.  Depth first (or up to some depth) search is likely to be the PKI
path development strategy in combination with judicious use of AKID,
SKID, key usage, pathToName, and certificate policy matching rules.

> -----Original Message-----
> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 1:51 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Santosh
> 
> Hmm.... I think I see.  Perhaps the problem arises because of your use
> of
> the word domain.  Consider your 2nd and 3rd paragraph rewritten to
> omit the
> word "domain", such as:
> 
> 	The relying party will start with the assumption that the
> 	subscriber with whom it is trying to form a key management
> certificate
> 	path or digital signature certificate verification path is
> reachable
> by starting with the entries in the caCertificate Attribute.
> 
> 	If the above search fails, the
> 	relying party will continue with the assumption that the
> subscriber
> with
> 	whom it is trying to form a key management certificate path or
> digital
> 	signature certificate verification path is reachable by using
> the
> forward element of the crossCertificatePair attribute under
> 	option 1 and forward element of the (crossCertificatePair -
> 	caCertificate) under option 2 first.
> 
> 
> 
> Does this capture your intent and avoid the word "domain"?
> 
> Of course, I don't like my algorithm,  because it appears to imply a
> search
> to the end before trying the other branch.
> 
> David Kurn
> 
> 
> > -----Original Message-----
> > From:	Santosh Chokhani [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 10:32 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> [email-masked]'
> > Subject:	RE: forward & reverse elements - population
> > 
> > Let us say an application requires more communication within a
> domain.
> > 
> > Then the relying party will start with the assumption that the
> > subscriber with whom it is trying to form a key management
> certificate
> > path or digital signature certificate verification path is also in
> the
> > same domain and hence will follow the caCertificate attribute link
> > first.
> > 
> > If the application requires more communication across the domain,
> the
> > relying party will start with the assumption that the subscriber
> with
> > whom it is trying to form a key management certificate path or
> digital
> > signature certificate verification path is in another domain and
> hence
> > will use forward element of the crossCertificatePair attribute under
> > option 1 and forward element of the (crossCertificatePair -
> > caCertificate) under option 2 first.
> > 
> > If there is no bias in communication intra or inter domain, the
> relying
> > party has lost nothing and will always find a trust path, if there
> is
> > one.
> > 
> 	<SNIP>

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:50:42 -0700 
Sender: [email-masked]

Santosh

Hmm.... I think I see.  Perhaps the problem arises because of your use of
the word domain.  Consider your 2nd and 3rd paragraph rewritten to omit the
word "domain", such as:

	The relying party will start with the assumption that the
	subscriber with whom it is trying to form a key management
certificate
	path or digital signature certificate verification path is reachable
by starting with the entries in the caCertificate Attribute.

	If the above search fails, the
	relying party will continue with the assumption that the subscriber
with
	whom it is trying to form a key management certificate path or
digital
	signature certificate verification path is reachable by using the
forward element of the crossCertificatePair attribute under
	option 1 and forward element of the (crossCertificatePair -
	caCertificate) under option 2 first.

Does this capture your intent and avoid the word "domain"?

Of course, I don't like my algorithm,  because it appears to imply a search
to the end before trying the other branch.

David Kurn

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 10:32 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Let us say an application requires more communication within a domain.
> 
> Then the relying party will start with the assumption that the
> subscriber with whom it is trying to form a key management certificate
> path or digital signature certificate verification path is also in the
> same domain and hence will follow the caCertificate attribute link
> first.
> 
> If the application requires more communication across the domain, the
> relying party will start with the assumption that the subscriber with
> whom it is trying to form a key management certificate path or digital
> signature certificate verification path is in another domain and hence
> will use forward element of the crossCertificatePair attribute under
> option 1 and forward element of the (crossCertificatePair -
> caCertificate) under option 2 first.
> 
> If there is no bias in communication intra or inter domain, the relying
> party has lost nothing and will always find a trust path, if there is
> one.
> 
	<SNIP>

From: Santosh Chokhani <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, Mike Smith <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:44:32 -0400
Sender: [email-masked]

The subscriber authentication at the various stages (such as initial
registration, registration after revocation, revocation request, normal
rekey, etc.) is supposed to be described in the certificate policy.
Thus, the certificate policy asserted points to the authentication
method.

There is NO need for another extension.

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 1:16 PM
> To:	Mike Smith; [email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: New Extension Proposed: Method Of Authentication
> 
> > In using certificates, it is useful to know what form of 
> > authentication is used by a CA to identify a new certificate 
> > requester.  A certificate extension seems the best place to store 
> > this information.
> 
> This sounds to me like a trip into a quagmire. I don't think that
> it is possible to charaterize authentication mechanisms usefully
> in a set of binary flags.
> 
> For example two CAs may be requiring presentation of a driving
> license for authentication, only one CA may be using a state of
> MA license with photo ID and another a UK driving license without
> photo ID.
> 
> Even with documents such as passports there is considerable 
> variation between countries in the strictness of their proceedures.
> 
> Then there are proceedural variations, is the applicant present
> in person or were the credentials merely faxed...
> 
> 
> Nor is the mechanism of authentication by itself particularly 
> usefull unless there is an evaluation of the reliability of the
> party performing it. 
> 
> Of course one can start to characterise these characteristics
> as well but to do so merely throws up yet more information which
> might be relevant, factors which become increasingly subjective.
> 
> 
> This is a hard AI problem - establishing a shared vocabulary of
> terms which permits exchange of concepts whose semantics are
> not embedded in the communication mechanism or indeed any 
> mechanism for which a formal description is available.
> 
> 		Phill

From: Santosh Chokhani <[email-masked]>
To: "'Kurn, David'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 13:32:28 -0400
Sender: [email-masked]

Let us say an application requires more communication within a domain.

Then the relying party will start with the assumption that the
subscriber with whom it is trying to form a key management certificate
path or digital signature certificate verification path is also in the
same domain and hence will follow the caCertificate attribute link
first.

If the application requires more communication across the domain, the
relying party will start with the assumption that the subscriber with
whom it is trying to form a key management certificate path or digital
signature certificate verification path is in another domain and hence
will use forward element of the crossCertificatePair attribute under
option 1 and forward element of the (crossCertificatePair -
caCertificate) under option 2 first.

If there is no bias in communication intra or inter domain, the relying
party has lost nothing and will always find a trust path, if there is
one.

> -----Original Message-----
> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 1:12 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Santosh
> 
> I seem to sense a circularity of definition.   If I interpret your
> comment
> correctly, you place a cert in the caCertificate attribute if it
> belongs to
> the same domain, and you can determine that it's in the same domain by
> seeing if it's in the caCertificate attribute.  Exactly how I would
> use this
> in a computer program is unclear.   Perhaps you could sketch out some
> program logic one would use.
> 
> David
> 
> > -----Original Message-----
> > From:	Santosh Chokhani [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 9:53 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> [email-masked]'
> > Subject:	RE: forward & reverse elements - population
> > 
> > David:
> > 
> > In both options 1 and 2, a relying party can determine which issuing
> CAs
> > are considered in the domain of the subject CA by looking at
> > caCertificate attribute and the forward element of the
> > crossCertificatePair attribute.
> > 
> > In option 1, it is straightforward.
> > 
> > In option 2, you have to subtract the caCertificate from the
> > crossCertificatePair to get the two sets.
> > 
> > These two domains are from the subject CA's perspective.  It may or
> may
> > not be in the domain of the relying party.
> > 
> > > -----Original Message-----
> > > From:	Kurn, David [SMTP:[email-masked]]
> > > Sent:	Wednesday, September 09, 1998 12:16 PM
> > > To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > Santosh
> > > 
> > > Sorry to ask what must be a very naive question.  If, as you
> suggest,
> > > the
> > > "definition of a domain is purely a matter of local policy", then
> I
> > > think
> > > that the term "domain" is undefined for the purposes of a
> standard.
> > > If so,
> > > then I find it difficult to define any algorhithm (not necessarily
> > > computer
> > > based) or any process by which anyone could determine whether a CA
> is
> > > in the
> > > same or a different domain.
> > > 
> > > Think, for example, of a general purpose application program (like
> a
> > > mail
> > > client) trying to answer the question "is that CA inside or
> outside of
> > > my
> > > domain".  
> > > 
> > > Back in my college days, my math professors made it painfully
> clear
> > > that if
> > > you define a set, you must also provide a rule whereby you can
> > > determine
> > > whether a given element is inside or outside of that set.  Without
> > > such a
> > > rule, the set is undefined.
> > > 
> > > It may be that the definition of "domain" is elsewhere in the
> > > document, but
> > > I cannot find it.
> > > 
> > > David Kurn
> > > Compaq Computer Corp
> > > Electronic Commerce Stuff
> > > 
> > > > -----Original Message-----
> > > > From:	Santosh Chokhani [SMTP:[email-masked]]
> > > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > > To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > Yes. I agree.  The following is the revised text.
> > > > 
> > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.  If there are any self-issued certificates
> and
> > > they
> > > > require publication, the caCertificate attribute shall be used
> to
> > > store
> > > > them.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store
> certificates
> > > > issued to this CA by CAs in other domains.  Optionally, the
> reverse
> > > > element of the crossCertificatePair attribute, held in a
> particular
> > > CA's
> > > > directory entry, may contain a subset of certificates issued by
> this
> > > CA
> > > > to other CAs.  When both the forward and the reverse elements
> are
> > > > present, issuer name in one certificate shall match the subject
> name
> > > in
> > > > the other and vice versa, and the subject public key in one
> > > certificate
> > > > shall be capable of verifying the digital signature on the other
> > > > certificate and vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.  If there are any self-issued certificates
> and
> > > they
> > > > require publication, the caCertificate attribute shall be used
> to
> > > store
> > > > them.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store all
> > > certificates
> > > > issued to this CA.  Optionally, the reverse element of the
> > > > crossCertificatePair attribute, held in a particular CA's
> directory
> > > > entry, may contain a subset of certificates issued by this CA to
> > > other
> > > > CAs.  When both the forward and the reverse elements are
> present,
> > > issuer
> > > > name in one certificate shall match the subject name in the
> other
> > > and
> > > > vice versa, and the subject public key in one certificate shall
> be
> > > > capable of verifying the digital signature on the other
> certificate
> > > and
> > > > vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > > -----Original Message-----
> > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > Subject:	RE: forward & reverse elements - population
> > > > > 
> > > > > I agree that the texts below are consistent with the original
> > > intent
> > > > > of the
> > > > > 2 options and I also agree that they are clearer than the
> original
> > > > > texts
> > > > > except, possibly for coverage of self issued certificates.
> > > Shouldn't
> > > > > we also
> > > > > state explicitly that self issued certs are stored only in the
> > > > > cACertificate
> > > > > attribute for both options? 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh
> Chokhani
> > > > > > Subject: 	RE: forward & reverse elements - population
> > > > > > 
> > > > > > Sharon:
> > > > > > 
> > > > > > I can agree to the following text for the two option
> instead.
> > > > > Please
> > > > > > note that I have further clarified cross-certificate by
> tying
> > > the DN
> > > > > and
> > > > > > public keys.
> > > > > > 
> > > > > > I think the following texts are consistent with and further
> > > > > > clarifications of the two options.
> > > > > > 
> > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > > > > 
> > > > > And I option 2 :-)
> > > > > 
> > > > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > > > 
> > > > > > The cACertificate attribute, held in a particular CA's
> directory
> > > > > entry,
> > > > > > shall be used to store certificates issued to this CA by CAs
> in
> > > the
> > > > > same
> > > > > > domain as this CA.
> > > > > > 
> > > > > > The forward element of the crossCertificatePair attribute,
> held
> > > in a
> > > > > > particular CA's directory entry, shall be used to store
> > > certificates
> > > > > > issued to this CA by CAs in other domains.  Optionally, the
> > > reverse
> > > > > > element of the crossCertificatePair attribute, held in a
> > > particular
> > > > > CA's
> > > > > > directory entry, may contain a subset of certificates issued
> by
> > > this
> > > > > CA
> > > > > > to other CAs.  When both the forward and the reverse
> elements
> > > are
> > > > > > present, issuer name in one certificate shall match the
> subject
> > > name
> > > > > in
> > > > > > the other and vice versa, and the subject public key in one
> > > > > certificate
> > > > > > shall be capable of verifying the digital signature on the
> other
> > > > > > certificate and vice versa.
> > > > > > 
> > > > > > In the case of V3 certificates, none of the above CA
> > > certificates
> > > > > shall
> > > > > > include a basicConstraints extension with the cA value set
> to
> > > FALSE.
> > > > > > 
> > > > > > The definition of domain is purely a matter of local policy.
> > > > > > 
> > > > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > > > 
> > > > > > The cACertificate attribute, held in a particular CA's
> directory
> > > > > entry,
> > > > > > shall be used to store certificates issued to this CA by CAs
> in
> > > the
> > > > > same
> > > > > > domain as this CA.
> > > > > > 
> > > > > > The forward element of the crossCertificatePair attribute,
> held
> > > in a
> > > > > > particular CA's directory entry, shall be used to store all
> > > > > certificates
> > > > > > issued to this CA.  Optionally, the reverse element of the
> > > > > > crossCertificatePair attribute, held in a particular CA's
> > > directory
> > > > > > entry, may contain a subset of certificates issued by this
> CA to
> > > > > other
> > > > > > CAs.  When both the forward and the reverse elements are
> > > present,
> > > > > issuer
> > > > > > name in one certificate shall match the subject name in the
> > > other
> > > > > and
> > > > > > vice versa, and the subject public key in one certificate
> shall
> > > be
> > > > > > capable of verifying the digital signature on the other
> > > certificate
> > > > > and
> > > > > > vice versa.
> > > > > > 
> > > > > > In the case of V3 certificates, none of the above CA
> > > certificates
> > > > > shall
> > > > > > include a basicConstraints extension with the cA value set
> to
> > > FALSE.
> > > > > > 
> > > > > > The definition of domain is purely a matter of local policy.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > ----------
> > > > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > > > > Subject: 	RE: forward & reverse elements -
> population
> > > > > > > > 
> > > > > > > 	--stuff deleted
> > > > > > > > > 
> > > > > > > > 	[]  I agree.  I do not have problem with the
> following
> > > > > language.
> > > > > > > > " A certificate issued to a CA by another shall be
> stored
> > > either
> > > > > in
> > > > > > > the
> > > > > > > > caCertificate or forward component of
> crossCertificatePair
> > > > > attribute
> > > > > > > of
> > > > > > > > the subject CA.  Optionally, a subset of certificates
> issued
> > > by
> > > > > a CA
> > > > > > > can
> > > > > > > > be stored in the reverse component of
> crossCertificatePair
> > > > > attribute
> > > > > > > of
> > > > > > > > the issuing CA."
> > > > > > > > 
> > > > > > > > 	Please note that to me subset includes none,
> some, or
> > > > > all.  If
> > > > > > > > folks want further clarification, it is ok by me.
> > > > > > > > 
> > > > > > > Santosh, the only issue I have with this text is that (at
> > > least
> > > > > with
> > > > > > > the
> > > > > > > rationale behind option 2) any cert that appears in the
> > > > > cACertificate
> > > > > > > attribute of a given CA
> > > > > > > entry, should also appear in the crossCertificatePair
> > > attribute in
> > > > > the
> > > > > > > same
> > > > > > > CA entry.
> > > > > > >  What about deleting the reference to the cACertificate
> > > attribute
> > > > > from
> > > > > > > your
> > > > > > > text and proposing this as new text just for the
> > > > > crossCertificatePair
> > > > > > > attribute? 
> > > > > > > 
> > > > > > > Both Jan and David have indicated reasons to keep the
> "pair"
> > > > > together
> > > > > > > in the
> > > > > > > mutual case, so we should also consider adding the last
> > > paragraph
> > > > > of
> > > > > > > the
> > > > > > > text David proposed for that.  
> > > > > > > 
> > > > > > > Here's what the resulting text proposal would look like:
> > > > > > > 
> > > > > > > > " A certificate issued to a CA by another shall be
> stored in
> > > the
> > > > > > > > forward component of crossCertificatePair attribute of
> > > > > > > > the subject CA.  Optionally, a subset of certificates
> issued
> > > by
> > > > > a CA
> > > > > > > can
> > > > > > > > be stored in the reverse component of
> crossCertificatePair
> > > > > attribute
> > > > > > > of
> > > > > > > > the issuing CA. When both elements are present in the
> same
> > > > > value,
> > > > > > > the
> > > > > > > > value shall represent a mutual cross-certification of
> the
> > > two
> > > > > CAs. "
> > > > > > > > 
> > > > > > > If we can come to consensus on that attribute, then let's
> see
> > > what
> > > > > we
> > > > > > > can do
> > > > > > > with the cACertificate attribute text.
> > > > > > > 
> > > > > > > I agree with your view on what a subset is and I think
> that
> > > same
> > > > > > > definition
> > > > > > > would apply to the contents of the cACertificate attribute
> as
> > > a
> > > > > subset
> > > > > > > of
> > > > > > > the crossCertificatePair forward elements in option 2.
> > > > > > 

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:15:46 -0400
Importance: Normal
Sender: [email-masked]

> In using certificates, it is useful to know what form of 
> authentication is used by a CA to identify a new certificate 
> requester.  A certificate extension seems the best place to store 
> this information.

This sounds to me like a trip into a quagmire. I don't think that
it is possible to charaterize authentication mechanisms usefully
in a set of binary flags.

For example two CAs may be requiring presentation of a driving
license for authentication, only one CA may be using a state of
MA license with photo ID and another a UK driving license without
photo ID.

Even with documents such as passports there is considerable 
variation between countries in the strictness of their proceedures.

Then there are proceedural variations, is the applicant present
in person or were the credentials merely faxed...

Nor is the mechanism of authentication by itself particularly 
usefull unless there is an evaluation of the reliability of the
party performing it. 

Of course one can start to characterise these characteristics
as well but to do so merely throws up yet more information which
might be relevant, factors which become increasingly subjective.

This is a hard AI problem - establishing a shared vocabulary of
terms which permits exchange of concepts whose semantics are
not embedded in the communication mechanism or indeed any 
mechanism for which a formal description is available.

		Phill

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:12:22 -0700 
Sender: [email-masked]

Santosh

I seem to sense a circularity of definition.   If I interpret your comment
correctly, you place a cert in the caCertificate attribute if it belongs to
the same domain, and you can determine that it's in the same domain by
seeing if it's in the caCertificate attribute.  Exactly how I would use this
in a computer program is unclear.   Perhaps you could sketch out some
program logic one would use.

David

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 9:53 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> David:
> 
> In both options 1 and 2, a relying party can determine which issuing CAs
> are considered in the domain of the subject CA by looking at
> caCertificate attribute and the forward element of the
> crossCertificatePair attribute.
> 
> In option 1, it is straightforward.
> 
> In option 2, you have to subtract the caCertificate from the
> crossCertificatePair to get the two sets.
> 
> These two domains are from the subject CA's perspective.  It may or may
> not be in the domain of the relying party.
> 
> > -----Original Message-----
> > From:	Kurn, David [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 12:16 PM
> > To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> > Subject:	RE: forward & reverse elements - population
> > 
> > Santosh
> > 
> > Sorry to ask what must be a very naive question.  If, as you suggest,
> > the
> > "definition of a domain is purely a matter of local policy", then I
> > think
> > that the term "domain" is undefined for the purposes of a standard.
> > If so,
> > then I find it difficult to define any algorhithm (not necessarily
> > computer
> > based) or any process by which anyone could determine whether a CA is
> > in the
> > same or a different domain.
> > 
> > Think, for example, of a general purpose application program (like a
> > mail
> > client) trying to answer the question "is that CA inside or outside of
> > my
> > domain".  
> > 
> > Back in my college days, my math professors made it painfully clear
> > that if
> > you define a set, you must also provide a rule whereby you can
> > determine
> > whether a given element is inside or outside of that set.  Without
> > such a
> > rule, the set is undefined.
> > 
> > It may be that the definition of "domain" is elsewhere in the
> > document, but
> > I cannot find it.
> > 
> > David Kurn
> > Compaq Computer Corp
> > Electronic Commerce Stuff
> > 
> > > -----Original Message-----
> > > From:	Santosh Chokhani [SMTP:[email-masked]]
> > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > Yes. I agree.  The following is the revised text.
> > > 
> > > NEW PROPOSED TEXT FOR OPTION 1
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.  If there are any self-issued certificates and
> > they
> > > require publication, the caCertificate attribute shall be used to
> > store
> > > them.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store certificates
> > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > element of the crossCertificatePair attribute, held in a particular
> > CA's
> > > directory entry, may contain a subset of certificates issued by this
> > CA
> > > to other CAs.  When both the forward and the reverse elements are
> > > present, issuer name in one certificate shall match the subject name
> > in
> > > the other and vice versa, and the subject public key in one
> > certificate
> > > shall be capable of verifying the digital signature on the other
> > > certificate and vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > NEW PROPOSED TEXT FOR OPTION 2
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.  If there are any self-issued certificates and
> > they
> > > require publication, the caCertificate attribute shall be used to
> > store
> > > them.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store all
> > certificates
> > > issued to this CA.  Optionally, the reverse element of the
> > > crossCertificatePair attribute, held in a particular CA's directory
> > > entry, may contain a subset of certificates issued by this CA to
> > other
> > > CAs.  When both the forward and the reverse elements are present,
> > issuer
> > > name in one certificate shall match the subject name in the other
> > and
> > > vice versa, and the subject public key in one certificate shall be
> > > capable of verifying the digital signature on the other certificate
> > and
> > > vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > > -----Original Message-----
> > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > I agree that the texts below are consistent with the original
> > intent
> > > > of the
> > > > 2 options and I also agree that they are clearer than the original
> > > > texts
> > > > except, possibly for coverage of self issued certificates.
> > Shouldn't
> > > > we also
> > > > state explicitly that self issued certs are stored only in the
> > > > cACertificate
> > > > attribute for both options? 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > > > Subject: 	RE: forward & reverse elements - population
> > > > > 
> > > > > Sharon:
> > > > > 
> > > > > I can agree to the following text for the two option instead.
> > > > Please
> > > > > note that I have further clarified cross-certificate by tying
> > the DN
> > > > and
> > > > > public keys.
> > > > > 
> > > > > I think the following texts are consistent with and further
> > > > > clarifications of the two options.
> > > > > 
> > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > > > 
> > > > And I option 2 :-)
> > > > 
> > > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > > 
> > > > > The cACertificate attribute, held in a particular CA's directory
> > > > entry,
> > > > > shall be used to store certificates issued to this CA by CAs in
> > the
> > > > same
> > > > > domain as this CA.
> > > > > 
> > > > > The forward element of the crossCertificatePair attribute, held
> > in a
> > > > > particular CA's directory entry, shall be used to store
> > certificates
> > > > > issued to this CA by CAs in other domains.  Optionally, the
> > reverse
> > > > > element of the crossCertificatePair attribute, held in a
> > particular
> > > > CA's
> > > > > directory entry, may contain a subset of certificates issued by
> > this
> > > > CA
> > > > > to other CAs.  When both the forward and the reverse elements
> > are
> > > > > present, issuer name in one certificate shall match the subject
> > name
> > > > in
> > > > > the other and vice versa, and the subject public key in one
> > > > certificate
> > > > > shall be capable of verifying the digital signature on the other
> > > > > certificate and vice versa.
> > > > > 
> > > > > In the case of V3 certificates, none of the above CA
> > certificates
> > > > shall
> > > > > include a basicConstraints extension with the cA value set to
> > FALSE.
> > > > > 
> > > > > The definition of domain is purely a matter of local policy.
> > > > > 
> > > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > > 
> > > > > The cACertificate attribute, held in a particular CA's directory
> > > > entry,
> > > > > shall be used to store certificates issued to this CA by CAs in
> > the
> > > > same
> > > > > domain as this CA.
> > > > > 
> > > > > The forward element of the crossCertificatePair attribute, held
> > in a
> > > > > particular CA's directory entry, shall be used to store all
> > > > certificates
> > > > > issued to this CA.  Optionally, the reverse element of the
> > > > > crossCertificatePair attribute, held in a particular CA's
> > directory
> > > > > entry, may contain a subset of certificates issued by this CA to
> > > > other
> > > > > CAs.  When both the forward and the reverse elements are
> > present,
> > > > issuer
> > > > > name in one certificate shall match the subject name in the
> > other
> > > > and
> > > > > vice versa, and the subject public key in one certificate shall
> > be
> > > > > capable of verifying the digital signature on the other
> > certificate
> > > > and
> > > > > vice versa.
> > > > > 
> > > > > In the case of V3 certificates, none of the above CA
> > certificates
> > > > shall
> > > > > include a basicConstraints extension with the cA value set to
> > FALSE.
> > > > > 
> > > > > The definition of domain is purely a matter of local policy.
> > > > > 
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > ----------
> > > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > > > Subject: 	RE: forward & reverse elements - population
> > > > > > > 
> > > > > > 	--stuff deleted
> > > > > > > > 
> > > > > > > 	[]  I agree.  I do not have problem with the following
> > > > language.
> > > > > > > " A certificate issued to a CA by another shall be stored
> > either
> > > > in
> > > > > > the
> > > > > > > caCertificate or forward component of crossCertificatePair
> > > > attribute
> > > > > > of
> > > > > > > the subject CA.  Optionally, a subset of certificates issued
> > by
> > > > a CA
> > > > > > can
> > > > > > > be stored in the reverse component of crossCertificatePair
> > > > attribute
> > > > > > of
> > > > > > > the issuing CA."
> > > > > > > 
> > > > > > > 	Please note that to me subset includes none, some, or
> > > > all.  If
> > > > > > > folks want further clarification, it is ok by me.
> > > > > > > 
> > > > > > Santosh, the only issue I have with this text is that (at
> > least
> > > > with
> > > > > > the
> > > > > > rationale behind option 2) any cert that appears in the
> > > > cACertificate
> > > > > > attribute of a given CA
> > > > > > entry, should also appear in the crossCertificatePair
> > attribute in
> > > > the
> > > > > > same
> > > > > > CA entry.
> > > > > >  What about deleting the reference to the cACertificate
> > attribute
> > > > from
> > > > > > your
> > > > > > text and proposing this as new text just for the
> > > > crossCertificatePair
> > > > > > attribute? 
> > > > > > 
> > > > > > Both Jan and David have indicated reasons to keep the "pair"
> > > > together
> > > > > > in the
> > > > > > mutual case, so we should also consider adding the last
> > paragraph
> > > > of
> > > > > > the
> > > > > > text David proposed for that.  
> > > > > > 
> > > > > > Here's what the resulting text proposal would look like:
> > > > > > 
> > > > > > > " A certificate issued to a CA by another shall be stored in
> > the
> > > > > > > forward component of crossCertificatePair attribute of
> > > > > > > the subject CA.  Optionally, a subset of certificates issued
> > by
> > > > a CA
> > > > > > can
> > > > > > > be stored in the reverse component of crossCertificatePair
> > > > attribute
> > > > > > of
> > > > > > > the issuing CA. When both elements are present in the same
> > > > value,
> > > > > > the
> > > > > > > value shall represent a mutual cross-certification of the
> > two
> > > > CAs. "
> > > > > > > 
> > > > > > If we can come to consensus on that attribute, then let's see
> > what
> > > > we
> > > > > > can do
> > > > > > with the cACertificate attribute text.
> > > > > > 
> > > > > > I agree with your view on what a subset is and I think that
> > same
> > > > > > definition
> > > > > > would apply to the contents of the cACertificate attribute as
> > a
> > > > subset
> > > > > > of
> > > > > > the crossCertificatePair forward elements in option 2.
> > > > > 

From: Santosh Chokhani <[email-masked]>
To: "'Kurn, David'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:53:12 -0400
Sender: [email-masked]

David:

In both options 1 and 2, a relying party can determine which issuing CAs
are considered in the domain of the subject CA by looking at
caCertificate attribute and the forward element of the
crossCertificatePair attribute.

In option 1, it is straightforward.

In option 2, you have to subtract the caCertificate from the
crossCertificatePair to get the two sets.

These two domains are from the subject CA's perspective.  It may or may
not be in the domain of the relying party.

> -----Original Message-----
> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 12:16 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> Subject:	RE: forward & reverse elements - population
> 
> Santosh
> 
> Sorry to ask what must be a very naive question.  If, as you suggest,
> the
> "definition of a domain is purely a matter of local policy", then I
> think
> that the term "domain" is undefined for the purposes of a standard.
> If so,
> then I find it difficult to define any algorhithm (not necessarily
> computer
> based) or any process by which anyone could determine whether a CA is
> in the
> same or a different domain.
> 
> Think, for example, of a general purpose application program (like a
> mail
> client) trying to answer the question "is that CA inside or outside of
> my
> domain".  
> 
> Back in my college days, my math professors made it painfully clear
> that if
> you define a set, you must also provide a rule whereby you can
> determine
> whether a given element is inside or outside of that set.  Without
> such a
> rule, the set is undefined.
> 
> It may be that the definition of "domain" is elsewhere in the
> document, but
> I cannot find it.
> 
> David Kurn
> Compaq Computer Corp
> Electronic Commerce Stuff
> 
> > -----Original Message-----
> > From:	Santosh Chokhani [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 8:27 AM
> > To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > Subject:	RE: forward & reverse elements - population
> > 
> > Yes. I agree.  The following is the revised text.
> > 
> > NEW PROPOSED TEXT FOR OPTION 1
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.  If there are any self-issued certificates and
> they
> > require publication, the caCertificate attribute shall be used to
> store
> > them.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store certificates
> > issued to this CA by CAs in other domains.  Optionally, the reverse
> > element of the crossCertificatePair attribute, held in a particular
> CA's
> > directory entry, may contain a subset of certificates issued by this
> CA
> > to other CAs.  When both the forward and the reverse elements are
> > present, issuer name in one certificate shall match the subject name
> in
> > the other and vice versa, and the subject public key in one
> certificate
> > shall be capable of verifying the digital signature on the other
> > certificate and vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > NEW PROPOSED TEXT FOR OPTION 2
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.  If there are any self-issued certificates and
> they
> > require publication, the caCertificate attribute shall be used to
> store
> > them.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store all
> certificates
> > issued to this CA.  Optionally, the reverse element of the
> > crossCertificatePair attribute, held in a particular CA's directory
> > entry, may contain a subset of certificates issued by this CA to
> other
> > CAs.  When both the forward and the reverse elements are present,
> issuer
> > name in one certificate shall match the subject name in the other
> and
> > vice versa, and the subject public key in one certificate shall be
> > capable of verifying the digital signature on the other certificate
> and
> > vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > > -----Original Message-----
> > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > To:	[email-masked]'; 'Santosh Chokhani'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > I agree that the texts below are consistent with the original
> intent
> > > of the
> > > 2 options and I also agree that they are clearer than the original
> > > texts
> > > except, possibly for coverage of self issued certificates.
> Shouldn't
> > > we also
> > > state explicitly that self issued certs are stored only in the
> > > cACertificate
> > > attribute for both options? 
> > > 
> > > 
> > > > ----------
> > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > Sent: 	September 9, 1998 9:08 AM
> > > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > > Subject: 	RE: forward & reverse elements - population
> > > > 
> > > > Sharon:
> > > > 
> > > > I can agree to the following text for the two option instead.
> > > Please
> > > > note that I have further clarified cross-certificate by tying
> the DN
> > > and
> > > > public keys.
> > > > 
> > > > I think the following texts are consistent with and further
> > > > clarifications of the two options.
> > > > 
> > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > > 
> > > And I option 2 :-)
> > > 
> > > > NEW PROPOSED TEXT FOR OPTION 1
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store
> certificates
> > > > issued to this CA by CAs in other domains.  Optionally, the
> reverse
> > > > element of the crossCertificatePair attribute, held in a
> particular
> > > CA's
> > > > directory entry, may contain a subset of certificates issued by
> this
> > > CA
> > > > to other CAs.  When both the forward and the reverse elements
> are
> > > > present, issuer name in one certificate shall match the subject
> name
> > > in
> > > > the other and vice versa, and the subject public key in one
> > > certificate
> > > > shall be capable of verifying the digital signature on the other
> > > > certificate and vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > NEW PROPOSED TEXT FOR OPTION 2
> > > > 
> > > > The cACertificate attribute, held in a particular CA's directory
> > > entry,
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.
> > > > 
> > > > The forward element of the crossCertificatePair attribute, held
> in a
> > > > particular CA's directory entry, shall be used to store all
> > > certificates
> > > > issued to this CA.  Optionally, the reverse element of the
> > > > crossCertificatePair attribute, held in a particular CA's
> directory
> > > > entry, may contain a subset of certificates issued by this CA to
> > > other
> > > > CAs.  When both the forward and the reverse elements are
> present,
> > > issuer
> > > > name in one certificate shall match the subject name in the
> other
> > > and
> > > > vice versa, and the subject public key in one certificate shall
> be
> > > > capable of verifying the digital signature on the other
> certificate
> > > and
> > > > vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > include a basicConstraints extension with the cA value set to
> FALSE.
> > > > 
> > > > The definition of domain is purely a matter of local policy.
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > > Subject:	RE: forward & reverse elements - population
> > > > > 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > > Subject: 	RE: forward & reverse elements - population
> > > > > > 
> > > > > 	--stuff deleted
> > > > > > > 
> > > > > > 	[]  I agree.  I do not have problem with the following
> > > language.
> > > > > > " A certificate issued to a CA by another shall be stored
> either
> > > in
> > > > > the
> > > > > > caCertificate or forward component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the subject CA.  Optionally, a subset of certificates issued
> by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA."
> > > > > > 
> > > > > > 	Please note that to me subset includes none, some, or
> > > all.  If
> > > > > > folks want further clarification, it is ok by me.
> > > > > > 
> > > > > Santosh, the only issue I have with this text is that (at
> least
> > > with
> > > > > the
> > > > > rationale behind option 2) any cert that appears in the
> > > cACertificate
> > > > > attribute of a given CA
> > > > > entry, should also appear in the crossCertificatePair
> attribute in
> > > the
> > > > > same
> > > > > CA entry.
> > > > >  What about deleting the reference to the cACertificate
> attribute
> > > from
> > > > > your
> > > > > text and proposing this as new text just for the
> > > crossCertificatePair
> > > > > attribute? 
> > > > > 
> > > > > Both Jan and David have indicated reasons to keep the "pair"
> > > together
> > > > > in the
> > > > > mutual case, so we should also consider adding the last
> paragraph
> > > of
> > > > > the
> > > > > text David proposed for that.  
> > > > > 
> > > > > Here's what the resulting text proposal would look like:
> > > > > 
> > > > > > " A certificate issued to a CA by another shall be stored in
> the
> > > > > > forward component of crossCertificatePair attribute of
> > > > > > the subject CA.  Optionally, a subset of certificates issued
> by
> > > a CA
> > > > > can
> > > > > > be stored in the reverse component of crossCertificatePair
> > > attribute
> > > > > of
> > > > > > the issuing CA. When both elements are present in the same
> > > value,
> > > > > the
> > > > > > value shall represent a mutual cross-certification of the
> two
> > > CAs. "
> > > > > > 
> > > > > If we can come to consensus on that attribute, then let's see
> what
> > > we
> > > > > can do
> > > > > with the cACertificate attribute text.
> > > > > 
> > > > > I agree with your view on what a subset is and I think that
> same
> > > > > definition
> > > > > would apply to the contents of the cACertificate attribute as
> a
> > > subset
> > > > > of
> > > > > the crossCertificatePair forward elements in option 2.
> > > > 

To: [email-masked]
Subject: For Option 2
Date: Wed, 09 Sep 1998 17:38:35 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

Date: Wed, 09 Sep 1998 09:36:53 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

It seems to me that the certificate policies (section 4.2.1.5) is still the
proper place for this. If we create a set of bits that says how the CA is
authenticating, unless the statement in the new bits is *exactly* what the
CA is using, they should not commit to those bits because someone later can
say "but you said you were doing such-and-so". The CPS is under their control.

Can you be specific about the advantage of what you are proposing versus
the certificate policy?

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: [email-masked]
Date: Wed, 9 Sep 1998 12:23:30 -0400
Subject: For Option 2
Sender: [email-masked]

Alan Buffett
09/09/98 12:23 PM

From: "Kurn, David" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:15:34 -0700 
Sender: [email-masked]

Santosh

Sorry to ask what must be a very naive question.  If, as you suggest, the
"definition of a domain is purely a matter of local policy", then I think
that the term "domain" is undefined for the purposes of a standard.  If so,
then I find it difficult to define any algorhithm (not necessarily computer
based) or any process by which anyone could determine whether a CA is in the
same or a different domain.

Think, for example, of a general purpose application program (like a mail
client) trying to answer the question "is that CA inside or outside of my
domain".  

Back in my college days, my math professors made it painfully clear that if
you define a set, you must also provide a rule whereby you can determine
whether a given element is inside or outside of that set.  Without such a
rule, the set is undefined.

It may be that the definition of "domain" is elsewhere in the document, but
I cannot find it.

David Kurn
Compaq Computer Corp
Electronic Commerce Stuff

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 8:27 AM
> To:	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> Subject:	RE: forward & reverse elements - population
> 
> Yes. I agree.  The following is the revised text.
> 
> NEW PROPOSED TEXT FOR OPTION 1
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.  If there are any self-issued certificates and they
> require publication, the caCertificate attribute shall be used to store
> them.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  Optionally, the reverse
> element of the crossCertificatePair attribute, held in a particular CA's
> directory entry, may contain a subset of certificates issued by this CA
> to other CAs.  When both the forward and the reverse elements are
> present, issuer name in one certificate shall match the subject name in
> the other and vice versa, and the subject public key in one certificate
> shall be capable of verifying the digital signature on the other
> certificate and vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> NEW PROPOSED TEXT FOR OPTION 2
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.  If there are any self-issued certificates and they
> require publication, the caCertificate attribute shall be used to store
> them.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store all certificates
> issued to this CA.  Optionally, the reverse element of the
> crossCertificatePair attribute, held in a particular CA's directory
> entry, may contain a subset of certificates issued by this CA to other
> CAs.  When both the forward and the reverse elements are present, issuer
> name in one certificate shall match the subject name in the other and
> vice versa, and the subject public key in one certificate shall be
> capable of verifying the digital signature on the other certificate and
> vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> > -----Original Message-----
> > From:	Sharon Boeyen [SMTP:[email-masked]]
> > Sent:	Wednesday, September 09, 1998 11:02 AM
> > To:	[email-masked]'; 'Santosh Chokhani'
> > Subject:	RE: forward & reverse elements - population
> > 
> > I agree that the texts below are consistent with the original intent
> > of the
> > 2 options and I also agree that they are clearer than the original
> > texts
> > except, possibly for coverage of self issued certificates. Shouldn't
> > we also
> > state explicitly that self issued certs are stored only in the
> > cACertificate
> > attribute for both options? 
> > 
> > 
> > > ----------
> > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > Sent: 	September 9, 1998 9:08 AM
> > > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > > Subject: 	RE: forward & reverse elements - population
> > > 
> > > Sharon:
> > > 
> > > I can agree to the following text for the two option instead.
> > Please
> > > note that I have further clarified cross-certificate by tying the DN
> > and
> > > public keys.
> > > 
> > > I think the following texts are consistent with and further
> > > clarifications of the two options.
> > > 
> > > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > > 
> > And I option 2 :-)
> > 
> > > NEW PROPOSED TEXT FOR OPTION 1
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store certificates
> > > issued to this CA by CAs in other domains.  Optionally, the reverse
> > > element of the crossCertificatePair attribute, held in a particular
> > CA's
> > > directory entry, may contain a subset of certificates issued by this
> > CA
> > > to other CAs.  When both the forward and the reverse elements are
> > > present, issuer name in one certificate shall match the subject name
> > in
> > > the other and vice versa, and the subject public key in one
> > certificate
> > > shall be capable of verifying the digital signature on the other
> > > certificate and vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > NEW PROPOSED TEXT FOR OPTION 2
> > > 
> > > The cACertificate attribute, held in a particular CA's directory
> > entry,
> > > shall be used to store certificates issued to this CA by CAs in the
> > same
> > > domain as this CA.
> > > 
> > > The forward element of the crossCertificatePair attribute, held in a
> > > particular CA's directory entry, shall be used to store all
> > certificates
> > > issued to this CA.  Optionally, the reverse element of the
> > > crossCertificatePair attribute, held in a particular CA's directory
> > > entry, may contain a subset of certificates issued by this CA to
> > other
> > > CAs.  When both the forward and the reverse elements are present,
> > issuer
> > > name in one certificate shall match the subject name in the other
> > and
> > > vice versa, and the subject public key in one certificate shall be
> > > capable of verifying the digital signature on the other certificate
> > and
> > > vice versa.
> > > 
> > > In the case of V3 certificates, none of the above CA certificates
> > shall
> > > include a basicConstraints extension with the cA value set to FALSE.
> > > 
> > > The definition of domain is purely a matter of local policy.
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > To:	[email-masked]'; 'Santosh Chokhani'
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > > Subject: 	RE: forward & reverse elements - population
> > > > > 
> > > > 	--stuff deleted
> > > > > > 
> > > > > 	[]  I agree.  I do not have problem with the following
> > language.
> > > > > " A certificate issued to a CA by another shall be stored either
> > in
> > > > the
> > > > > caCertificate or forward component of crossCertificatePair
> > attribute
> > > > of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA."
> > > > > 
> > > > > 	Please note that to me subset includes none, some, or
> > all.  If
> > > > > folks want further clarification, it is ok by me.
> > > > > 
> > > > Santosh, the only issue I have with this text is that (at least
> > with
> > > > the
> > > > rationale behind option 2) any cert that appears in the
> > cACertificate
> > > > attribute of a given CA
> > > > entry, should also appear in the crossCertificatePair attribute in
> > the
> > > > same
> > > > CA entry.
> > > >  What about deleting the reference to the cACertificate attribute
> > from
> > > > your
> > > > text and proposing this as new text just for the
> > crossCertificatePair
> > > > attribute? 
> > > > 
> > > > Both Jan and David have indicated reasons to keep the "pair"
> > together
> > > > in the
> > > > mutual case, so we should also consider adding the last paragraph
> > of
> > > > the
> > > > text David proposed for that.  
> > > > 
> > > > Here's what the resulting text proposal would look like:
> > > > 
> > > > > " A certificate issued to a CA by another shall be stored in the
> > > > > forward component of crossCertificatePair attribute of
> > > > > the subject CA.  Optionally, a subset of certificates issued by
> > a CA
> > > > can
> > > > > be stored in the reverse component of crossCertificatePair
> > attribute
> > > > of
> > > > > the issuing CA. When both elements are present in the same
> > value,
> > > > the
> > > > > value shall represent a mutual cross-certification of the two
> > CAs. "
> > > > > 
> > > > If we can come to consensus on that attribute, then let's see what
> > we
> > > > can do
> > > > with the cACertificate attribute text.
> > > > 
> > > > I agree with your view on what a subset is and I think that same
> > > > definition
> > > > would apply to the contents of the cACertificate attribute as a
> > subset
> > > > of
> > > > the crossCertificatePair forward elements in option 2.
> > > 

Date: Wed, 09 Sep 1998 10:03:36 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: New Extension Proposed: Method Of Authentication
Sender: [email-masked]

In using certificates, it is useful to know what form of authentication is used by a CA to identify a new certificate requester.  A certificate extension seems the best place to store this information.

At one time, Bob Jeuneman prepared a paper proposing this extension and detailing many categories, from anonymous, self-authenticated, self authenticated with data verifired (or with credit account, etc.), authenticated in person, in person with governement-issued picture ID, multiple forms of government picture IDs with current credit reports and corporate D&B, etc.

The current practice, I beleive, is to embed the authentication mechanism in a CA operations or policy statement tha may or may not be online for someone to peruse and make their own judgement.  Putting a clear indicator in the signed cert would help.

Comments?  Bob?

Michael

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:05:30 -0400
Sender: [email-masked]

Denis:

I agree with you.  Clarification of the text is easy.  However, I have a
question.  Must a certificate issued to a CA appear in the forward
element, caCertificate or can it be missing altogether?

I think the text in terms of saying that the forward element need not be
present in all cases is easy.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 8:44 PM
> To:	Santosh Chokhani
> Cc:	'Sharon Boeyen'; [email-masked]'
> Subject:	Re: forward & reverse elements - population
> 
> Santosh,
> 
> Your new proposed text does not address my concern correctly.
> 
> For a crossCertificatePair Attribute, either the forward element only
> MAY be present, or the reverse element only MAY be present, or the
> reverse and the forward elements may be both present.
>  
> Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward
> element
> shall not be mandated to be present in a crossCertificatePair
> Attribute.
> 
> Denis 
> 
> > Sharon:
> 
> > I can agree to the following text for the two option instead.
> Please
> > note that I have further clarified cross-certificate by tying the DN
> and
> > public keys.
> > 
> > I think the following texts are consistent with and further
> > clarifications of the two options.
> > 
> > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > 
> > NEW PROPOSED TEXT FOR OPTION 1
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store certificates
> > issued to this CA by CAs in other domains.  Optionally, the reverse
> > element of the crossCertificatePair attribute, held in a particular
> CA's
> > directory entry, may contain a subset of certificates issued by this
> CA
> > to other CAs.  When both the forward and the reverse elements are
> > present, issuer name in one certificate shall match the subject name
> in
> > the other and vice versa, and the subject public key in one
> certificate
> > shall be capable of verifying the digital signature on the other
> > certificate and vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > NEW PROPOSED TEXT FOR OPTION 2
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store all
> certificates
> > issued to this CA.  Optionally, the reverse element of the
> > crossCertificatePair attribute, held in a particular CA's directory
> > entry, may contain a subset of certificates issued by this CA to
> other
> > CAs.  When both the forward and the reverse elements are present,
> issuer
> > name in one certificate shall match the subject name in the other
> and
> > vice versa, and the subject public key in one certificate shall be
> > capable of verifying the digital signature on the other certificate
> and
> > vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > > -----Original Message-----
> > > From: Sharon Boeyen [SMTP:[email-masked]]
> > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > To:   [email-masked]'; 'Santosh Chokhani'
> > > Subject:      RE: forward & reverse elements - population
> > >
> > >
> > >
> > > > ----------
> > > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > > Sent:       September 8, 1998 10:05 AM
> > > > To:         'Sharon Boeyen'; [email-masked]'
> > > > Subject:    RE: forward & reverse elements - population
> > > >
> > >       --stuff deleted
> > > > >
> > > >     []  I agree.  I do not have problem with the following
> language.
> > > > " A certificate issued to a CA by another shall be stored either
> in
> > > the
> > > > caCertificate or forward component of crossCertificatePair
> attribute
> > > of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA."
> > > >
> > > >     Please note that to me subset includes none, some, or all.
> If
> > > > folks want further clarification, it is ok by me.
> > > >
> > > Santosh, the only issue I have with this text is that (at least
> with
> > > the
> > > rationale behind option 2) any cert that appears in the
> cACertificate
> > > attribute of a given CA
> > > entry, should also appear in the crossCertificatePair attribute in
> the
> > > same
> > > CA entry.
> > >  What about deleting the reference to the cACertificate attribute
> from
> > > your
> > > text and proposing this as new text just for the
> crossCertificatePair
> > > attribute?
> > >
> > > Both Jan and David have indicated reasons to keep the "pair"
> together
> > > in the
> > > mutual case, so we should also consider adding the last paragraph
> of
> > > the
> > > text David proposed for that.
> > >
> > > Here's what the resulting text proposal would look like:
> > >
> > > > " A certificate issued to a CA by another shall be stored in the
> > > > forward component of crossCertificatePair attribute of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA. When both elements are present in the same
> value,
> > > the
> > > > value shall represent a mutual cross-certification of the two
> CAs. "
> > > >
> > > If we can come to consensus on that attribute, then let's see what
> we
> > > can do
> > > with the cACertificate attribute text.
> > >
> > > I agree with your view on what a subset is and I think that same
> > > definition
> > > would apply to the contents of the cACertificate attribute as a
> subset
> > > of
> > > the crossCertificatePair forward elements in option 2.
> 
> -- 
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: [email-masked]
To: [email-masked]
Date: Wed, 9 Sep 1998 11:46:08 -0400
Subject: For Option 2
Sender: [email-masked]

09/09/98 11:46 AM
Ross Smith
Ross Smith
Ross Smith
09/09/98 11:46 AM
09/09/98 11:46 AM

Date: Wed, 09 Sep 1998 17:44:12 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Santosh Chokhani <[email-masked]>
CC: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: forward & reverse elements - population
Sender: [email-masked]

Santosh,

Your new proposed text does not address my concern correctly.

For a crossCertificatePair Attribute, either the forward element only
MAY be present, or the reverse element only MAY be present, or the
reverse and the forward elements may be both present.
 
Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward element
shall not be mandated to be present in a crossCertificatePair Attribute.

Denis 

> Sharon:

> I can agree to the following text for the two option instead.  Please
> note that I have further clarified cross-certificate by tying the DN and
> public keys.
> 
> I think the following texts are consistent with and further
> clarifications of the two options.
> 
> I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> 
> NEW PROPOSED TEXT FOR OPTION 1
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  Optionally, the reverse
> element of the crossCertificatePair attribute, held in a particular CA's
> directory entry, may contain a subset of certificates issued by this CA
> to other CAs.  When both the forward and the reverse elements are
> present, issuer name in one certificate shall match the subject name in
> the other and vice versa, and the subject public key in one certificate
> shall be capable of verifying the digital signature on the other
> certificate and vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> NEW PROPOSED TEXT FOR OPTION 2
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store all certificates
> issued to this CA.  Optionally, the reverse element of the
> crossCertificatePair attribute, held in a particular CA's directory
> entry, may contain a subset of certificates issued by this CA to other
> CAs.  When both the forward and the reverse elements are present, issuer
> name in one certificate shall match the subject name in the other and
> vice versa, and the subject public key in one certificate shall be
> capable of verifying the digital signature on the other certificate and
> vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> > -----Original Message-----
> > From: Sharon Boeyen [SMTP:[email-masked]]
> > Sent: Tuesday, September 08, 1998 5:46 PM
> > To:   [email-masked]'; 'Santosh Chokhani'
> > Subject:      RE: forward & reverse elements - population
> >
> >
> >
> > > ----------
> > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > Sent:       September 8, 1998 10:05 AM
> > > To:         'Sharon Boeyen'; [email-masked]'
> > > Subject:    RE: forward & reverse elements - population
> > >
> >       --stuff deleted
> > > >
> > >     []  I agree.  I do not have problem with the following language.
> > > " A certificate issued to a CA by another shall be stored either in
> > the
> > > caCertificate or forward component of crossCertificatePair attribute
> > of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA."
> > >
> > >     Please note that to me subset includes none, some, or all.  If
> > > folks want further clarification, it is ok by me.
> > >
> > Santosh, the only issue I have with this text is that (at least with
> > the
> > rationale behind option 2) any cert that appears in the cACertificate
> > attribute of a given CA
> > entry, should also appear in the crossCertificatePair attribute in the
> > same
> > CA entry.
> >  What about deleting the reference to the cACertificate attribute from
> > your
> > text and proposing this as new text just for the crossCertificatePair
> > attribute?
> >
> > Both Jan and David have indicated reasons to keep the "pair" together
> > in the
> > mutual case, so we should also consider adding the last paragraph of
> > the
> > text David proposed for that.
> >
> > Here's what the resulting text proposal would look like:
> >
> > > " A certificate issued to a CA by another shall be stored in the
> > > forward component of crossCertificatePair attribute of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA. When both elements are present in the same value,
> > the
> > > value shall represent a mutual cross-certification of the two CAs. "
> > >
> > If we can come to consensus on that attribute, then let's see what we
> > can do
> > with the cACertificate attribute text.
> >
> > I agree with your view on what a subset is and I think that same
> > definition
> > would apply to the contents of the cACertificate attribute as a subset
> > of
> > the crossCertificatePair forward elements in option 2.

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:26:42 -0400
Sender: [email-masked]

Yes. I agree.  The following is the revised text.

NEW PROPOSED TEXT FOR OPTION 1

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.  If there are any self-issued certificates and they
require publication, the caCertificate attribute shall be used to store
them.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates
issued to this CA by CAs in other domains.  Optionally, the reverse
element of the crossCertificatePair attribute, held in a particular CA's
directory entry, may contain a subset of certificates issued by this CA
to other CAs.  When both the forward and the reverse elements are
present, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

NEW PROPOSED TEXT FOR OPTION 2

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.  If there are any self-issued certificates and they
require publication, the caCertificate attribute shall be used to store
them.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store all certificates
issued to this CA.  Optionally, the reverse element of the
crossCertificatePair attribute, held in a particular CA's directory
entry, may contain a subset of certificates issued by this CA to other
CAs.  When both the forward and the reverse elements are present, issuer
name in one certificate shall match the subject name in the other and
vice versa, and the subject public key in one certificate shall be
capable of verifying the digital signature on the other certificate and
vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 11:02 AM
> To:	[email-masked]'; 'Santosh Chokhani'
> Subject:	RE: forward & reverse elements - population
> 
> I agree that the texts below are consistent with the original intent
> of the
> 2 options and I also agree that they are clearer than the original
> texts
> except, possibly for coverage of self issued certificates. Shouldn't
> we also
> state explicitly that self issued certs are stored only in the
> cACertificate
> attribute for both options? 
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > Sent: 	September 9, 1998 9:08 AM
> > To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> > Subject: 	RE: forward & reverse elements - population
> > 
> > Sharon:
> > 
> > I can agree to the following text for the two option instead.
> Please
> > note that I have further clarified cross-certificate by tying the DN
> and
> > public keys.
> > 
> > I think the following texts are consistent with and further
> > clarifications of the two options.
> > 
> > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > 
> And I option 2 :-)
> 
> > NEW PROPOSED TEXT FOR OPTION 1
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store certificates
> > issued to this CA by CAs in other domains.  Optionally, the reverse
> > element of the crossCertificatePair attribute, held in a particular
> CA's
> > directory entry, may contain a subset of certificates issued by this
> CA
> > to other CAs.  When both the forward and the reverse elements are
> > present, issuer name in one certificate shall match the subject name
> in
> > the other and vice versa, and the subject public key in one
> certificate
> > shall be capable of verifying the digital signature on the other
> > certificate and vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > NEW PROPOSED TEXT FOR OPTION 2
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store all
> certificates
> > issued to this CA.  Optionally, the reverse element of the
> > crossCertificatePair attribute, held in a particular CA's directory
> > entry, may contain a subset of certificates issued by this CA to
> other
> > CAs.  When both the forward and the reverse elements are present,
> issuer
> > name in one certificate shall match the subject name in the other
> and
> > vice versa, and the subject public key in one certificate shall be
> > capable of verifying the digital signature on the other certificate
> and
> > vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From:	Sharon Boeyen [SMTP:[email-masked]]
> > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > To:	[email-masked]'; 'Santosh Chokhani'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > 
> > > 
> > > > ----------
> > > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > > Sent: 	September 8, 1998 10:05 AM
> > > > To: 	'Sharon Boeyen'; [email-masked]'
> > > > Subject: 	RE: forward & reverse elements - population
> > > > 
> > > 	--stuff deleted
> > > > > 
> > > > 	[]  I agree.  I do not have problem with the following
> language.
> > > > " A certificate issued to a CA by another shall be stored either
> in
> > > the
> > > > caCertificate or forward component of crossCertificatePair
> attribute
> > > of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA."
> > > > 
> > > > 	Please note that to me subset includes none, some, or
> all.  If
> > > > folks want further clarification, it is ok by me.
> > > > 
> > > Santosh, the only issue I have with this text is that (at least
> with
> > > the
> > > rationale behind option 2) any cert that appears in the
> cACertificate
> > > attribute of a given CA
> > > entry, should also appear in the crossCertificatePair attribute in
> the
> > > same
> > > CA entry.
> > >  What about deleting the reference to the cACertificate attribute
> from
> > > your
> > > text and proposing this as new text just for the
> crossCertificatePair
> > > attribute? 
> > > 
> > > Both Jan and David have indicated reasons to keep the "pair"
> together
> > > in the
> > > mutual case, so we should also consider adding the last paragraph
> of
> > > the
> > > text David proposed for that.  
> > > 
> > > Here's what the resulting text proposal would look like:
> > > 
> > > > " A certificate issued to a CA by another shall be stored in the
> > > > forward component of crossCertificatePair attribute of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA. When both elements are present in the same
> value,
> > > the
> > > > value shall represent a mutual cross-certification of the two
> CAs. "
> > > > 
> > > If we can come to consensus on that attribute, then let's see what
> we
> > > can do
> > > with the cACertificate attribute text.
> > > 
> > > I agree with your view on what a subset is and I think that same
> > > definition
> > > would apply to the contents of the cACertificate attribute as a
> subset
> > > of
> > > the crossCertificatePair forward elements in option 2.
> > 

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:01:32 -0400 
Sender: [email-masked]

I agree that the texts below are consistent with the original intent of the
2 options and I also agree that they are clearer than the original texts
except, possibly for coverage of self issued certificates. Shouldn't we also
state explicitly that self issued certs are stored only in the cACertificate
attribute for both options? 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 9, 1998 9:08 AM
> To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> Subject: 	RE: forward & reverse elements - population
> 
> Sharon:
> 
> I can agree to the following text for the two option instead.  Please
> note that I have further clarified cross-certificate by tying the DN and
> public keys.
> 
> I think the following texts are consistent with and further
> clarifications of the two options.
> 
> I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> 
And I option 2 :-)

> NEW PROPOSED TEXT FOR OPTION 1
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  Optionally, the reverse
> element of the crossCertificatePair attribute, held in a particular CA's
> directory entry, may contain a subset of certificates issued by this CA
> to other CAs.  When both the forward and the reverse elements are
> present, issuer name in one certificate shall match the subject name in
> the other and vice versa, and the subject public key in one certificate
> shall be capable of verifying the digital signature on the other
> certificate and vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> NEW PROPOSED TEXT FOR OPTION 2
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store all certificates
> issued to this CA.  Optionally, the reverse element of the
> crossCertificatePair attribute, held in a particular CA's directory
> entry, may contain a subset of certificates issued by this CA to other
> CAs.  When both the forward and the reverse elements are present, issuer
> name in one certificate shall match the subject name in the other and
> vice versa, and the subject public key in one certificate shall be
> capable of verifying the digital signature on the other certificate and
> vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> 
> 
> > -----Original Message-----
> > From:	Sharon Boeyen [SMTP:[email-masked]]
> > Sent:	Tuesday, September 08, 1998 5:46 PM
> > To:	[email-masked]'; 'Santosh Chokhani'
> > Subject:	RE: forward & reverse elements - population
> > 
> > 
> > 
> > > ----------
> > > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > > Sent: 	September 8, 1998 10:05 AM
> > > To: 	'Sharon Boeyen'; [email-masked]'
> > > Subject: 	RE: forward & reverse elements - population
> > > 
> > 	--stuff deleted
> > > > 
> > > 	[]  I agree.  I do not have problem with the following language.
> > > " A certificate issued to a CA by another shall be stored either in
> > the
> > > caCertificate or forward component of crossCertificatePair attribute
> > of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA."
> > > 
> > > 	Please note that to me subset includes none, some, or all.  If
> > > folks want further clarification, it is ok by me.
> > > 
> > Santosh, the only issue I have with this text is that (at least with
> > the
> > rationale behind option 2) any cert that appears in the cACertificate
> > attribute of a given CA
> > entry, should also appear in the crossCertificatePair attribute in the
> > same
> > CA entry.
> >  What about deleting the reference to the cACertificate attribute from
> > your
> > text and proposing this as new text just for the crossCertificatePair
> > attribute? 
> > 
> > Both Jan and David have indicated reasons to keep the "pair" together
> > in the
> > mutual case, so we should also consider adding the last paragraph of
> > the
> > text David proposed for that.  
> > 
> > Here's what the resulting text proposal would look like:
> > 
> > > " A certificate issued to a CA by another shall be stored in the
> > > forward component of crossCertificatePair attribute of
> > > the subject CA.  Optionally, a subset of certificates issued by a CA
> > can
> > > be stored in the reverse component of crossCertificatePair attribute
> > of
> > > the issuing CA. When both elements are present in the same value,
> > the
> > > value shall represent a mutual cross-certification of the two CAs. "
> > > 
> > If we can come to consensus on that attribute, then let's see what we
> > can do
> > with the cACertificate attribute text.
> > 
> > I agree with your view on what a subset is and I think that same
> > definition
> > would apply to the contents of the cACertificate attribute as a subset
> > of
> > the crossCertificatePair forward elements in option 2.
> 

Date: Wed, 09 Sep 1998 15:40:49 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: For Option none
Sender: [email-masked]

The straw poll is now obsolete since neither of the two original texts
is acceptable as it is. Anyway since it was not a "vote", it was
interresting to promote discussion on this topic and apparently that
discussion has not yet ended !

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:08:23 -0400
Sender: [email-masked]

Sharon:

I can agree to the following text for the two option instead.  Please
note that I have further clarified cross-certificate by tying the DN and
public keys.

I think the following texts are consistent with and further
clarifications of the two options.

I STILL AM STRONGLY IN FAVOR OF OPTION 1.

NEW PROPOSED TEXT FOR OPTION 1

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates
issued to this CA by CAs in other domains.  Optionally, the reverse
element of the crossCertificatePair attribute, held in a particular CA's
directory entry, may contain a subset of certificates issued by this CA
to other CAs.  When both the forward and the reverse elements are
present, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

NEW PROPOSED TEXT FOR OPTION 2

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store all certificates
issued to this CA.  Optionally, the reverse element of the
crossCertificatePair attribute, held in a particular CA's directory
entry, may contain a subset of certificates issued by this CA to other
CAs.  When both the forward and the reverse elements are present, issuer
name in one certificate shall match the subject name in the other and
vice versa, and the subject public key in one certificate shall be
capable of verifying the digital signature on the other certificate and
vice versa.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Tuesday, September 08, 1998 5:46 PM
> To:	[email-masked]'; 'Santosh Chokhani'
> Subject:	RE: forward & reverse elements - population
> 
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > Sent: 	September 8, 1998 10:05 AM
> > To: 	'Sharon Boeyen'; [email-masked]'
> > Subject: 	RE: forward & reverse elements - population
> > 
> 	--stuff deleted
> > > 
> > 	[]  I agree.  I do not have problem with the following language.
> > " A certificate issued to a CA by another shall be stored either in
> the
> > caCertificate or forward component of crossCertificatePair attribute
> of
> > the subject CA.  Optionally, a subset of certificates issued by a CA
> can
> > be stored in the reverse component of crossCertificatePair attribute
> of
> > the issuing CA."
> > 
> > 	Please note that to me subset includes none, some, or all.  If
> > folks want further clarification, it is ok by me.
> > 
> Santosh, the only issue I have with this text is that (at least with
> the
> rationale behind option 2) any cert that appears in the cACertificate
> attribute of a given CA
> entry, should also appear in the crossCertificatePair attribute in the
> same
> CA entry.
>  What about deleting the reference to the cACertificate attribute from
> your
> text and proposing this as new text just for the crossCertificatePair
> attribute? 
> 
> Both Jan and David have indicated reasons to keep the "pair" together
> in the
> mutual case, so we should also consider adding the last paragraph of
> the
> text David proposed for that.  
> 
> Here's what the resulting text proposal would look like:
> 
> > " A certificate issued to a CA by another shall be stored in the
> > forward component of crossCertificatePair attribute of
> > the subject CA.  Optionally, a subset of certificates issued by a CA
> can
> > be stored in the reverse component of crossCertificatePair attribute
> of
> > the issuing CA. When both elements are present in the same value,
> the
> > value shall represent a mutual cross-certification of the two CAs. "
> > 
> If we can come to consensus on that attribute, then let's see what we
> can do
> with the cACertificate attribute text.
> 
> I agree with your view on what a subset is and I think that same
> definition
> would apply to the contents of the cACertificate attribute as a subset
> of
> the crossCertificatePair forward elements in option 2.

From: Alan Lloyd <[email-masked]>
To: "'Mike Smith '" <[email-masked]>, "[email-masked] '" <[email-masked]>, Alan Lloyd <[email-masked]>, "'Phillip M Hallam-Baker '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OFF TOPIC ???? RE: Relational vs Directory Repository Models  (was RE: pathdevelopment complexity s)
Date: Wed, 9 Sep 1998 19:22:02 +1000
Sender: [email-masked]

Thanks for the reply - comments in line. 

----------
From: Phillip M Hallam-Baker
To: Mike Smith; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 9/9/98 1:50:46 AM
Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models
(was RE: pathdevelopment complexity s)

Ph: I'm having a lot of trouble following this discussion. It appears to
have begun a discussion of the relative merits of X.500 vs LDAP server
models.
This does not appear to be something which is relevant to PKIX.
LDAP is merely a protocol. It does not define a product. Arguments based
on the 'scalability' of a client-server protocol are almost without
exception irrelevant since scaling depends on server-server
communication. The idea that the same protocol should serve both
purposes is questionable at best.

alan: LDAP is just a protocol! That statement is curious given that
features in protocol impact the system services that are conveyed to
and available from " the protocol". eg. Replicated/Master certfificates
.. How does LDAP get the Master copy of a certficate when it needs that.
If the certficate happens to be outside the "domain of interest" how
does LDAP control the extent of a search re Chaining.. It can not. If
one is trying to build large scale certficate based systems supported by
directory services, then "the protocol" used will affect the trust and
performance of the system services applied.. LDAP does not deal with
distributed systems - it deals with client interfaces to seperate
servers. Cert Matching Rules and LDAP (non X.500)servers? - ask the
vendors.

Ph:I fail to see how improved search capabilities will greatly assist
for the purposes of PKIX unless the directories have the ability to
break open, readand understand attributes embedded in certificates. If
people believe that support for a specific (and specified) search
mechanism would lead to an improvement in efficiency that is important
to PKIX let us discuss thatspecific extension.

alan: See X.500/9 certficate matching rules, see the draft I posted last
week. Cert and CRL matching rules can, in fact are intended to assist
the management and validation of certificates. They should be applied to
this end. As said in my draft, it seems pointless trying to get a client
to understand all the information and revocation designs of any CA that
might exist on this planet.
X.509 is part of X.500 and the application of X.509 to be scaleable
depends on the use and features of a directory services. The emphasis to
date on CA design has been.. information objects for CA functions that
"may" use a directory.
OCSP is symptomatic of this approach ie. no directory service is
considered. This = special client software and special servers and
special CA databases. Hardly an approach for the large scale of the
internet, the use of distributed, scaleable EC services and simple
clients.

To build a generalised, efficient, scaleable certificate infrastructure,
X.500 directory systems (not LDAP servers) are fundamental. With added
matching rules and common CA information doctrines (as applied to their
DIBs) the PKIX problem is very solveable.

Ph: We need to remember that we are charterted as an IETF working group
and weare not in a position to endorse a particular directory strategy.

alan: Well if "we" are chartered to build a car and it wants to be used,
by definition should we not be making sure that the roads and wheels are
in place. (eg directory systems). ie. when anything is designed,
assumptions or statements about underlying (scaleable) services should
be made.

Ph: If we want to be able to offload client work to a server of some
kind we should first consider the requirements that motivate such an
architectural approach and the trust implications of doing so before
considering protocol extensions. Indeed a critical step would be
deciding which protocol to base an implementation on.

Alan: X.500 was designed to deal with this issue (see X.500 1993 cert
and CRL matching rules).
There is no direct extension to the protocol" its the addition of convey
service requirements and modified directory matching rule support.

As for trust - then there is no trust in multitudes of chaotic CA
information designs and complex clients that cannot verify certs for
specific application and originator/recipient contexts.

Finally - it seems a lot of the work on PKIX has been made so complex
because of the limitations in LDAP, LDAP servers and "non directory
system" application, eg OCSP, eg, . Taking X.500 infrastructure away
from X.509 is like taking the wheels off a car and then trying to fix
the car's resulting problems.

So IMHO - if the charter of this group is to build a certficate
infrastructure for the internet - should we not follow industry trends
with directories ie LDAP or DAP access to X.500 that incorporates X.509?

And extend this as per dir-cert-stat draft to make it scaleable and
efficient.

Thoughts are welcome.

regards alan

		Phill

Date: Tue, 08 Sep 1998 22:17:20 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Ed Posnak <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: OCSP in Chicago
Sender: [email-masked]

Hi Ed,
    Please take a look at section 4.4.4 (Archive Cutoff). See if
that addresses your concerns.

4.4.4 Archive Cutoff

An OCSP responder MAY choose to retain revocation information beyond a 
certificate’s expiration. The date obtained by subtracting this 
retention interval value from the producedAt time in a response is 
defined as the certificate’s “archive cutoff” date.

OCSP-enabled applications would use an OCSP archive cutoff date to 
contribute to a proof that a digital signature was (or was not) reliable 
on the date it was produced even if the certificate needed to validate 
the signature has long since expired.

OCSP servers that provide support for such historical reference SHOULD 
include an archive cutoff date extension in responses.  If included, 
this value SHALL be provided as an OCSP singleResponse extension  
identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime:

id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

archiveCutoff ::= GeneralizedTime

To illustrate, if a server is operated with a 7-year retention interval 
policy and status was produced at time t1 then the value for 
archiveCutoff in the response would be (t1 - 7 years).

Regards,
Ambarish

Ed Posnak wrote:
> 
> Does the following still apply to a "Good" status?
> 
> [from version 05] "... it is quite possible that an OCSP responder
> returns the notRevoked state if a certificate was revoked, but has since
> expired (equivalent to a serial number being dropped from the CRL). "
> 
> If so, perhaps the above sentence shouldn't have been dropped from the
> description?
> 
> ejp

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

Date: Tue, 08 Sep 1998 23:44:10 -0400
To: Pavel Krylov <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: depth
Cc: [email-masked]
Sender: [email-masked]

In researching this for IPSec, I've heard a depth of approximately four being used, and of course a single root, and sporadic use of deeper trees, as far as 8.

At 12:35 AM 9/8/98 +0400, you wrote:
>
>My question:
>        What depth of certificate tree is exist now?? Average value?
>
>Sharon, Santosh? 
>
>---------------------------------------
>Pavel V.Krylov          [email-masked]
> 

Date: Tue, 08 Sep 1998 18:27:51 -0700
From: Ed Posnak <[email-masked]>
Organization: Xetex Corporation
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: OCSP in Chicago
Sender: [email-masked]

Does the following still apply to a "Good" status?

[from version 05] "... it is quite possible that an OCSP responder
returns the notRevoked state if a certificate was revoked, but has since
expired (equivalent to a serial number being dropped from the CRL). "

If so, perhaps the above sentence shouldn't have been dropped from the
description?

ejp

Date: Tue, 08 Sep 1998 18:07:20 -0400
To: "[email-masked]'" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 08 Sep 1998 15:02:30 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: OCSP in Chicago
Sender: [email-masked]

Hi All,

For the benefit of those who were not in Chicago, it was resolved
that the symbol for notRevoked be changed to good. We have put
in the following explanation of the good state:

The "good" state indicates a positive response to the status inquiry. 
At a minimum, this positive response indicates that the certificate is
not revoked, but does not necessarily mean that the certificate was ever
issued or that the producedAt time is within the certificate's validity
interval. Response extensions may be used to convey additional
information on assertions made by the responder regarding the status of
the certificate such as positive statement about issuance, validity,
etc.).

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: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 17:46:01 -0400 
Sender: [email-masked]

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 8, 1998 10:05 AM
> To: 	'Sharon Boeyen'; [email-masked]'
> Subject: 	RE: forward & reverse elements - population
> 
	--stuff deleted
> > 
> 	[]  I agree.  I do not have problem with the following language.
> " A certificate issued to a CA by another shall be stored either in the
> caCertificate or forward component of crossCertificatePair attribute of
> the subject CA.  Optionally, a subset of certificates issued by a CA can
> be stored in the reverse component of crossCertificatePair attribute of
> the issuing CA."
> 
> 	Please note that to me subset includes none, some, or all.  If
> folks want further clarification, it is ok by me.
> 
Santosh, the only issue I have with this text is that (at least with the
rationale behind option 2) any cert that appears in the cACertificate
attribute of a given CA
entry, should also appear in the crossCertificatePair attribute in the same
CA entry.
 What about deleting the reference to the cACertificate attribute from your
text and proposing this as new text just for the crossCertificatePair
attribute? 

Both Jan and David have indicated reasons to keep the "pair" together in the
mutual case, so we should also consider adding the last paragraph of the
text David proposed for that.  

Here's what the resulting text proposal would look like:

> " A certificate issued to a CA by another shall be stored in the
> forward component of crossCertificatePair attribute of
> the subject CA.  Optionally, a subset of certificates issued by a CA can
> be stored in the reverse component of crossCertificatePair attribute of
> the issuing CA. When both elements are present in the same value, the
> value shall represent a mutual cross-certification of the two CAs. "
> 
If we can come to consensus on that attribute, then let's see what we can do
with the cACertificate attribute text.

I agree with your view on what a subset is and I think that same definition
would apply to the contents of the cACertificate attribute as a subset of
the crossCertificatePair forward elements in option 2.

From: "Fuerst, Neal" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FOR Option 2
Date: Tue, 8 Sep 1998 11:05:12 -0500 
Sender: [email-masked]

Thanks.

Neal Fuerst
Information Security Analyst
Compaq Computer Corporation
E-Mail: [email-masked]
Phone: 281.518.8072
Pager: 713.509.4586

Entrust validation string: OMCO-KGMF-KQZN
"No matter how paranoid you are, you're not paranoid enough."

From: "PACHL, Jan" <[email-masked]>
To: "'David Boyce'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population 
Date: Tue, 8 Sep 1998 12:37:04 -0700
Sender: [email-masked]

in response to:
>From: 	David Boyce[SMTP:[email-masked]]
>"PACHL, Jan" writes:
>>If the forward and the reverse element are never both present in the
>>same pair (=either one is present or the other, but never both, in any
>>given pair), what is the point of having the attribute defined as
>>"pair"?
>>In that case it would make better sense to have two separate attributes
>>instead -- "forward certificate" and "reverse certificate".
>
>Well, we are trying to work with the defined X.509 attributes, so
>creating new ones which duplicate existing definitions will just muddy
>things further.  I agree, though, that things might have been 
>different.
>
Yes, I agree we should work with the defined attributes.
Presumably the crossCertificationPair attribute was defined as a pair
(and not as two separate attributes) for a good reason.

Jan Pachl
>SHL Systemhouse

From: Daya Puls <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 15:36:23 -0400 
Sender: [email-masked]

Daya Puls, CISSP
Intelligent Infrastructure Security Architect
COMPAQ, IM Security 
40 Old Bolton Road, OGO1-2/V12, Stow, MA 01775-1299
Fon: 978-496-9560, Fax: 978-496-9191, Eml: [email-masked]

From: [email-masked]
Subject: For Option 2
To: [email-masked] (IETF PKIX)
Date: Tue, 8 Sep 1998 15:23:54 +0000 ()
Sender: [email-masked]

From: [email-masked]
To: ietf-pkiximcorg <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 12:09:50 -0500
Sender: [email-masked]

Date: Tue, 08 Sep 1998 12:20:47 -0400
To: [email-masked]
From: [email-masked] (David Giglio)
Subject: For option 2
Sender: [email-masked]

___________________________________________________________________
David Giglio - Senior Product Manager 
Bay Networks, Inc.                Access Server Div.
M/S BL8-05                        [email-masked]
5 Federal Street                  978-916-4234 Office
Billerica, MA 01821               978-916-4782 Fax		

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Mike Smith" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Date: Tue, 8 Sep 1998 11:50:46 -0400
Importance: Normal
Sender: [email-masked]

I'm having a lot of trouble following this discussion. It appears to have
begun a discussion of the relative merits of X.500 vs LDAP server models.
This does not appear to be something which is relevant to PKIX.

LDAP is merely a protocol. It does not define a product. Arguments based on
the 'scalability' of a client-server protocol are almost without exception
irrelevant since scaling depends on server-server communication. The idea
that the same protocol should serve both purposes is questionable at best.

I fail to see how improved search capabilities will greatly assist for the
purposes of PKIX unless the directories have the ability to break open, read
and understand attributes embedded in certificates. If people believe that
support for a specific (and specified) search mechanism would lead to an
improvement in efficiency that is important to PKIX let us discuss that
specific extension.

We need to remember that we are charterted as an IETF working group and we
are not in a position to endorse a particular directory strategy.

If we want to be able to offload client work to a server of some kind we
should first consider the requirements that motivate such an architectural
approach and the trust implications of doing so before considering protocol
extensions. Indeed a critical step would be deciding which protocol to base
an implementation on.

		Phill

From: [email-masked]
To: ietf-pkiximcorg <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 10:41:10 -0500
Sender: [email-masked]

To: "PACHL, Jan" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: forward & reverse elements - population 
Date: Tue, 08 Sep 1998 16:38:15 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

"PACHL, Jan" writes:
>If the forward and the reverse element are never both present in the
>same pair (=either one is present or the other, but never both, in any
>given pair), what is the point of having the attribute defined as
>"pair"?
>In that case it would make better sense to have two separate attributes
>instead -- "forward certificate" and "reverse certificate".

Well, we are trying to work with the defined X.509 attributes, so
creating new ones which duplicate existing definitions will just muddy
things further.  I agree, though, that things might have been 
different.

>I can see some (limited?) use for populating both forward and reverse 
in
>the same pair, to record mutual certification.  Not primarily for path
>discovery, but for answering other questions about certification
>relationships.

Yes.  What I was trying to do was begin to pin down what it means when
both elements are present in the same value, and conscious mutual
certification seems an appropriate use. 

I suppose PKIX could specify that conforming CAs should not populate
both elements in a value, but that applications processing the values
for path development should not assume only one element is present.

I note that the X.509 certificatePairExactMatch matching rule doesn't
appear to cater for specifying 'values matching a forward certificate
assertion which have no reverse certificate', or vice versa.
Consequently, it may not be possible (using that Matching Rule, at
least) to obtain ONLY the forward certificates.

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

To: Sharon Boeyen <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: forward & reverse elements - population 
Date: Tue, 08 Sep 1998 16:36:43 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

Sharon Boeyen writes:

>3 - One more issue raised by David Boyce's proposed text was 
population of
>the crossCertificatePair attribute in the case where certification 
between
>two CAs is mutual. The syntax of the crossCertificatePair attribute is 
such
>that a single value of the attribute is one of the following:
>- only a forward element
>- only a reverse element
>- both a forward and reverse.
>
>I wonder though when one would be interested in retrieving a value 
that had
>both forward and reverse present? Does anyone have an example of a
>requirement for this?

I can think of one example where population of both elements could be
helpful for path development: the case when a strong bind request is
received which contains just a signature, so that a certificate path has
to be developed locally in order to verify the signature.

If during this development, a mutual certificate pair is encountered, it
might act as a hint that this is a good way to develop a certification
path in the opposite direction for use when responding to the bind
(assuming the responder intends to supply a certificate path in its
response).  Without this hint, building this path would be harder.

> When doing path discovery, regardless of the
>algorithm, wouldn't you be interested in one of the forward or reverse 
only
>for a given operation? If that is true then wouldn't it be better not 
to
>populate both forward and reverse in a single value but even in the 
case of
>mutual certification, spread these certificates over different values 
of the
>attribute? The reason I'm wondering about this is that the smallest 
unit of
>information that LDAP can return is a whole attribute value (can't 
pull only
>a forward or only a reverse from a single value). I'm trying to come 
up any
>reason for wanting the two together in the mutual case and having 
trouble
>coming up with a requirement. Again, when we get to the point of using
>LDAPv3 and more complex filtering capabilities, we may get to a point 
where
>we can retrieve single certs from the crossCertificatePair attribute, 
but if
>both forward and reverse are populated in the same attribute value, 
you'll
>get both certs. Views?

I don't think that LDAPv3 will give you any finer-grained control over
what is returned either.  It would require transporting less than a
whole value of an attribute, and it's hard to see how this would be
something LDAPv3 would want to define.  For path development purposes, I
agree it's a pity to have to transport the reverse certificate with the
forward, only to discard it because it's of no interest;  but there it
is.

Some may feel that this bandwidth issue is enough to rule out populating
both elements.  It doesn't actively get in the way of path development,
however, and there may be a meaningful population of both elements.

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-10.txt
Date: Tue, 08 Sep 1998 11:02:09 -0400
Sender: [email-masked]

--NextPart

Note: This revision reflects comments received during the last call period.

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 Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, T. Polk, D. Solo 
	Filename	: draft-ietf-pkix-ipki-part1-10.txt
	Pages		: 129
	Date		: 04-Sep-98
	
   This is the tenth draft of the Internet Public Key Infrastructure
   X.509 Certificate and CRL Profile.  This draft is the result of
   Working Group Last Call, and includes modifications to reflect the
   group's final 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.

Internet-Drafts are 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-ipki-part1-10.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-10.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-part1-10.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-ipki-part1-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part1-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: [email-masked]
To: [email-masked]
Date: Tue, 8 Sep 1998 10:55:28 -0400
Subject: For Option 2
Sender: [email-masked]

Jean Bernatchez
09/08/98 10:55 AM

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 10:05:30 -0400
Sender: [email-masked]

comments in-line.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Monday, September 07, 1998 8:02 PM
> To:	[email-masked]'
> Subject:	forward & reverse elements - population
> 
> Three related  issues:
> 
> 1 - raised by Denis - need to clarify how one way certification of a
> CA to
> another CA is represented in the crossCertificationPair attribute (as
> opposed to bilateral)
> 
> Denis - would adding some text along the lines of that proposed by
> David
> Boyce (that at least one of the forward or reverse elements must be
> present
> in a value of the crossCertificatePair attribute) satisfy that?
> 
> 2 - raised by Santosh -  population of the reverse element of the
> crossCertificatePair attribute not to be mandated.
> 
> Santosh, I tend to agree with this. I'm curious whether you (and
> others)
> think we can mandate, especially in a schema spec, that the forward
> certificates be published by the subject CA either? Is a schema spec
> really
> the place to dictate CA behaviour? Or should the schema spec provide
> the
> tools to be used for publishing the certs, should the CA decide to
> publish
> them. 
> 
	[]  I agree.  I do not have problem with the following language.
" A certificate issued to a CA by another shall be stored either in the
caCertificate or forward component of crossCertificatePair attribute of
the subject CA.  Optionally, a subset of certificates issued by a CA can
be stored in the reverse component of crossCertificatePair attribute of
the issuing CA."

	Please note that to me subset includes none, some, or all.  If
folks want further clarification, it is ok by me.

> In the case of option 2, if we mandate neither, the
> crossCertificatePair
> attribute would contain all the certificates of the forward and
> reverse
> types that this CA has decided to publish. The content of the
> cACertificate
> attribute would still be a subset of the content of the
> crossCertificatePair
> attribute plus self issued certificates. This would result in a
> situation
> where some certificates would be published only in the issuing CAs
> entry,
> some only in the subject CAs entry and others in both. But in all
> cases a
> relying party would be able to find them in the crossCertificatePair
> attribute and if the relying party understood the CAs definition of
> domain
> they could take advantage of the subset published in that CAs
> cACertificate
> attribute.
> 
> Do you think this reflects the real business needs or do you think we
> need
> to mandate that the subject CA publish forward certificates issued for
> it? I
> lean toward not mandating either, but can go along with either
> approach on
> this one.
> 
> 3 - One more issue raised by David Boyce's proposed text was
> population of
> the crossCertificatePair attribute in the case where certification
> between
> two CAs is mutual. The syntax of the crossCertificatePair attribute is
> such
> that a single value of the attribute is one of the following:
> - only a forward element
> - only a reverse element
> - both a forward and reverse.
> 
> I wonder though when one would be interested in retrieving a value
> that had
> both forward and reverse present? Does anyone have an example of a
> requirement for this? When doing path discovery, regardless of the
> algorithm, wouldn't you be interested in one of the forward or reverse
> only
> for a given operation? If that is true then wouldn't it be better not
> to
> populate both forward and reverse in a single value but even in the
> case of
> mutual certification, spread these certificates over different values
> of the
> attribute? The reason I'm wondering about this is that the smallest
> unit of
> information that LDAP can return is a whole attribute value (can't
> pull only
> a forward or only a reverse from a single value). I'm trying to come
> up any
> reason for wanting the two together in the mutual case and having
> trouble
> coming up with a requirement. Again, when we get to the point of using
> LDAPv3 and more complex filtering capabilities, we may get to a point
> where
> we can retrieve single certs from the crossCertificatePair attribute,
> but if
> both forward and reverse are populated in the same attribute value,
> you'll
> get both certs. Views?
> 
> 
> 
> 
> ------------------
> Sharon Boeyen                  
> Entrust Technologies
> 
> mailto:[email-masked]  Tel: (613) 247-3181 
> http://www.entrust.com            Fax: (613) 247-3690 
>        

From: [email-masked]
To: [email-masked]
Subject: For Option 2
Date: Tue, 8 Sep 1998 10:03:01 -0400
Sender: [email-masked]

To whom it may concern, 

For Option 2. 

Regards, 

J.P. Lachance 
Senior Systems Engineer 
PMO GOC PKI 
Communications Security Establishement 
Tel: 613-991-7504 
Fax: 613-991-7455 
Internet: [email-masked]

From: "PACHL, Jan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 08:58:19 -0500
Sender: [email-masked]

If the forward and the reverse element are never both present in the
same pair (=either one is present or the other, but never both, in any
given pair), what is the point of having the attribute defined as
"pair"?
In that case it would make better sense to have two separate attributes
instead -- "forward certificate" and "reverse certificate".

I can see some (limited?) use for populating both forward and reverse in
the same pair, to record mutual certification.  Not primarily for path
discovery, but for answering other questions about certification
relationships.

Jan Pachl
SHL Systemhouse

>From: 	Sharon Boeyen[SMTP:[email-masked]]
>[ ... ]
>
>3 - One more issue raised by David Boyce's proposed text was population of
>the crossCertificatePair attribute in the case where certification between
>two CAs is mutual. The syntax of the crossCertificatePair attribute is such
>that a single value of the attribute is one of the following:
>- only a forward element
>- only a reverse element
>- both a forward and reverse.
>
>I wonder though when one would be interested in retrieving a value that had
>both forward and reverse present? Does anyone have an example of a
>requirement for this? When doing path discovery, regardless of the
>algorithm, wouldn't you be interested in one of the forward or reverse only
>for a given operation? If that is true then wouldn't it be better not to
>populate both forward and reverse in a single value but even in the case of
>mutual certification, spread these certificates over different values of the
>attribute? The reason I'm wondering about this is that the smallest unit of
>information that LDAP can return is a whole attribute value (can't pull only
>a forward or only a reverse from a single value). I'm trying to come up any
>reason for wanting the two together in the mutual case and having trouble
>coming up with a requirement. Again, when we get to the point of using
>LDAPv3 and more complex filtering capabilities, we may get to a point where
>we can retrieve single certs from the crossCertificatePair attribute, but if
>both forward and reverse are populated in the same attribute value, you'll
>get both certs. Views?
>
>

From: [email-masked]
To: [email-masked]
Subject: For Option 2
Date: Tue, 8 Sep 1998 09:07:44 -0400
Sender: [email-masked]

From: [email-masked]
To: [email-masked]
Subject: For option 2
Date: Mon, 7 Sep 1998 09:34:21 -0400
Sender: [email-masked]

Date: Tue, 08 Sep 1998 07:23:34 -0400
To: [email-masked]
From: "John A. DiDuro" <[email-masked]>
Subject: for Option 2
Sender: [email-masked]

From: Jeremy Bingham <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:12:07 -0400
Sender: [email-masked]

Date: Tue, 08 Sep 1998 10:26:20 +0200
From: Ton van Lieshout <[email-masked]>
Reply-To: [email-masked]
Organization: Point Information Systems B.V.
To: [email-masked]
Subject: FOR OPTION 2
Sender: [email-masked]

As an Entrust prtner, we vote for option 2.

Ton van Lieshout
Technical Director

From: =?iso-8859-1?Q?Svein_L=F8seth?= <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:05:31 +0100
Sender: [email-masked]

---------------------------------------------------------------------------------------------------------------------------
Svein Løseth						Tlf.:    +47-22 95 86 83
Network Security AS					Fax:    +47-22 60 44 27
Gaustadalléen 21				    Dir. Line:    +47-22 95 85 48
N-0371 OSLO						GSM: +47-91 77 09 63
NORWAY						http://www.security.no

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: forward & reverse elements - population
Date: Mon, 7 Sep 1998 20:01:30 -0400 
Sender: [email-masked]

Three related  issues:

1 - raised by Denis - need to clarify how one way certification of a CA to
another CA is represented in the crossCertificationPair attribute (as
opposed to bilateral)

Denis - would adding some text along the lines of that proposed by David
Boyce (that at least one of the forward or reverse elements must be present
in a value of the crossCertificatePair attribute) satisfy that?

2 - raised by Santosh -  population of the reverse element of the
crossCertificatePair attribute not to be mandated.

Santosh, I tend to agree with this. I'm curious whether you (and others)
think we can mandate, especially in a schema spec, that the forward
certificates be published by the subject CA either? Is a schema spec really
the place to dictate CA behaviour? Or should the schema spec provide the
tools to be used for publishing the certs, should the CA decide to publish
them. 

In the case of option 2, if we mandate neither, the crossCertificatePair
attribute would contain all the certificates of the forward and reverse
types that this CA has decided to publish. The content of the cACertificate
attribute would still be a subset of the content of the crossCertificatePair
attribute plus self issued certificates. This would result in a situation
where some certificates would be published only in the issuing CAs entry,
some only in the subject CAs entry and others in both. But in all cases a
relying party would be able to find them in the crossCertificatePair
attribute and if the relying party understood the CAs definition of domain
they could take advantage of the subset published in that CAs cACertificate
attribute.

Do you think this reflects the real business needs or do you think we need
to mandate that the subject CA publish forward certificates issued for it? I
lean toward not mandating either, but can go along with either approach on
this one.

3 - One more issue raised by David Boyce's proposed text was population of
the crossCertificatePair attribute in the case where certification between
two CAs is mutual. The syntax of the crossCertificatePair attribute is such
that a single value of the attribute is one of the following:
- only a forward element
- only a reverse element
- both a forward and reverse.

I wonder though when one would be interested in retrieving a value that had
both forward and reverse present? Does anyone have an example of a
requirement for this? When doing path discovery, regardless of the
algorithm, wouldn't you be interested in one of the forward or reverse only
for a given operation? If that is true then wouldn't it be better not to
populate both forward and reverse in a single value but even in the case of
mutual certification, spread these certificates over different values of the
attribute? The reason I'm wondering about this is that the smallest unit of
information that LDAP can return is a whole attribute value (can't pull only
a forward or only a reverse from a single value). I'm trying to come up any
reason for wanting the two together in the mutual case and having trouble
coming up with a requirement. Again, when we get to the point of using
LDAPv3 and more complex filtering capabilities, we may get to a point where
we can retrieve single certs from the crossCertificatePair attribute, but if
both forward and reverse are populated in the same attribute value, you'll
get both certs. Views?

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Mon, 07 Sep 1998 15:30:57 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: PKIX freeware library coming soon (fwd)
Sender: [email-masked]

At 12:49 AM 9/8/98 +0200, Monica Pietrosanu-Ene wrote:
>Any recent news related to that freeware library?
>I searched the MIT site and I didn't find anything related to that
implementation. It should be available by the end of August, isn't it?

There is a new mailing list to discuss the library. Please see
<http://www.imc.org/imc-pfl/> for more information on the mailing list and
the library. I've been told that the folks making the library are
almost-almost ready to release the first version (they can't turn the page
on their calendars to September until they do...). At that point, the new
mailing list for the library should become active.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: Mike Smith <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 7 Sep 1998 11:59:43 -0700
Subject: Re: Relational vs Directory Repository Models (was RE: path development complexity s)
Sender: [email-masked]

and with an intelligent repository, along with assumptions about knowing
every
use to contain risk/liability exposures and provide timely status ... and a
nudge in the protocol
here & there ... it becomes account authority instead of certification
authority
client gets even thinner ... and account authority provides enhanced value
transaction (most of the certificates are redundant/superfluous).

Date: Mon, 07 Sep 1998 21:35:28 +0400 (MSK DST)
From: Pavel Krylov <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: depth
Sender: [email-masked]

My question:
        What depth of certificate tree is exist now?? Average value?

Sharon, Santosh? 

---------------------------------------
Pavel V.Krylov          [email-masked]

Date: Mon, 07 Sep 1998 11:23:32 -0600
From: Mike Smith <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Re relational - and Dirs and all that
Sender: [email-masked]

Thanks for the remedial lesson.  We also tend towards business objects in design and implmentation.  

I too, think that these hybrid systems are the direction of the future.

michael

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re relational - and Dirs and all that
Date: Tue, 8 Sep 1998 03:01:12 +1000
Sender: [email-masked]

Alan: Mike the amazing thing is I am in Charlotte US and working remote
to Aus. I had to repaste the text as I got an error? in the long
distance server?
Comments in line marked Alan. 

Quick response from so far away, I am still amazed at this Internet
technology, even though I've been relying on it daily, since the early
'80s.  :)

Alan: I have been relying on since 9.00 AM this morning :-)

Mike: With an X500 model, then one would have to create the directory
service agents (DSA) to actually process the requests.  My limited
understanding of how these work makes it complex indeed to process
through multiple
layers from one DSA to another (using DAP to cahin to other
"directories").

Alan: Directories are distributed, object oriented, named based
transaction systems. They operate on distributed naming contexts with
objects such as  people (that have certs) and CAs that have certs.
Directories to us are the foundation for new forms distributed
information engineering. (However, LDAP servers (non X.500 ones) do not
do distribution - so watch out for the scaling issues with those
things).
Most think LDAP servers are the only forms of directories and because
they have distribution issues - it means that all directories have
distribution issues - X.500 (which can have LDAP access) does not have
these, therefore the information solution space is wider than LDAP
server only systems.

Mike: Server side logic, whether stored procedures, external routines or
objects from an Application Server, seems less complex for development
of client server applications with thin clients, since the variety of
tools and supporting technology is so available.  My "take" on X500
models is that the directory system was designed for thin servers and
thin cleints (thinner clients with the original LDAP, fatter clients
(almost DAP) with the current LDAP models).   Now, the discussion seems
to be on how fat (huge) and intelligent (brilliant) to make the clients.

Alan: Thin and fat seems can get mixed up these days. There is the
stacks - LDAP  is about 230kb and DAP which is about 130kb. LDAP on
bigger searches becomes less efficient and DAP has features that deal
with master/copy entries and controlling chaining ie. DAP has twice
(scaleable) the functionality than LDAP. 
In terms of "processing" above the stack - LDAP clients do more because
they have to chase referrals (no chaining in the servers) and with the
LDAP servers (non X.500 ones) if one wants to authenticate users one has
to replicate everything to everywhere. ie. what LDAP does not do that
X.500 does.. Humans have to.

Mike: As you have discovered, a relational DBMS can perform all of the
functions of the X.500 requirements and a whole lot more.  

Alan: But X.500 deals correctly with object oriented engineering,
distributed name based systems and scaling. There is a difference. DBMSs
deal with data management with integrity (as well as many other
things)they (RDBs) do not distribute or scale in the same way-   X.500
is about protected distributed object oriented engineering. We have put
the both together (RDBs and X.500) - in fact we have made commercial
RDBMs extremely fast and distributed object oriented system that is
conformant to X.500 (with LDAP access and provides LDAP server
interconnectivity).

Mike: As a business-focused technologist, I also like the easier
integration of an RDBMS-engined repository with the RDBMS' that are used
to run the business  (I know some Directory schemes output data to RDBMS
- some may even allow two-way communication).  I like the idea of
searching multiple RDBMS sources in one query instead of chaining DSA to
DSA - I also think the logic can be more comprehensive.  By
comprehensive, let's say against a rule set that can contain more than
one decision matrix, maybe with some knowledge-based intelligence
acquired from yet another DBMS.  I can envision a central-responder
repository model that "handles" simple requests for path building that
get as complex as necessary across hierarchical, cross-certified, policy
mapped, Web of trust, personal trust, bilaterally agreed relationships
AND others yet to be defined. 

Alan: I am a very business focussed technologist and believe that OO
distributed systems are required and that these will integrate with RDBs
where appropriate (eg. Legacy systems or where relational requirements
extend beyond those as affored with OO/RDB systems (like our directory).
We provide a range of tools for RDBs and LDIF interchange and
integration.

Mike: Relationship management becomes the central repository's concern,
not that of the relying party.  The relying party needs a business
relationship with the central repository, or their CA (issuer) does.
Contracts and agreements amongst the players need to exist for a central
system to work, but there are business models that can support highly
complex relationship structures.

Alan: Some - repeat some of this can be designed with directories and OO
structures.

Mike: I tend to think of how to incorporate a workable PKI into an
electronic commerce scenario that may involve business relationships
with thousands of companies, hundreds of financial institutions and
their millions of customers.  

Alan: We do - in fact we scale to these requirements.

Mike: In all probability, this means working with many PKI systems and
models and their varied implementations.  I do not see a system
accepting "all" certificates coming into it.  Having said that, though,
in business, its always risk vs. reward and if someone wishes to reward
(and indemnify) me enough to honor self-authenticated or other "weak"
certificates, maybe I'll need to incorporate that into my model as well.

Mike: I do not see basing a business solely on a directory, no matter
its integrity or "globalness".  I do not even see basing a directory
service business solely on an X.500 directory.

Alan: Some do now - the trend is to have distributed systems and basing
these on scaleable - mutually authenticated OO - X.500 technologies.
However, this does not mean that some centralised RDB applications wont
exist - they will in our view become "directory enabled" so they can
interwork with WEB/RDB/OO(X.500)business information infrastructures
that support a range of authenticated role based people and
applications.
This is the new approach to business information system modelling - and
this also includes multi - distributed CA/PKI functions.

I do find business uses for directory-structured systems, but find the
duplication of data and differing and costly development environment
(ASN.1 vs C++, ProC, SQL, Java, or whatever) annoying.  I look towards
enterprise services for customers and employees that incorporates PKI -
not to PKI as something totally separate.

Alan: Absolutely

So, that's the origin of my comments on relational "vs." directory.  I
really think that there should be a synthesis, not an opposition.

Since both LDAP and X.500 and X.509 (with version 3) are independent of
the directory model and technology,
 
Alan: Dont quite agree - X.509 will not go far without X.500.

if we think "outside the X.500 box", then we can use the strengths of
the X.500 directory model and add on some strenghts in logic processing
from the tools in the RDBMS world.

Alan: We did and we have and we do - see Integrated Information
Infrastructures.
I will send a paper off list.

 That way, one can support LDAP, DAP, Java Applets, integrated client
applications, or whatever development technology becomes available
across IP to meet constantly changing business requirements.

Alan: Agree

Alan: Regards alan

  Michael 

Snip..

Date: Mon, 07 Sep 1998 10:01:25 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Sender: [email-masked]

Quick response from so far away, I am still amazed at this Internet technology, even though I've been relying on it daily, since the early '80s.  :)

With an X500 model, then one would have to create the directory service agents (DSA) to actually process the requests.  My limited understanding of how these work makes it complex indeed to process through multiple layers from one DSA to another (using DAP to cahin to other "directories").

Server side logic, whether stored procedures, external routines or objects from an Application Server, seems less complex for development of client server applications with thin clients, since the variety of tools and supporting technology is so available.  My "take" on X500 models is that the directory system was designed for thin servers and thin cleints (thinner clients with the original LDAP, fatter clients (almost DAP) with the current LDAP models).   Now, the discussion seems to be on how fat (huge) and intelligent (brilliant) to make the clients.

As you have discovered, a relational DBMS can perform all of the functions of the X.500 requirements and a whole lot more.  As a business-focused technologist, I also like the easier integration of an RDBMS-engined repository with the RDBMS' that are used to run the business  (I know some Directory schemes output data to RDBMS - some may even allow two-way communication).  I like the idea of searching multiple RDBMS sources in one query instead of chaining DSA to DSA - I also think the logic can be more comprehensive.  By comprehensive, let's say against a rule set that can contain more than one decision matrix, maybe with some knowledge-based intelligence acquired from yet another DBMS.  I can envision a central-responder repository model that "handles" simple requests for path building that get as complex as necessary across hierarchical, cross-certified, policy mapped, Web of trust, personal trust, bilaterally agreed relationships AND others yet to be defined.  

Relationship management becomes the central repository's concern, not that of the relying party.  The relying party needs a business relationship with the central repository, or their CA (issuer) does.  Contracts and agreements amongst the players need to exist for a central system to work, but there are business models that can support highly complex relationship structures.

I tend to think of how to incorporate a workable PKI into an electronic commerce scenario that may involve business relationships with thousands of companies, hundreds of financial institutions and their millions of customers.  In all probability, this means working with many PKI systems and models and their varied implementations.  I do not see a system accepting "all" certificates coming into it.  Having said that, though, in business, its always risk vs. reward and if someone wishes to reward (and indemnify) me enough to honor self-authenticated or other "weak" certificates, maybe I'll need to incorporate that into my model as well.

I do not see basing a business solely on a directory, no matter its integrity or "globalness".  I do not even see basing a directory service business solely on an X.500 directory.

I do find business uses for directory-structured systems, but find the duplication of data and differing and costly development environment (ASN.1 vs C++, ProC, SQL, Java, or whatever) annoying.  I look towards enterprise services for customers and employees that incorporates PKI - not to PKI as something totally separate.

So, that's the origin of my comments on relational "vs." directory.  I really think that there should be a synthesis, not an opposition.

Since both LDAP and X.500 and X.509 (with version 3) are independent of the directory model and technology, if we think "outside the X.500 box", then we can use the strengths of the X.500 directory model and add on some strenghts in logic processing from the tools in the RDBMS world.

That way, one can support LDAP, DAP, Java Applets, integrated client applications, or whatever development technology becomes available across IP to meet constantly changing business requirements.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 9:15 AM >>>
 Mike - I am not sure if I understand your response as it mixes
technology statements.
So comments in line.

----------
From: Mike Smith
To: [email-masked]; [email-masked] 
Cc: [email-masked]; [email-masked] 
Sent: 9/8/98 12:27:08 AM
Subject: Relational vs Directory Repository Models (was RE:
pathdevelopment complexity s)

Some of you have heard this before from me and others, but, maybe it's
worth repeating at this time.

AL: Its new to me so thanks.

Complexity of the problem of path building requires a more
robust/intelligent repository. 

AL: Agree 

 Think out of the directory model and consider a relational database
behind the LDAP responder.  Per cert request times may be slower, but
the ability to work with multiple business (trust) models and supply ALL
of the necessary certs (in one query) for the most complex path
validation scenario outweighs (and maybe outperforms) a series of
client-side processing and LDAP requests.

AL: This is an implementation issue - we use a Patented SQL design under
our X.500 LDAP product and its fast including distributed (multi server)
operations.
One always scales the hardware, processing, process and DB and network
to do the job anyway.

The business logic for multiple trust models would reside on the host.
The LDAP request could be parsed, the business (trust) rules selected
according to either or both the relying party's and sender's trust
requirements.  

AL: Host - is this a server or a mainframe - this is a sizing issue? 
Perhaps a view of the system should be:

a)A distributed X.500 system with high performance (even though it uses
SQL RDBMS ) to give it industry strength and integrity.

b) LDAP or DAP (DAP is for the lucky few that want to control the scope
of directory chaining to get a cert path and getting Master cert from CA
entries:-)  ) access by the client software - with the presented cert
and the domain in which validation is required information.
Note: yet another weakness in LDAP will show up with trust/scope of cert
path processing...Somehow LDAP and LDAP servers just dont seem to mix
with X.509, certpath processing and CAs...

c) A CA that populates its portion of The interconnected DIB with CA
certs, CRLs, etc and validation information. 

d)Trusted CA utilities that run/execute on the CA "server" or "host" to
manage the CA's validation "environment".

The RDBMS and its server-side business logic can even chain requests to
other CA directories if necessary.

AL: Yes - there is nothing to stop a directory request to retrieve
something with a Search/Matching rule into subordinate objects below the
CA entry in question - via alias or cross referencing to other CAs DIBs
- but this is a bit messy re Search and Trust management. But very
achieveable with a few extensions to Results Correlation processing or
CA Utilities.

Of course, my perspective is that the business logic and trust
requirements come from the CA, not the end-user.  If the trust model
rule making is placed on the end user, then one would need to design a
pretty fat, customer customizable client software piece.

AL: Agree and totally agree. The way things were turning out with client
cert validation software is like LDAP clients have - more code in them
than in a DSA. Simply because they incorporated (lesser) distribution
handling functions - eg. referrals, replication management, etc - than
X.500 DSAs in fact do. Fat unwieldy clients are symptomatic of what
happens if one has no distributed (server) system, information and
service based model to work with.
regards alan
PS - the draft for dir cert stat will be formally circulated next week.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 7:55 AM >>>
 
Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked] 
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

From: Alan Lloyd <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "'Mike Smith '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: Relational vs Directory Repository Models (was RE: pathdevelo pment complexity s)
Date: Tue, 8 Sep 1998 01:15:58 +1000
Sender: [email-masked]

 Mike - I am not sure if I understand your response as it mixes
technology statements.
So comments in line.

----------
From: Mike Smith
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 9/8/98 12:27:08 AM
Subject: Relational vs Directory Repository Models (was RE:
pathdevelopment complexity s)

Some of you have heard this before from me and others, but, maybe it's
worth repeating at this time.

AL: Its new to me so thanks.

Complexity of the problem of path building requires a more
robust/intelligent repository. 

AL: Agree 

 Think out of the directory model and consider a relational database
behind the LDAP responder.  Per cert request times may be slower, but
the ability to work with multiple business (trust) models and supply ALL
of the necessary certs (in one query) for the most complex path
validation scenario outweighs (and maybe outperforms) a series of
client-side processing and LDAP requests.

AL: This is an implementation issue - we use a Patented SQL design under
our X.500 LDAP product and its fast including distributed (multi server)
operations.
One always scales the hardware, processing, process and DB and network
to do the job anyway.

The business logic for multiple trust models would reside on the host.
The LDAP request could be parsed, the business (trust) rules selected
according to either or both the relying party's and sender's trust
requirements.  

AL: Host - is this a server or a mainframe - this is a sizing issue? 
Perhaps a view of the system should be:

a)A distributed X.500 system with high performance (even though it uses
SQL RDBMS ) to give it industry strength and integrity.

b) LDAP or DAP (DAP is for the lucky few that want to control the scope
of directory chaining to get a cert path and getting Master cert from CA
entries:-)  ) access by the client software - with the presented cert
and the domain in which validation is required information.
Note: yet another weakness in LDAP will show up with trust/scope of cert
path processing...Somehow LDAP and LDAP servers just dont seem to mix
with X.509, certpath processing and CAs...

c) A CA that populates its portion of The interconnected DIB with CA
certs, CRLs, etc and validation information. 

d)Trusted CA utilities that run/execute on the CA "server" or "host" to
manage the CA's validation "environment".

The RDBMS and its server-side business logic can even chain requests to
other CA directories if necessary.

AL: Yes - there is nothing to stop a directory request to retrieve
something with a Search/Matching rule into subordinate objects below the
CA entry in question - via alias or cross referencing to other CAs DIBs
- but this is a bit messy re Search and Trust management. But very
achieveable with a few extensions to Results Correlation processing or
CA Utilities.

Of course, my perspective is that the business logic and trust
requirements come from the CA, not the end-user.  If the trust model
rule making is placed on the end user, then one would need to design a
pretty fat, customer customizable client software piece.

AL: Agree and totally agree. The way things were turning out with client
cert validation software is like LDAP clients have - more code in them
than in a DSA. Simply because they incorporated (lesser) distribution
handling functions - eg. referrals, replication management, etc - than
X.500 DSAs in fact do. Fat unwieldy clients are symptomatic of what
happens if one has no distributed (server) system, information and
service based model to work with.
regards alan
PS - the draft for dir cert stat will be formally circulated next week.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 7:55 AM >>>
 
Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked] 
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Mon, 07 Sep 1998 08:27:08 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Relational vs Directory Repository Models (was RE: path development complexity s)
Sender: [email-masked]

Some of you have heard this before from me and others, but, maybe it's worth repeating at this time.

Complexity of the problem of path building requires a more robust/intelligent repository.  Think out of the directory model and consider a relational database behind the LDAP responder.  Per cert request times may be slower, but the ability to work with multiple business (trust) models and supply ALL of the necessary certs (in one query) for the most complex path validation scenario outweighs (and maybe outperforms) a series of client-side processing and LDAP requests.

The business logic for multiple trust models would reside on the host.  The LDAP request could be parsed, the business (trust) rules selected according to either or both the relying party's and sender's trust requirements.   

The RDBMS and its server-side business logic can even chain requests to other CA directories if necessary.

Of course, my perspective is that the business logic and trust requirements come from the CA, not the end-user.  If the trust model rule making is placed on the end user, then one would need to design a pretty fat, customer customizable client software piece.

Michael

>>> Alan Lloyd <[email-masked]> 09/07 7:55 AM >>>
 
Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked] 
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Mon, 07 Sep 1998 15:58:39 +0200
To: "Aram Perez" <[email-masked]>, bob jueneman <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: [email-masked]
Sender: [email-masked]

Hi Aram,

Some comments follow.

At 10:17 AM 9/4/98 -0700, Aram Perez wrote:
>Bob and Stefan:
>
>>At 06:42 PM 9/2/98 -0600, Bob Jueneman wrote:
>><snip>
>>>>I suggest that we stick to the standardized definitions of the key usage
>>>>bits and leave
>>>>policy issues out of a common certificate profile.
>>>
>>>If there were any sense of the community as to what these definitions
really
>>>mean, or ought to mean, we would probably not be having this discussion.
>>>Otherwise I would agree with you.
>>>>
>>>>non-repudiation is according to standard selected by the NR bit, not NR in
>>>>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>>>>other than non-repudiation are allowed for the key.
>
>Is non-repudiation a mechanism or a service?

Sorry for my careless language. Non-repudiation is a service and that
service is not defined by the CA. However the CA may indicate that the
certificate is aimed to support that service.

>
>>>
>>>I believe that is exactly the issue. Are you suggesting that NR plus DS
>>should not
>>>be allowed?  Why?
>>
>>No I do not. I do suggest that such decision is up to local policy. But
>>there will be some policies where this combination will not be allowed, but
>>I think you agree to that.
>
>My problem with this is that to provide "digital" non-repudiation, you
have to
>"sign" something with a digital signature. I understand that the key usage
field
>is very overloaded, so I'll probably have to live with it, but I do not
agree or
>like it.

Yes and no. It is clear that X509 has mixed two levels. The mechanism level
and the service level. Looking back in the mirror that might have been a
bad mix. What's even worse is that the service bit NR in some cases is used
as an alternative to DS. To accomplish this the standard has been forced to
define both bits to a combined service/mechanism bit. I.e. NR is selecting
use of digital signatures and DS is selecting services other than
non-repudiation. This is causing the messy debate and could be used as an
argument for a defect report.

However considering the standard as it is, can we use it? Yes I think so,
even if it's not perfect. 

>
>>
>>The important thing is that I suggest that the NR bit and DS bit has
>>separate meaning and that they should be set independently to specify DS,
>>NR or both.
>>
>>The vague definition of the NR bit is a problem, I agree to that.
>
>YES!!
>
>>
>>If I were to define some distinguishing property of the NR bit that would
be:
>>
>>   Non repudiation denotes services constructed in such way that:
>>   1) The signature provides proof of the integrity and 
>>      origin of data - both in an unforgeable relationship - which can be 
>>      verified by any third party at any time.[X.509 / ISO 9594-8]
>>   2) The signature is applied to a message where the signatory is capable
>>      of, and required to, accept responsibility for the message content 
>>      before signing.
>
>But NR is set in the certificate (i.e. the public key) and does not tell you
>whether the signatory (who is using the private key) actually was capable of
>accepting responsibility.

Yes you are right, it doesn't. And it shouldn't. Since the CA isn't the
provider of that service the certificate will tell nothing about the
service in which the certificate is used. The key usage bit is a
requirement stated by the CA for staying with it's liabilities, not a
promise that the requirements will be met.

>
>>   3) The signatory's liability for signing the message can be concluded
>>      from the signed message itself, possibly within a well known and
agreed 
>>      context that can be verified by any third party at any time.
>>
>>This definitions rules out any signed logon ticket or other data
>>authentication mechanisms where the signature says "this message wasn't
>>changed" instead of "I take full responsibility for the message content".
>
>You do not need a digital signature to tell you "this message wasn't
changed".
>CRCs, LRCs, checksums, etc have been used for this longer that I've been
alive.
>You use digital signature when you want to know "this message wasn't changed"
>AND "this message came from the reported sender".
>

Agreed. I guess my point still stands.

>>
>>But since this is not defined by the bit (which I regret) the way to go
>>will be for the CA to include this in it's published certificate policy.
>
>I doubt whether a CA is going to take responsibility and liability for
something
>it has no control over. The CA does not know what applications and crypto
APIs
>the owner of the private key is using.
>

The CA will not assume responsibility for services utilizing the
certificates. It will only be liable for its issued certificates. Again,
the CA is not the provider of the NR service. Still, the CA will in some
cases state requirements on supported services. Don't forget the original
task for the CA. It is just to provide statements to be used as guidance by
certificate users.

>>
>>I can't see any other way for now when utilizing the existing standard. I
>>would not object though to a defect report to get this into the standard.
>
>And I am willing to help (or lead) in this effort.
>
>>
>>In the new proposed work item, however, regaring a profile for
>>non-repudiation certificates supporting legal acceptance of digital
>>signatures I will try to get this definition in.
>>
>>Would you support it?
>
>I would be glad to help and support it.
>
>Regard,
>Aram Perez
>Apple Computer, Inc.
>
>

/Stefan

From: Alan Lloyd <[email-masked]>
To: "'Frank O'Dwyer '" <[email-masked]>
Cc: "'Dave Horvath '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Mon, 7 Sep 1998 23:55:08 +1000
Sender: [email-masked]

Thanks Frank - Its nice to see some reality re this issue. 
My draft submitted re dir cert stat.
point one is we all need a scaleable directory infrastructure for any CA
system to work and point two is we dont need CA information designs that
act as a maze for megabytes of client software to find the "way out"..

As said I think CAs must provide a validation service based on the cert
presented and the domain of the client requesting validation.

We seem to have gone down the track of inventing a X.509 CA model (and
directory objects) for the sake of a CA on what it wants to do with
certificate management - as the first part of the system design. As
opposed to a CA model that provides a simple client with a validation
service, which really is the second part of the system design.

For chasing cert paths - Names in the certficates should do - plus the
context (ie. the requestor) of the validation. And the CA should do the
rest.

The directory service and its matching rules proposed in the dir cert
stat doc are the foundation of this.

All thoughts on this area are welcome.

regards alan

----------
From: Frank O'Dwyer
To: Alan Lloyd
Cc: Dave Horvath; [email-masked]
Sent: 9/5/98 9:44:06 PM
Subject: Re: path development complexity (was Re: What the straw poll
mean	s)

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this
foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Mon, 07 Sep 1998 14:53:16 +0200
To: Bill Brice <[email-masked]>, pkix <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Defining Non-Repudiation
Sender: [email-masked]

Bill,

Thank you for your very clarifying information. This is a very important
perspective to have when discussing standardized certificate profiles.

As you may have seen I have proposed a new work item for PKIX regarding a
specific certificate profile based on PKIX part 1 to be used in the context
you describe. The ONLY rationale for this profile is to create a common
profile for technical interoperability. Not to achieve a globally
harmonized legal framework.

The new work item, called profile for Qualified Certificates, addresses
some of your issues:
<snip>
>(2)	The certificate is considered trustworthy (i.e., an accurate 
>binding of a public key to a person's identity) because the certificate 
>was issued by a certification authority in accordance with standards, 
>procedures, and other requirements specified by the Secretary of State, 
>or the trier of fact independently finds that the certificate was issued
>in a trustworthy manner by a certification authority that properly 
>authenticated the subscriber and the subscriber's public key, or 
>otherwise finds that the material information set forth in the 
>certificate is true.

The qualified certificate will be a certificate which includes a statement
by the issuer that it meets all requirements imposed by the governing legal
framework, regardless of what that legal framework states, to support
"Secure electronic signatures" according to your definition. Further the
qualified certificate profile will enhance interoperability in naming and
other essential attributes.

It would be nice to have your view on this. The work item has primary been
raised as an answer to needs arising from the European legal framework
development. It is though conducted in a generic approach that should be
independent of any legal framework. I hope that I can count on your input
to ensure that the profile will be consistent with the American legal
approach.

/Stefan

At 03:22 PM 8/21/98 -0500, Bill Brice wrote:
>All,
>
>There has been considerable discussion and debate on these
>lists regarding the proper use of the DS and NR KeyUsage bits
>in X.509v3 certificates.
>
>Lets look at this from a legal perspective for a moment,
>since a large part of digital signatures is being able
>to place some reliance on the data that is digitally signed.
>
>In the US, private contract law is governed primarily by the
>laws of the various US states. Under the Uniform Commercial Code 
>(in effect for many years now), as enacted by US state laws, 
>a signature is defined as "any symbol executed or adopted by 
>a party with the present intention to authenticate a writing". 
>
>This means that my typed name at the bottom of this message
>constitutes a valid "signature" under the law. This is a practice
>many people use in their e-mails, and it has a binding effect
>today, under present law. Were this e-mail digitally signed, you
>"might" be able to consider it a signature, but only if it were
>consciously signed by me with the "present intention to authenticate"
>this message.
>
>As a relying party this digital signature carries no more legal
>weight that my typed signature below. In a dispute, you as the relier
>would have the burden of proof that the signature on this message,
>whether typed or digitally signed, was valid. The court and/or jury
>would have to decide whether your reliance was "reasonable under
>the facts and circumstances" of the matter. It would make no
>difference what KeyUsage bit was set.
>
>In determining "reasonable reliance" there is a broad continuum.
>In the case of the typed signature: Do you personally know me?
>What other information did you have about me? What other correspondence
>have you received from me? Do you know my address and phone
>numbers? etc. etc. In the case of the digital signature the same
>questions would apply, plus: Do you understand anything about PKI?
>Who issued the certificate? What application software did you use to
>receive and verify the message?
>
>In fact, most people outside of this mailing list would quite reasonably
>have less comfort with this message were it digitally signed as opposed
>to a typed closing signature.
>
>Woe on the first relying party to litigate a repudiated digital 
>signature. It will likely cost over US$100,000.
>
>Fortunately, there is a way out of this messy state of affairs. And
>it impacts the DS/NR question.
>
>The US State of Illinois, after 18 months of study by the Illinois
>Commission on Electronic Commerce and Crime, passed a new EC law
>(to take effect July 1, 1999) titled the "Electronic Commerce
>Security Act". This comprehensive law not only recognizes digital
>signatures as being equally valid as a UCC (above) signature, but it
>create a new class of signature called a "secure electronic signature"
>and a new class of data record called a "secure electronic record".
>
>To quote from the Commission's report: "Secure electronic records and 
>secure electronic signatures define categories of records and 
>signatures that are accorded heightened evidentiary presumptions 
>because of their enhanced reliability and trustworthiness, 
>just as notarized documents are accorded heightened evidentiary 
>presumptions for the same reason.  The concept of a secure electronic 
>record and a secure electronic signature is critical to enabling 
>electronic commerce.  Businesses will be much more willing to enter 
>into commercial transactions, extend credit, commit resources, 
>ship goods, or otherwise rely on messages from contracting parties 
>transmitted over public networks such as the Internet when they can 
>be assured that such records and signatures will be accorded the 
>heightened evidentiary presumptions necessary to effectively make 
>their transactions nonrepudiable."
>
>The effect of this is that a relying party may presume that a
>"secure electronic signature" is valid and in a dispute the burden
>of proof shifts to the signer to rebut the presumption.
>
>This is the quality we would all like in a non-repudiable 
>digital signature. It will be necessary for other jurisdictions to
>follow the Illinois lead in order to give us the PKI world we would
>want (at least as far as digisig is concerned). I would urge Petra
>to consider this approach in the German legislation.
>
>In order to achieve this GOLD CARD level of non-repudiation the law
>provides as follows:
>
>----START
>Section 10-110.  Secure electronic signature.
>
>(a)	If, through the use of a qualified security procedure, 
>it can be verified that an electronic signature is the signature of a 
>specific person, then such electronic signature shall be considered to 
>be a secure electronic signature at the time of verification, if the 
>relying party establishes that the qualified security procedure was: 
>
>      (1)	commercially reasonable under the circumstances, 
>
>      (2)	applied by the relying party in a trustworthy manner,
>and
>
>      (3)	reasonably and in good faith relied upon by the relying
>party.
>
>(b)	A qualified security procedure for purposes of this Section is a
>
>security procedure for identifying a person that is:
>
>	(1)	previously agreed to by the parties, or
>
>	(2)	certified by the Secretary of State in accordance with 
>Section 10-135 as being capable of creating, in a trustworthy manner, 
>an electronic signature that:
>
>      (A)	is unique to the signer within the context in which it
>is used;
>
>      (B)	can be used to objectively identify the person signing
>the 
>electronic record;
>
>      (C)	was reliably created by such identified person, (e.g., 
>because some aspect of the procedure involves the use of a signature 
>device or other means or method that is under the sole control of such 
>person), and that cannot be readily duplicated or compromised, and
>
>      (D)	is created, and is linked to the electronic record to
>which it relates, in a manner such that if the record or the signature
>is intentionally or unintentionally changed after signing the electronic
>signature is invalidated.
>
>----END
>
>So, what's a qualified security procedure in the case of digital
>signatures?
>The law provides:
>
>----START
>Section 15-105.  Secure electronic signature.  A digital signature that 
>is created using an asymmetric algorithm certified by the Secretary 
>of State under item (2) of subsection (b) of Section 10-110 shall be 
>considered to be a qualified security procedure for purposes of 
>identifying a person under Section 10-110 if:
>
>(1)	The digital signature was created during the operational period 
>of a valid certificate, was used within the scope of any other 
>restrictions specified or incorporated by reference in the certificate, 
>if any, and can be verified by reference to the public key listed in 
>the certificate; and
>
>(2)	The certificate is considered trustworthy (i.e., an accurate 
>binding of a public key to a person's identity) because the certificate 
>was issued by a certification authority in accordance with standards, 
>procedures, and other requirements specified by the Secretary of State, 
>or the trier of fact independently finds that the certificate was issued
>
>in a trustworthy manner by a certification authority that properly 
>authenticated the subscriber and the subscriber's public key, or 
>otherwise finds that the material information set forth in the 
>certificate is true.
>----END
>
>So, what are the implications for the PKIX draft and this debate
>about DS/NR keybits?
>
>I believe the Illinois ECS Act gives us strong guidance on the direction
>of the law (at least US law). The key issue for PKIX is expressed in
>paragraph 1 of Section 15-105 above. Namely, that the digital signature
>"was used within the scope of any other restrictions specified or 
>incorporated by reference in the certificate, if any...".
>
>IMHO, this says that it's really up to the CA and what they say in
>their CPS and any Certificate Policies adopted by the CA. If a CA
>adopts the PKIX profile, which they don't have to, then it would be
>up to the CA to further clarify the meaning of the NR bit in their
>certificates. To me, the NR bit is a requirement for any CA whose
>certificates will be used in an open environment, and whose certs
>are intended to establish the kind of non-repudiation contemplated
>by the Illinois law. The DS bit is irrelevant in this context.
>
>Of course it would be great if the application software would pay
>any attention at all to the v3 extensions in a certificate. But,
>that's another story.
>
>
>Bill Brice, Chief PKI Architect
>International DataTrust
>PO Box 670789
>Dallas, TX 75367-0789
>+1.214.706.9320 (direct), +1.214.706.9321 (fax) 
>
>P.S. I'm not an attorney. While I participate in the American Bar
>Association's Information Security Committee, these opinions are
>my own and you should conduct your own investigation and seek
>you own legal advice on these matters. :)
>
>

Date: Mon, 07 Sep 1998 09:35:36 +0100
From: Jorgen Moller <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: "CliveBetteridge" <[email-masked]>
To: <[email-masked]>
Subject: Internet Directory Consortium call for participation in DirConnect3
Date: Sun, 6 Sep 1998 17:48:12 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00D9_01BDD9BE.846D2140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,=20

The interest in LDAP, especially V3 and extensions remains strong. With =
this increase in popularity of the technology come even greater =
requirements for interoperability of different suppliers' =
implementations. To enable cooperative LDAP testing in an engineers-only =
environment the Internet Directory Consortium proposes to hold a =
Dirconnect3 Interoperability Testing event.=20

If you are implementing LDAP clients or servers you are urged to =
consider this opportunity of meeting your peers in other organizations =
for some serious testing.

The location will be in the San Jose area.=20

The program will be as below:=20

Day 1

8:30 - 9:30 Set up, get acquainted, muffins, fruit, coffee, sodas

9:30 - 12:00 Testing

12:00 - 1:00 Lunch (buffet, served away from the work room)

1:00 - 5:00 Testing

5:00 - 5:30 Recap and plan for Day 2=20

8:30 - 12:00 Testing (muffins, fruit, coffee, sodas at 8:30)

12:00 - 1:00 Lunch (buffet, served away from the work room)

1:00 - 4:00 Testing

4:00 - 5:00 Review and prepare preliminary report

5:00 - 6:00 Tear down

A quick straw-poll suggests most favored dates to be in the week =
commencing Monday 26th October.

Please can you give me the answers to the following questions:

Are you likely to attend?=20

What date(s) would you prefer?

What would you like to test?

Basic LDAP V2?

Basic LDAP V3?

LDAP V3 Extensions? (please list)

I look forward to hearing from you.

Best regards

Clive

Clive Betteridge, Operations Manager - Internet Directory Consortium

The Open Group

Apex Plaza, Forbury Road, Reading RG1 1AX, UK

Mailto:[email-masked] Ph: +44 1344 642153

http://www.opengroup.org/idc/ Fx: +44 118 950 0110=20

------=_NextPart_000_00D9_01BDD9BE.846D2140
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>
<DIV><FONT color=3D#000000 face=3DArial>
<P>Dear all,</FONT><FONT face=3DArial>&nbsp;</P></FONT><FONT =
color=3D#000000=20
face=3DArial>
<P>The interest in LDAP, especially V3 and extensions remains strong. =
With this=20
increase in popularity of the technology come even greater requirements =
for=20
interoperability of different suppliers' implementations. To enable =
cooperative=20
LDAP testing in an engineers-only environment the Internet Directory =
Consortium=20
proposes to hold a Dirconnect3 Interoperability Testing =
event.</FONT><FONT=20
face=3DArial>&nbsp;</P>
<P>If you are implementing LDAP clients or servers you are urged to =
consider=20
this opportunity of meeting your peers in other organizations for some =
serious=20
testing.</P></FONT><FONT color=3D#000000 face=3DArial>
<P>The location will be in the San Jose area.</FONT><FONT=20
face=3DArial>&nbsp;</P></FONT><FONT color=3D#000000 face=3DArial>
<P>The program will be as below:</FONT><FONT =
face=3DArial>&nbsp;</P></FONT><FONT=20
color=3D#000000 face=3DArial>
<P>Day 1</P>
<P>8:30 - 9:30 Set up, get acquainted, muffins, fruit, coffee, sodas</P>
<P>9:30 - 12:00 Testing</P>
<P>12:00 - 1:00 Lunch (buffet, served away from the work room)</P>
<P>1:00 - 5:00 Testing</P>
<P>5:00 - 5:30 Recap and plan for Day 2 </P>
<P>8:30 - 12:00 Testing (muffins, fruit, coffee, sodas at 8:30)</P>
<P>12:00 - 1:00 Lunch (buffet, served away from the work room)</P>
<P>1:00 - 4:00 Testing</P>
<P>4:00 - 5:00 Review and prepare preliminary report</P>
<P>5:00 - 6:00 Tear down</P>
<P></P>
<P></P>
<P>A quick straw-poll suggests most favored dates to be in the week =
commencing=20
Monday 26th October.</P>
<P></P>
<P>Please can you give me the answers to the following questions:</P>
<P>Are you likely to attend? </P>
<P>What date(s) would you prefer?</P>
<P></P>
<P>What would you like to test?</P>
<P>Basic LDAP V2?</P>
<P>Basic LDAP V3?</P>
<P>LDAP V3 Extensions? (please list)</P>
<P></P>
<P></P>
<P>I look forward to hearing from you.</P>
<P></P>
<P>Best regards</P>
<P></P>
<P>Clive</P>
<P></P>
<P>Clive Betteridge, Operations Manager - Internet Directory =
Consortium</P>
<P>The Open Group</P>
<P>Apex Plaza, Forbury Road, Reading RG1 1AX, UK</P></FONT><U><FONT=20
color=3D#0000ff face=3DArial>
<P>Mailto:[email-masked]</U></FONT><FONT color=3D#000000=20
face=3DArial>&nbsp;Ph: +44 1344 642153</P></FONT><U><FONT =
color=3D#0000ff=20
face=3DArial>
<P>http://www.opengroup.org/idc/</U></FONT><FONT color=3D#000000=20
face=3DArial>&nbsp;Fx: +44 118 950 0110 =
</FONT></P></DIV></DIV></BODY></HTML>

------=_NextPart_000_00D9_01BDD9BE.846D2140--

Date: Sat, 05 Sep 1998 21:20:16 +0100
From: "Frank O'Dwyer" <[email-masked]>
To: [email-masked]
Subject: Re: path development complexity
Sender: [email-masked]

Robert Klerer wrote:
> As a believer in the thinner client, a (local and possibly trusted) network
> based resource can perform this task more efficiently than locating it on
> the client. 

That sounds like it would help a lot (and it would be useful) but I
would still be concerned that it wouldn't be enough. For example,
people expected a lot of HTTP proxy caches (a similar solution to a
similar kind of problem), but I think those turned out not to
deliver as much as was expected. 

You also have the problem of arbitrary/roaming users connecting to
ISPs -- there is not much reason to suppose that a responder located
at an ISP would do a very good job of caching paths, since the users
could be connecting to just about anything. (Caching would still
help I guess.)

Lastly, you have the problem that certificates themselves run fairly
big, and that will doubtless get worse as people stuff more
extensions in there (mpegs of cats spring to mind:). So if
cross-certificates really take off, one of these responders could
potentially wind up like a backbone IP router, holding paths to
everywhere, and needing ridiculous quantities of main memory just to
avoid thrashing. (The router problem is also a similar problem with
similar causes.)

Another analogy is an internet search engine - take a look at the
spec of machine that altavista runs on.

So, if it is possible (and I don't know if it is), it would be much
better to design the PKI structure so that path discovery was easy
in the first place. 

> And we can argue whether it is more vulnerable to denial of
> service attacks or not.  But since the validation of the discovered path
> will always remain a client function, we would only be vulnerable to denial
> attacks.

Well if the responder was out of service the client could always
fall back on searching for itself. It could keep a local cache of
discovered paths also, and search there first (again like the
HTTP/proxy scenario).

Cheers,
Frank O'Dwyer.

From: "Robert Klerer" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: path development complexity 
Date: Sat, 5 Sep 1998 10:13:36 -0400
Sender: [email-masked]

Frank,

You have identified the problem.  By design the cross-certification
arrangements are driven by the business (and social) rules rather than the
design of pkix.  We have put in some generic restrictions that can be
applied, like name constraints and path length limitations, but I would
expect application specific extensions to proliferate.

To make the problem of path discovery harder, a cross certification
arrangement may be valid for one application but not another.  For example,
Citibank may decide that their employees can exchange signed and encrypted
email with employees of IBM.  The cross certification arrangement between
their CA's may be constructed to lack the critical extension to be valid for
exchanging financial trading information, while the arrangement with BoA
does and allows the trust relationship to be used for both email and
trading.

As a believer in the thinner client, a (local and possibly trusted) network
based resource can perform this task more efficiently than locating it on
the client.  And we can argue whether it is more vulnerable to denial of
service attacks or not.  But since the validation of the discovered path
will always remain a client function, we would only be vulnerable to denial
attacks.

-----Original Message-----
From: Frank O'Dwyer <[email-masked]>
To: Alan Lloyd <[email-masked]>
Cc: Dave Horvath <[email-masked]>; [email-masked] <[email-masked]>
Date: Saturday, September 05, 1998 9:12 AM
Subject: Re: path development complexity (was Re: What the straw poll mean
s)

>Alan Lloyd wrote:
>> I have a few views in that certs must be supported by mutually
>> authenticated distributed X.500 directory systems otherwise 509 based
>> systems just  wont scale and provide the commercial utilitity as
>> demanded by global EC directed organisations. Not having this foundation
>> - one just drops into all sorts of operational cost, scaling and
>> efficiency holes.
>
>What I am talking about is not the underlying retrieval efficiency,
>but rather the cost of total wrong-turns in the overall search, e.g:
>
> 10:15 Developing a path to verify certificate for "Joe's Server,
>NY"
> 10:15 Retrieving cross-certificates for "Keys R Us"
> 10:16 Retrieving cross-certificates for "Keys R Us Too"
> 10:17 Retrieving cross-certificates for "Barcelona CA"
> 10:18 Retrieving cross-certificates for "Spanish Bank"
> CARRIER LOST
>
>Users just love that browser "stop" button, and so any verification
>process that can't complete in a second or so is broken (my
>opinion).
>
>Throwing a meatier directory and/or caches (as someone else
>suggested) at it doesn't help if finding just one path involves
>trawling the world for hundreds of names. That is why I think it
>would be better if the certificates themselves contained positive
>guidance as to where to go next, or if cross-cert scenarios that
>lead to vague searches could be identified and discouraged. For
>example, maybe name constraints could be used as clues to guide path
>building. As things stand, content like basic constraints just tells
>you where *not* to search. That seems to leave building in
>heuristics, and hoping that working down from your trusted root(s)
>and/or up from the end-entity cert(s), you somehow meet in the
>middle and terminate in some reasonable time -- something that is by
>no means guaranteed.
>
>Maybe I have missed something obvious here - but I think this could,
>given time, turn out to be a showstopper scalability issue if it is
>not addressed early.
>
>Cheers,
>Frank O'Dwyer.
>

Date: Sat, 05 Sep 1998 12:44:06 +0100
From: "Frank O'Dwyer" <[email-masked]>
To: Alan Lloyd <[email-masked]>
CC: Dave Horvath <[email-masked]>, [email-masked]
Subject: Re: path development complexity (was Re: What the straw poll mean s)
Sender: [email-masked]

Alan Lloyd wrote:
> I have a few views in that certs must be supported by mutually
> authenticated distributed X.500 directory systems otherwise 509 based
> systems just  wont scale and provide the commercial utilitity as
> demanded by global EC directed organisations. Not having this foundation
> - one just drops into all sorts of operational cost, scaling and
> efficiency holes.

What I am talking about is not the underlying retrieval efficiency,
but rather the cost of total wrong-turns in the overall search, e.g:

 10:15 Developing a path to verify certificate for "Joe's Server,
NY"
 10:15 Retrieving cross-certificates for "Keys R Us"
 10:16 Retrieving cross-certificates for "Keys R Us Too"
 10:17 Retrieving cross-certificates for "Barcelona CA"
 10:18 Retrieving cross-certificates for "Spanish Bank"
 CARRIER LOST

Users just love that browser "stop" button, and so any verification
process that can't complete in a second or so is broken (my
opinion).

Throwing a meatier directory and/or caches (as someone else
suggested) at it doesn't help if finding just one path involves
trawling the world for hundreds of names. That is why I think it
would be better if the certificates themselves contained positive
guidance as to where to go next, or if cross-cert scenarios that
lead to vague searches could be identified and discouraged. For
example, maybe name constraints could be used as clues to guide path
building. As things stand, content like basic constraints just tells
you where *not* to search. That seems to leave building in
heuristics, and hoping that working down from your trusted root(s)
and/or up from the end-entity cert(s), you somehow meet in the
middle and terminate in some reasonable time -- something that is by
no means guaranteed.

Maybe I have missed something obvious here - but I think this could,
given time, turn out to be a showstopper scalability issue if it is
not addressed early.

Cheers,
Frank O'Dwyer.

Date: Sat, 05 Sep 1998 13:32:45 +0200
To: WHenry <[email-masked]>
From: Patrik Nilsson <[email-masked]>
Subject: RE: Heads Up - Historic digital signing ceremony
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

The signed communiqué, the certificates, etc, are available at:
http://www.baltimore.ie/clintonvisit98/communique.html

Seems like there's a mime type problem on the web server though. The certs
are typed as ca-certs, leading to strange results when installing them in
Communicator.

Patrik

At 07:48 PM 98-09-04 , WHenry wrote:
> I wonder what President Clinton did with the smartcard afterwards...
>Can anyone add info on the nature of this PKI? Was there cross
>certification, or a single CA?
>
> Bill Henry
>> -----Original Message-----
>> From:	Kurn, David 
>> Sent:	Friday, September 04, 1998 12:43 PM
>> To:	[email-masked]
>> Subject:	RE: Heads Up - Historic digital signing ceremony
>> 
>> I wonder if the President obtained an export license for this technology.
>> I
>> think crypto devices (such as smart cards) could be subject to ITAR.
>> 
>> David Kurn
>> Compaq Computers
>> 
>> > -----Original Message-----
>> > From:	Bill Brice [SMTP:[email-masked]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[email-masked]
>> > Subject:	Heads Up - Historic digital signing ceremony
>> > 
>> > While the bits are flying on the LDAP debate, I 
>> > thought the list should know that a historic 
>> > milestone took place today (Friday 9/4) in the
>> > E-commerce/X.509 world.
>> > 
>> > President Clinton and the Irish Prime Minister
>> > signed a joint communiqué on E-commerce in Dublin.
>> > What was significant was not the communiqué but the
>> > fact that both heads of state signed the document
>> > digitally using X.509 technology. The private keys
>> > were held on smartcards issued to each head of
>> > state. This is the first instance of an 
>> > international agreement being digitally signed.
>> > 
>> > It's nice to see that this work 
>> > is actually showing up in the real
>> > world in a significant way.
>> > 
>> > OK - keep voting!
>> > 
>> > Bill Brice, Chief PKI Architect
>> > International DataTrust
>> > 
>> > P.S. Congratulations to Baltimore Technologies for
>> > pulling this off. It will move the PKIX world forward.
> 

Date: Fri, 4 Sep 1998 17:21:49 -0800
To: [email-masked]
From: Paul Ma <[email-masked]>
Subject: FOR Option2
Sender: [email-masked]

Hi,

I would put my 2 cents in for choosing option 2 in the latest straw poll on
certificate attributes used to store CA certificate.

Paul

From: "Surendra Reddy" <[email-masked]>
To: <[email-masked]>
Subject:  For option 2
Date: Fri, 4 Sep 1998 14:49:11 +0100
Importance: Normal
Sender: [email-masked]

From: "PACHL, Jan" <[email-masked]>
To: "'WHenry'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 16:22:33 -0500
Sender: [email-masked]

The press release about the event and the system used is at
http://www.baltimore.ie/news/press/pr980904.html

Jan Pachl

>----------
>From: 	WHenry[SMTP:[email-masked]]
>Sent: 	Friday, September 04, 1998 1:48 PM
>To: 	'Kurn, David'
>Cc: 	[email-masked]'
>Subject: 	RE: Heads Up - Historic digital signing ceremony
>
> I wonder what President Clinton did with the smartcard afterwards...
>Can anyone add info on the nature of this PKI? Was there cross
>certification, or a single CA?
>
> Bill Henry
>> -----Original Message-----
>> From:	Kurn, David 
>> Sent:	Friday, September 04, 1998 12:43 PM
>> To:	[email-masked]
>> Subject:	RE: Heads Up - Historic digital signing ceremony
>> 
>> I wonder if the President obtained an export license for this technology.
>> I
>> think crypto devices (such as smart cards) could be subject to ITAR.
>> 
>> David Kurn
>> Compaq Computers
>> 
>> > -----Original Message-----
>> > From:	Bill Brice [SMTP:[email-masked]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[email-masked]
>> > Subject:	Heads Up - Historic digital signing ceremony
>> > 
>> > While the bits are flying on the LDAP debate, I 
>> > thought the list should know that a historic 
>> > milestone took place today (Friday 9/4) in the
>> > E-commerce/X.509 world.
>> > 
>> > President Clinton and the Irish Prime Minister
>> > signed a joint communiqué on E-commerce in Dublin.
>> > What was significant was not the communiqué but the
>> > fact that both heads of state signed the document
>> > digitally using X.509 technology. The private keys
>> > were held on smartcards issued to each head of
>> > state. This is the first instance of an 
>> > international agreement being digitally signed.
>> > 
>> > It's nice to see that this work 
>> > is actually showing up in the real
>> > world in a significant way.
>> > 
>> > OK - keep voting!
>> > 
>> > Bill Brice, Chief PKI Architect
>> > International DataTrust
>> > 
>> > P.S. Congratulations to Baltimore Technologies for
>> > pulling this off. It will move the PKIX world forward.
>

From: "Salmond, Kent" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:57 -0700 
Sender: [email-masked]

From: "Smith, David" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 13:56:51 -0700 
Sender: [email-masked]

Date: Fri, 04 Sep 1998 20:24:15 +0100
To: "[email-masked]" <[email-masked]>
From: John Hughes <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

 -------------------------------------------------------------------
| John Hughes             [email-masked]                 |
| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |
|                         Home Fax No:           +44(0)1525 380161  |
|                         Main Office Tel:       +44(0)181 876 8666 |
| www.entegrity.com       Mobile:                +44(0)468 055070   |
 ------------------------------------------------------------------- 

From: Bill Brice <[email-masked]>
To: "'Kurn, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 14:16:44 -0500 
Sender: [email-masked]

That's very interesting. Being familiar with the product
used, I'd bet the keys were RSA-1024 bit implemented
with all non-US strong crypto technology (other than
RSA). Hmmm. Interesting precedent!

> -----Original Message-----
> From: Kurn, David [mailto:[email-masked]]
> Sent: Friday, September 04, 1998 11:43 AM
> To: [email-masked]
> Subject: RE: Heads Up - Historic digital signing ceremony
> 
> 
> I wonder if the President obtained an export license for this 
> technology.  I
> think crypto devices (such as smart cards) could be subject to ITAR.
> 
> David Kurn
> Compaq Computers

Reply-To: <[email-masked]>
From: "JF Sauriol" <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:31:02 -0400
Importance: Normal
Sender: [email-masked]

From: Larry Shomo <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:52 -0400
Sender: [email-masked]

Lawrence P. Shomo
Vice President

********************************
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia, 22102-3305
(703) 848-0883, x202 (Phone)
(703) 848-0960 (Fax)
[email-masked] (Email)

********************************

From: WHenry <[email-masked]>
To: "'Kurn, David'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 13:48:00 -0400 
Sender: [email-masked]

 I wonder what President Clinton did with the smartcard afterwards...
Can anyone add info on the nature of this PKI? Was there cross
certification, or a single CA?

 Bill Henry
> -----Original Message-----
> From:	Kurn, David 
> Sent:	Friday, September 04, 1998 12:43 PM
> To:	[email-masked]
> Subject:	RE: Heads Up - Historic digital signing ceremony
> 
> I wonder if the President obtained an export license for this technology.
> I
> think crypto devices (such as smart cards) could be subject to ITAR.
> 
> David Kurn
> Compaq Computers
> 
> > -----Original Message-----
> > From:	Bill Brice [SMTP:[email-masked]]
> > Sent:	Friday, September 04, 1998 9:12 AM
> > To:	[email-masked]
> > Subject:	Heads Up - Historic digital signing ceremony
> > 
> > While the bits are flying on the LDAP debate, I 
> > thought the list should know that a historic 
> > milestone took place today (Friday 9/4) in the
> > E-commerce/X.509 world.
> > 
> > President Clinton and the Irish Prime Minister
> > signed a joint communiqué on E-commerce in Dublin.
> > What was significant was not the communiqué but the
> > fact that both heads of state signed the document
> > digitally using X.509 technology. The private keys
> > were held on smartcards issued to each head of
> > state. This is the first instance of an 
> > international agreement being digitally signed.
> > 
> > It's nice to see that this work 
> > is actually showing up in the real
> > world in a significant way.
> > 
> > OK - keep voting!
> > 
> > Bill Brice, Chief PKI Architect
> > International DataTrust
> > 
> > P.S. Congratulations to Baltimore Technologies for
> > pulling this off. It will move the PKIX world forward.

Date: Fri, 04 Sep 1998 10:17:26 -0700
Subject: Re: Digital signature and non-repudiation key usage bits
From: "Aram Perez" <[email-masked]>
To: Stefan Santesson <[email-masked]>, bob jueneman <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Bob and Stefan:

>At 06:42 PM 9/2/98 -0600, Bob Jueneman wrote:
><snip>
>>>I suggest that we stick to the standardized definitions of the key usage
>>>bits and leave
>>>policy issues out of a common certificate profile.
>>
>>If there were any sense of the community as to what these definitions really
>>mean, or ought to mean, we would probably not be having this discussion.
>>Otherwise I would agree with you.
>>>
>>>non-repudiation is according to standard selected by the NR bit, not NR in
>>>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>>>other than non-repudiation are allowed for the key.

Is non-repudiation a mechanism or a service?

>>
>>I believe that is exactly the issue. Are you suggesting that NR plus DS
>should not
>>be allowed?  Why?
>
>No I do not. I do suggest that such decision is up to local policy. But
>there will be some policies where this combination will not be allowed, but
>I think you agree to that.

My problem with this is that to provide "digital" non-repudiation, you have to
"sign" something with a digital signature. I understand that the key usage field
is very overloaded, so I'll probably have to live with it, but I do not agree or
like it.

>
>The important thing is that I suggest that the NR bit and DS bit has
>separate meaning and that they should be set independently to specify DS,
>NR or both.
>
>The vague definition of the NR bit is a problem, I agree to that.

YES!!

>
>If I were to define some distinguishing property of the NR bit that would be:
>
>   Non repudiation denotes services constructed in such way that:
>   1) The signature provides proof of the integrity and 
>      origin of data - both in an unforgeable relationship - which can be 
>      verified by any third party at any time.[X.509 / ISO 9594-8]
>   2) The signature is applied to a message where the signatory is capable
>      of, and required to, accept responsibility for the message content 
>      before signing.

But NR is set in the certificate (i.e. the public key) and does not tell you
whether the signatory (who is using the private key) actually was capable of
accepting responsibility.

>   3) The signatory's liability for signing the message can be concluded
>      from the signed message itself, possibly within a well known and agreed 
>      context that can be verified by any third party at any time.
>
>This definitions rules out any signed logon ticket or other data
>authentication mechanisms where the signature says "this message wasn't
>changed" instead of "I take full responsibility for the message content".

You do not need a digital signature to tell you "this message wasn't changed".
CRCs, LRCs, checksums, etc have been used for this longer that I've been alive.
You use digital signature when you want to know "this message wasn't changed"
AND "this message came from the reported sender".

>
>But since this is not defined by the bit (which I regret) the way to go
>will be for the CA to include this in it's published certificate policy.

I doubt whether a CA is going to take responsibility and liability for something
it has no control over. The CA does not know what applications and crypto APIs
the owner of the private key is using.

>
>I can't see any other way for now when utilizing the existing standard. I
>would not object though to a defect report to get this into the standard.

And I am willing to help (or lead) in this effort.

>
>In the new proposed work item, however, regaring a profile for
>non-repudiation certificates supporting legal acceptance of digital
>signatures I will try to get this definition in.
>
>Would you support it?

I would be glad to help and support it.

Regard,
Aram Perez
Apple Computer, Inc.

From: "Kurn, David" <[email-masked]>
To: [email-masked]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 09:43:21 -0700 
Sender: [email-masked]

I wonder if the President obtained an export license for this technology.  I
think crypto devices (such as smart cards) could be subject to ITAR.

David Kurn
Compaq Computers

> -----Original Message-----
> From:	Bill Brice [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 9:12 AM
> To:	[email-masked]
> Subject:	Heads Up - Historic digital signing ceremony
> 
> While the bits are flying on the LDAP debate, I 
> thought the list should know that a historic 
> milestone took place today (Friday 9/4) in the
> E-commerce/X.509 world.
> 
> President Clinton and the Irish Prime Minister
> signed a joint communiqué on E-commerce in Dublin.
> What was significant was not the communiqué but the
> fact that both heads of state signed the document
> digitally using X.509 technology. The private keys
> were held on smartcards issued to each head of
> state. This is the first instance of an 
> international agreement being digitally signed.
> 
> It's nice to see that this work 
> is actually showing up in the real
> world in a significant way.
> 
> OK - keep voting!
> 
> Bill Brice, Chief PKI Architect
> International DataTrust
> 
> P.S. Congratulations to Baltimore Technologies for
> pulling this off. It will move the PKIX world forward.

From: Peter Sylvester <[email-masked]>
Date: Fri, 4 Sep 1998 18:43:29 +0200
To: [email-masked], [email-masked], [email-masked]
Subject: RE: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

I have some problem to decrpyt the following. 
Is the following picture a correct description?

- A CA1 creates a certificate for another CA2.
- To publish this information, CA1 puts something in its 
  publishing service, e.g.; its directory entry.
- CA1 can inform by whatever means CA2 that this had happened. 
- If CA2 is convinced that CA1 is really CA1 or maybe even if not,
  CA2 then can put something it its publishing service, e.g.; its directory entry.

It seems to me that first the requirement of a path resolver vs a publication
service should be defined in a neutral way. What does a path resolver need
from the publication service of one CA, and in which way can a publication
service help a resolver.    

> Do you mean though that if CA1 issues a certificate to CA2 that rather
> than requiring that same certificate to be present in the reverse
> element of the crossCertificatePair attribute of CA1's directory as well
> as requiring that same certificate to be present in the forward element
> of the crossCertificatePair attribute of CA2's directory entry, you want
> to require that it be present in the directory entry of CA2, the subject
> CA as a forward value of the crossCertificatePair and optionally allow
> CA1 to populate its reverse element with the same certificate?
> 

Date: Fri, 04 Sep 1998 12:18:06 -0400
To: [email-masked]
From: "Erin Connor" <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

--------------------------------------------------------------------------
Erin Connor                             EWA-Canada Ltd.
Voice:  +1 (613) 230-6067 Ext 234       Suite 1600 - 275 Slater Street
Fax:    +1 (613) 230-4933               Ottawa, Ontario, Canada  K1P 5H9
mailto:[email-masked]         	http://www.ewa-canada.com

** Visit the CanCERT website at  http://cancert.ca ***
--------------------------------------------------------------------------

From: Bill Brice <[email-masked]>
To: [email-masked]
Subject: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 11:11:44 -0500 
Sender: [email-masked]

While the bits are flying on the LDAP debate, I 
thought the list should know that a historic 
milestone took place today (Friday 9/4) in the
E-commerce/X.509 world.

President Clinton and the Irish Prime Minister
signed a joint communiqué on E-commerce in Dublin.
What was significant was not the communiqué but the
fact that both heads of state signed the document
digitally using X.509 technology. The private keys
were held on smartcards issued to each head of
state. This is the first instance of an 
international agreement being digitally signed.

It's nice to see that this work 
is actually showing up in the real
world in a significant way.

OK - keep voting!

Bill Brice, Chief PKI Architect
International DataTrust

P.S. Congratulations to Baltimore Technologies for
pulling this off. It will move the PKIX world forward.

From: "Robert Klerer" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: path development complexity (was Re: What the straw poll means)
Date: Fri, 4 Sep 1998 11:52:02 -0400
Sender: [email-masked]

As pkix evolves and is implemented, the task of finding an appropriate trust
path must be addressed.  As Dave has stated, it is not going to be easy if
the trust islands of today start to cross certify for some applications.  It
is my belief that putting such processing on the client will cause problems
from both then network, processor and application development perspective.
A (shared) trusted responder that will be a repository and cache of
certificates that has the capability to do path discovery would make such a
process more efficient and manageable.

But the client must always validate any path provided by the responder.

The path discovery process as so described in the drafts will require
knowledge of application specific extensions.  This is the big problem and
should be a topic of discussion.

-----Original Message-----
From: Frank O'Dwyer <[email-masked]>
To: Dave Horvath <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, September 03, 1998 11:57 PM
Subject: path development complexity (was Re: What the straw poll means)

>Dave Horvath wrote:
>>         We are back the problem we raised earlier.  Clients that attempt
to
>> efficiently develop a path from the end entity to the trusted root must
>> explore 'n' paths (worst case scenario)  prior to finding the correct
>> one with option 2.
>
>This is not on the topic of the straw poll, but I was wondering if
>anyone has really looked into how difficult path development can get in
>a full-blown and well-connected global PKI? It seems to me that the real
>worst case scenario has you following cross-certificates until you have
>downloaded all the cross-certificates in the world. It would not have to
>get that bad before it was a serious problem.
>
>A few things would help prune the search (like the depth you are willing
>to search to, constraints within the certificates themselves), but still
>in general it has the potential to get truly nasty. Unless I have missed
>something, there are no positive hints in the certificates that would
>guide path development (perhaps there should be? There is a resemblance
>to the "travelling salesman" problem here, and it would certainly be
>ironic if building a path turned out to be as hard as factoring.:)
>
>Anyone looked at this? If it is a problem, then it might be reasonable
>to give recommendations on using constraints (or something else) in
>order to encourage the creation of cross-certificates that are
>"path-development friendly", and in order to discourage scenarios that
>lead to directory search explosions.
>
>Apologies if I am re-hashing something that has already been discussed
>here.
>
>Cheers,
>Frank O'Dwyer.
>

From: "Power, Michael: LEG" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:24:33 -0400 
Sender: [email-masked]

Date: Fri, 04 Sep 1998 11:03:15 -0400
From: Pamela Grannum <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: [email-masked]
To: [email-masked]
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:13:27 -0400
Sender: [email-masked]

My vote is for Option 2 of the LDAP schema companion paper.

Edmond P. van Hees
GOC PKI Security Engineer
telephone: 613-991-7413 
Fax: 613-991-7455
E-Mail:  [email-masked]

Date: Fri, 04 Sep 1998 10:37:54 -0700
To: [email-masked]
From: "Steve O'Neil" <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Reply-To: "Mark Scherling" <[email-masked]>
From: "Mark Scherling" <[email-masked]>
To: <[email-masked]>
Subject: option 2
Date: Fri, 4 Sep 1998 10:33:53 -0400
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Sharon Boeyen <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:30:00 +0100
Sender: [email-masked]

Santosh
re this comment to Denis message:

	The argument was made very clear in terms of the original X.509
standard requiring the attribute to be populated whereas
croosCertificatePair need not be.  In addition, a technical argument was
made why the current text goes against the original X.509 and a poor
technical solution.

------
I hope we don't go far down this road. At best I think X.509 is unclear
and ambiguous on this issue. Those present at the January meeting of the
X.509 group that discussed the defect report (including at least 4 of us
who have participated directly in that standard activity since at least
1988) had a long discussion of exactly this point and agreed that
additional text was required to resolve the ambiguity around the use of
these attributes. The result of that discussion was the draft resolution
of the defect report prepared for ballot (with which the current
Internet Draft is aligned), the content which is of course still subject
to change as described earlier.

There are so many arguments on both sides of this that I believe no one
can clearly claim conformance as a differentiator in the options for the
straw poll. 

Yes the crossCertificatePair attribute was optional and still is in the
pkiCA object class, but the reason for that is that a CA can exist
without ever having certified another CA or being certified by another
CA therefore it MUST be an optional attribute, however if present, its
contents must be clearly defined. You could use the same argument to say
that cACertificate was never intended to hold certs issued from one CA
to another - again because a CA can exist legitimately without ever
having a relationship with another CA and the cACertificate attribute
was mandatory.  Also, if you read the 2nd paragraph following the asn.1
for the EXTENSION in clause 8 of X.509, you see use of forward and
reverse certificates being discussed in path development and there is no
precise definition of what goes where in the directory entries. That
text has been there since 1988 as well. and the list of references that
can be used for both sides of the argument go on and on and on. 

The outcome from PKIX discussion will hopefully be available to feed
into the 509 process to clarify the standard.

From: Rene Eberhard <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 15:06:27 +0100
Sender: [email-masked]

Best regards Rene

From: Sharon Boeyen <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:02:50 +0100
Sender: [email-masked]

Santosh, a question for clarification - tied to Denis' message also:

I definitely agree that unilateral certification is valid and I don't
think any of us have been saying that bilateral certification between a
pair of CAs is mandatory. If that needs clarification, we can certainly
add text along those lines to option 2 - Stefan had some good proposals.

Do you mean though that if CA1 issues a certificate to CA2 that rather
than requiring that same certificate to be present in the reverse
element of the crossCertificatePair attribute of CA1's directory as well
as requiring that same certificate to be present in the forward element
of the crossCertificatePair attribute of CA2's directory entry, you want
to require that it be present in the directory entry of CA2, the subject
CA as a forward value of the crossCertificatePair and optionally allow
CA1 to populate its reverse element with the same certificate?

If that's what you mean, I can accept that position as well.

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 4, 1998 9:19 AM
> To: 	'Bill Burr'; Santosh Chokhani
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> I agree that option 2 is compromise.  Actually, as you know I had
> proposed it.
> 
> I would change one thing in it.  I would not mandate the population of
> reverse component of the crossCertificatePair.
> 
> > 
> > Bill Burr
> 

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Sharon Boeyen <[email-masked]>
Cc: [email-masked], Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:45:36 -0400
Sender: [email-masked]

Comments in line.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 1:03 PM
> To:	Sharon Boeyen
> Cc:	[email-masked]; 'Santosh Chokhani'
> Subject:	Re: What the straw poll means
> 
> Sharon, 
> 
> > The "two buckets" is exactly what I was trying to avoid in the
> > earlier debate on this topic, however I believe that the single 
> > bucket option was rejected in the Chicago meeting. 
> 
> It was a pity that you could not attend the Chicago meeting. 
> "rejected" may be a strong word. During the straw poll, I did not 
> raised my hand for any of the three options for the following good 
> reasons:
> 
> 1) I had three weeks of holidays one week ahead of the meeting, :-)
> 2) When I came back, I had 470 E-mails waiting for me,
> 3) I completely skipped the thread on the LDAP schema, :-(
> 
> As a result I could not understand from the discussion what the topic
> was and so I abstained. I would guess that I was not the single one in
> that position. There was some support for it anyway, so I do not
> understand why the straw poll is not on the three options but instead
> only on two options.
> 
> > The single bucket option is the
> > text which is currently in the Internet Draft. With that text, 
> > all self signed (or self issued certificates) were to be placed 
> > in the cACertificate attribute and all certificates issued by 
> > one CA to a different CA were put in the crossCertificatePair 
> > attribute. 
> 
> This was pretty nice and simple ! If I were to open the bunch of
> messages, maybe I could understand why this is not acceptable.
> 
	The argument was made very clear in terms of the original X.509
standard requiring the attribute to be populated whereas
croosCertificatePair need not be.  In addition, a technical argument was
made why the current text goes against the original X.509 and a poor
technical solution.

> > Depending on the particular path development algorithm being 
> > used by a relying party, directory search tools, especially 
> > when we evolve to LDAPv3 could be used to filter the content 
> > of the forward and or reverse elements of that SINGLE attribute 
> > and provide the relying party with the set of certificates of 
> > interest to that particular relying party.
> 
> Indeed. []    Again the approach is consistent with the text, spirit
> and intent of X.509 and never hurts, but may help path development. 
>  
> > I still believe that this is the best solution because the relying
> > party systems are the ones that know which certs are of interest 
> > to them, 
> 
> I agree with you.
> 
> > not the CA that happened to issue the certs, especially in the 
> > post PEM world where any CA could legitimately have certs issued 
> > for it by several CAs.
>  
> > My strong support for Option 2 in the straw poll is because 
> > the above was rejected by the meeting and I see Option 2 as 
> > a workable compromise ONLY because there is a complete set of 
> > certs in a single attribute and relying parties can do what is 
> > of interest to them without knowing the definition of domain 
> > which each individual CA happens to use. For self contained 
> > environments wanting to make use of a CA or set of CAs certs
> > issued within some locally defined domain, this is still possible.
> 
> Let me take a look at option 1 and say why it is not acceptable ... 
> because it imposes a model of trust that is too specific.
> 
> General comment: The notion of "domain" has never been introduced
> before and since the understanding of a domain is "purely a matter 
> of local policy" there is no chance that the requester understands 
> what it means - unless we are in a close environment. 
> 
> I believe that this feature is being introduced to be used in close
> environments for some "good" reasons. The text should explain these
> "good" reasons otherwise readers of the document will ignore for ever
> the rational.  
> 
> PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
> OPTION 1:
> ----------------
> The cACertificate attribute, held in a particular CA's directory
> entry, shall be used to store certificates issued to this CA by CAs 
> in the same domain as this CA. 
> 
>      When the notion of domain does not exists, then this will 
>      be empty.
> 
	[]  Agreed. 

> In addition, the cACertificate attribute shall be used to
> store self-issued certificates.
> 
>      This is fine.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  
> 
>      I have a problem here. Cross certification does not mean mutual 
>      cross certification. A CA can cross-certify another CA without 
>      any knowledge from the CA being cross certified. Even if the CA
>      got the knowledge of it, that CA would not like to place that 
>      certificate in that entry. Let us pick an example: a CA from 
>      the Banana Republic of Baracuda is providing a certificate for 
>      the NIST. I do not think that the NIST will necessarilly place
>      that certificate in his entry. 
> 
	[]Denis: THIS IS NOT AN OPTION 1 ISSUE.  THE CURRENT TEXT,
OPTION 1 and OPTION 2 ALL HAVE THE SAME DRAWBACK.  

> Optionally, the reverse element of the crossCertificatePair attribute,
> 
> held in a particular CA's directory entry, may contain certificates 
> issued by this CA to CAs in other domains.
> 
>      I have a problem here with the word "Optionally" : if the 
>      previous element is not there, then I cannot place an element 
>      here. This means that if CA 1 wants to recognize CA 2, 
>      then CA 2 MUST also recognize CA 1. This mandates mutual cross
>      certification. I do not think that we have ever mandated 
>      *mutual* cross certification in PKIX-1.
> 
	]My interpretation is  different.  You can always populate the
reverse attribute even if the forward is absent.  I will be glad to
clarify the text.  Please also note that this is an issue for current
ldapv2 text, Option 1 and for option 2.

>      Thus OPTION 1 is NOT acceptable and this has nothing to do with 
>      performance or path development.
> 
> In the case of V3 certificates, none of the above CA certificates may
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> OPTION 2:
> -------------
> The crossCertificatePair attribute, held in a particular CA's
> directory entry, shall be used to store all certificates issued 
> by this CA to other CAs, as well as certificates issued 
> for this CA by other CAs. Values held in the forward element are 
> certificates issued for this CA by other CAs, while values 
> in the reverse element are certificates issued by this CA for
> other CAs. 
> 
>      I would interpret the text as mandating to store the reverse 
>      element and optionally the forward element. I would instead
>      allow to store only the forward element, only the reverse 
>      element or both. 
> 
>      Hence the OPTION 2 is NOT acceptable either and this has 
>      nothing to do with performance or path development.
> 
> The text should be corrected and be something like:
> 
>      The crossCertificatePair  attribute,  held  in  a  particular
> CA's
>      directory  entry,  may be used to store certificates issued by
> this
>      CA to other CAs, as well as certificates  issued  for  this  CA
> by
>      other  CAs.  Values  held  in  the forward element are
> certificates
>      issued for this CA by other CAs, while values in the  reverse
> ele-
>      ment  are certificates issued by this CA for other CAs. Either
> cer-
>      tificate, if present,  may be used in  building  certificate
> paths
>      for  validation  and  may  be published in the directory entries
> of
>      either CA or both.
> 
	[]  This is an acceptable compromise to me between option 1 and
option 2.  It does not mandate, but permits population of the
crossCertificatePair attribute components.

>  ... which is exactly what is in the original text !
> 
> The cACertificate attribute, held in a particular CA's directory
> entry, shall be used to store certificates issued to this CA by CAs 
> in the same domain as this CA. This set of certificates is a subset 
> of the values of the forward element of the crossCertificatePair 
> attribute in the same CA entry.
>  
> In addition, the cACertificate attribute shall beused to store
> self-issued certificates.  
> 
>      When there are no domains, and IF the text was corrected as 
>      indicated hereabove (i.e. back to the text of the original 
>      version) then we would be "compatible" with the previous 
>      text, but this is not the case. Did I understood correctly ?
> 
>      I believe that there are "good" resons to introduce the 
>      notion of "domain". Are these "good reasons" technical or 
>      commercial ? If they are technical then they SHALL be 
>      written in the document. But what about if they are 
>      "commercial" ?
> 
> For the time being, I can only vote for OPTION 0 (i.e. the original
> text) !
> 
> Denis
> 
> -- 
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Ryan Moats" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Let's try to understand the real issue (was... RE: What the straw poll means)
Date: Fri, 4 Sep 1998 08:26:03 -0500
Importance: Normal
Sender: [email-masked]

>
> Hi Ryan,
>
> > | If this CA's definition of domain and my definition of domain do not
> > | coincide exactly (and why should they, since in general this CA and
> > I
> > | have no pre-established relationship?), then this sorting performed
> > by
> > | the CA is not merely useless to me, it is actually an explicit
> > | disadvantage (because the proponents of option 1 are recommending
> > that
> > | all the intra-domain certificates be examined *before* the
> > inter-domain
> > | certificates are examined, leading to worst-case path-construction
> > times
> > | for what may turn out to be a common scenario).
> >
> > I don't see that falling out of the Option 1 text as I read the
> > straw poll message.  If such is the case, then I would say that text
> > should be present.
> >
> Dave Horvath's message to Bob Jueneman earlier today said the following:
>
>     "I feel that the definition of domain is a local policy and that CAs
> should be free to define it as they wish.   Clients  that search/read
> CAs entries and obtain the values from both the cACertificate and
> crossCertificatePair attributes can explore the values in the
> cACertficate attribute first.  If a path to the trusted root is found,
processing
> stops. If not, they can explore the crossCertificatePair attribute.  Using
this
> algorithm CAs can define their domain and post each of their CA
> certificates to one attribute or the other.  The only adverse affect will
be
> efficiency in path development  on the client side if the CA does not
carefully
> select intra or inter domain."
>
> This was also mentioned at the meeting in Chicago.

Hmm.  I was at the meeting in Chicago (both sessions) and I don't remember
hearing
that.  However, I claim that the whole argument is implementation and
therefore out
of scope for this discussion.

> > | Note that there will be special circumstances in which one
> > definition of
> > | domain will be understood throughout a given environment (e.g., the
> > | strict hierarchy of CAs has been cited in previous posts on this
> > topic).
> > | In such cases there is a clear efficiency advantage to be gained in
> > path
> > | construction.  This is why option 2 is the perfect compromise:  for
> > such
> > | environments relying parties need only retrieve the n1 < n
> > certificates
> > | that they *know* will be useful to them.  Option 2 therefore meets
> > the
> > | needs of the general case as well as the special case, while
> > | simultaneously guaranteeing interoperability of two installed bases
> > | which would otherwise have no hope of interoperating today.
> >
> > Stop. Here's where I really fall off the wagon. How does the relying
> > party
> > retrieve ONLY the n1 certificates that they know will be useful to
> > them for
> > a CA?
> >
> If the relying party knows that its definition of domain matches that of
> the CA exactly, then it can simply retrieve all certificates in the
> cACertificate attribute (rather than all certificates in the
> crossCertificatePair attribute) in option 2.  This is n1 rather than n.
>
> Carlisle.

So what your saying then is that Option 2 is better because of the
interopability
issue (I can apply all the rest of the arguments to both cases since I don't
see
any difference in the use of cACertificate in both options)

Ryan

From: Santosh Chokhani <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:19:29 -0400
Sender: [email-masked]

I agree that option 2 is compromise.  Actually, as you know I had
proposed it.

I would change one thing in it.  I would not mandate the population of
reverse component of the crossCertificatePair.

> -----Original Message-----
> From:	Bill Burr [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 9:21 AM
> To:	Santosh Chokhani
> Cc:	[email-masked]
> Subject:	RE: What the straw poll means
> 
> At 08:11 AM 9/4/98 -0400, you wrote:
> 
> Santosh,
> 
> Are you saying that you agree that option 2 is the "perfect
> compromise?"  
> 
> >Stefan:
> >
> >I agree with every thing you say in this mail message,
> >
> >> -----Original Message-----
> >> From:	Stefan Santesson [SMTP:[email-masked]]
> >> Sent:	Friday, September 04, 1998 7:20 AM
> >> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
> >> Cc:	Santosh Chokhani
> >> Subject:	RE: What the straw poll means
> 
> <snip>
> 
> >>And since
> >> this
> >> guidance by the CA may be useful in many situations, I consider
> option
> >> 2 as
> >> the perfect compromise.
> >> 
> >> /Stefan
> >> 
> >> 
> >> 
> >> 
> >> 
> Regards,
> Bill Burr

Date: Fri, 04 Sep 1998 09:20:36 -0400
To: Santosh Chokhani <[email-masked]>
From: Bill Burr <[email-masked]>
Subject: RE: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

At 08:11 AM 9/4/98 -0400, you wrote:

Santosh,

Are you saying that you agree that option 2 is the "perfect compromise?"  

>Stefan:
>
>I agree with every thing you say in this mail message,
>
>> -----Original Message-----
>> From:	Stefan Santesson [SMTP:[email-masked]]
>> Sent:	Friday, September 04, 1998 7:20 AM
>> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
>> Cc:	Santosh Chokhani
>> Subject:	RE: What the straw poll means

<snip>

>>And since
>> this
>> guidance by the CA may be useful in many situations, I consider option
>> 2 as
>> the perfect compromise.
>> 
>> /Stefan
>> 
>> 
>> 
>> 
>> 
Regards,

Bill Burr

From: "Miklos, Sue A." <[email-masked]>
To: "'Carlisle Adams'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Let's try to understand the real issue (was... RE: What the straw poll means)
Date: Fri, 4 Sep 1998 08:58:25 -0400
Sender: [email-masked]

I work in an environment where although the entire 'world' won't
need/want/have access to my directory system, I will be required to make
information available to a geographical disbursed, multinational, large
group of users.

Sandi

>----------
>From: 	Ambarish Malpani[SMTP:[email-masked]]
>Sent: 	Thursday, September 03, 1998 4:41 PM
>To: 	Carlisle Adams
>Cc: 	[email-masked]
>Subject: 	Re: Let's try to understand the real issue (was... RE: What the
>straw poll means)
>
>Hi Carlisle,
>    Is the expectation that everybody is directly accessing their
>CA's LDAP directory? I always thought that each orginazation would
>actually maintain its own LDAP directory and, therefore, be able
>to specify which CAs are preferred over others.
>
>    Are we really expecting people to share their directories with
>everyone in the world?
>
>Ambarish
>
>
>Carlisle Adams wrote:
>> 
>> Hi all,
>> 
>> I propose that we try (once again) to understand what the real issue is
>> here.
>> 
>> > ----------
>> > From:         Ryan Moats[SMTP:[email-masked]]
>> > Sent:         Thursday, September 03, 1998 12:14 PM
>> > To:   [email-masked]
>> > Cc:   [email-masked]
>> > Subject:      Retrieval efficiency herring? (was... RE: What the straw
>> > poll means)
>> >
>> > As somebody coming to the party late from the LDAP world, I don't see
>> > why
>> > the certificates need to be retrieved from two places.  An LDAP lookup
>> > of an
>> > object with a fairly simple filter (objectclass="*") will return all
>> > of the
>> > attributes associated with that object.  Therefore a single lookup
>> > will return
>> > both attributes, so I don't understand how retrieval efficiency is
>> > gained.
>> >
>> O.K., so we see that a single LDAP lookup can retrieve all certificates
>> (which, after careful enumeration, was found to be "n") in either option
>> 1 or option 2.
>> 
>> The claimed advantage of option 1 is that this retrieval gets me
>> certificates that are sorted into "intra-domain" and "inter-domain",
>> which can help in efficient path construction.  Let's think about this
>> for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
>> TRUSTED BY ME  (because if it was directly trusted by me, I would
>> already have a trusted copy of its public key and would not need
>> certificates in which it was the subject).  If it is not directly
>> trusted by me, then why would I necessarily trust it to do this sorting
>> in a way that is beneficial to my path construction needs?  How does it
>> know what *my* definition of "domain" is?  How does it know whether most
>> of my certificate validations will be "intra" its definition of domain
>> or "inter" its definition of domain?
>> 
>> If this CA's definition of domain and my definition of domain do not
>> coincide exactly (and why should they, since in general this CA and I
>> have no pre-established relationship?), then this sorting performed by
>> the CA is not merely useless to me, it is actually an explicit
>> disadvantage (because the proponents of option 1 are recommending that
>> all the intra-domain certificates be examined *before* the inter-domain
>> certificates are examined, leading to worst-case path-construction times
>> for what may turn out to be a common scenario).
>> 
>> Relying parties know what certificates they will be validating most
>> often, depending upon what particular activity they are engaged in at
>> the moment.  THAT defines the relying parties' "intra" and "inter"
>> domains.  CAs in the middle of a cert. path cannot possibly know this,
>> in general, so having THEM define a domain and sort certificates
>> according to that definition is really meaningless.
>> 
>> Note that there will be special circumstances in which one definition of
>> domain will be understood throughout a given environment (e.g., the
>> strict hierarchy of CAs has been cited in previous posts on this topic).
>> In such cases there is a clear efficiency advantage to be gained in path
>> construction.  This is why option 2 is the perfect compromise:  for such
>> environments relying parties need only retrieve the n1 < n certificates
>> that they *know* will be useful to them.  Option 2 therefore meets the
>> needs of the general case as well as the special case, while
>> simultaneously guaranteeing interoperability of two installed bases
>> which would otherwise have no hope of interoperating today.
>> 
>> The price of this panacea?  A few redundant certificates in the
>> Directory.  Is it really worth sacrificing the general- (and perhaps
>> common-) case scenario, as well as interoperability, in order to save a
>> few certificates and satisfy a particular special-case?  I haven't yet
>> heard any convincing arguments...
>> 
>> Carlisle.
>
>-- 
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect					         650.567.5457
>ValiCert, Inc.				        [email-masked]
>1215 Terra Bella Ave.		              http://www.valicert.com
>Mountain View, CA 94043-1833
>

From: Santosh Chokhani <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 08:11:19 -0400
Sender: [email-masked]

Stefan:

I agree with every thing you say in this mail message,

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 7:20 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
> Cc:	Santosh Chokhani
> Subject:	RE: What the straw poll means
> 
> At 08:48 PM 9/2/98 -0400, Santosh Chokhani wrote:
> <snip>
> >The way I look at the difference between the two options is that if
> >n=n1+n2 certificates are issued to a CA, option 1 says CA puts n1 in
> one
> >bucket and n2 in another.  Option 2 says put n in one bucket and n1
> in
> >another.  When you retrieve the two buckets (which you must for path
> >development efficiency), option 2 gives you n+n1 certificates and
> option
> >1 gives you exactly all n.
> 
> I tried to point out before that this is not the whole picture.
> 
> The CA is dealing with n CA certificates n=n1+n2+n3+n4 of the form:
> n1 = intra domain issued to other CA:s
> n2 = intra domain issued by other CA:s to this CA
> n3 = inter domain issued to other CA:s
> n4 = inter domain issued by other CA:s to this CA
> 
> Option 1 stores only n2+n3+n4
> (n2 in one bucket and n3+n4 in the other.)
> 
> Option 2 stores n1+2(n2)+n3+n4
> (n2 in one bucket and n1+n2+n3+n4) in the other)
> 
> As you see, n1 is left out of option 1 (according to text)
> You said then that it is not forbidden to store n1 (in option 1)
> in the cross certificate pair. I guess then that option 1 should
> changed-
> 
> from:
>   Optionally, the reverse element of the
>   crossCertificatePair attribute, held in a particular CA's directory
> entry,
>   may contain certificates issued by this CA to CAs in other domains.
> 
> to:
>   Optionally, the reverse element of the
>   crossCertificatePair attribute, held in a particular CA's directory
> entry,
>   may contain certificates issued by this CA to other CAs.
> 
> So if this is correct then what we are fighting about is only whether
> we
> should duplicate n2 (out of n1,n2,n3 and n4). To me it sounds
> reasonable to
> have the complete set of n1+n2+n3+n4 in one bucket and the n2 in the
> cACertificate attribute as a specific information for those who wants
> to
> have the CA:s guidance to define the inter domain subgroup. And since
> this
> guidance by the CA may be useful in many situations, I consider option
> 2 as
> the perfect compromise.
> 
> /Stefan
> 
> 
> 
> 
> 

To: [email-masked]
cc: Sharon Boeyen <[email-masked]>, [email-masked], "'Santosh Chokhani'" <[email-masked]>
Subject: Re: What the straw poll means 
Date: Fri, 04 Sep 1998 12:24:47 +0100
From: David Boyce <[email-masked]>
Sender: [email-masked]

Denis,

Your comments are helpful in pointing out flaws in the expression of the
two options, although these aren't at the heart of the debate.  

I have included a suggested text for the relevant part of Option 1
below.  It seems to me that similar adjustments would need to be made to
the Option 2 text.

As for the relative merits of options 1 and 2 from a functional point of
view, I am still taking time to listen and consider.  I wish there was
more information about the installed base requiring option 2.

Denis Pinkas writes:

>Let me take a look at option 1 and say why it is not acceptable ... 
>because it imposes a model of trust that is too specific.

Would you say that the modified text I suggest below imposes the same
constraint?  In other words, is your concern simply a matter of the
expression of option 1?

>PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
>OPTION 1:
>----------------
[snip]

>The forward element of the crossCertificatePair attribute, held in a
>particular CA's directory entry, shall be used to store certificates
>issued to this CA by CAs in other domains.  
>
>     I have a problem here. Cross certification does not mean mutual 
>     cross certification. A CA can cross-certify another CA without 
>     any knowledge from the CA being cross certified. Even if the CA
>     got the knowledge of it, that CA would not like to place that 
>     certificate in that entry. Let us pick an example: a CA from 
>     the Banana Republic of Baracuda is providing a certificate for 
>     the NIST. I do not think that the NIST will necessarilly place
>     that certificate in his entry. 

>Optionally, the reverse element of the crossCertificatePair attribute, 
>held in a particular CA's directory entry, may contain certificates 
>issued by this CA to CAs in other domains.
>
>     I have a problem here with the word "Optionally" : if the 
>     previous element is not there, then I cannot place an element 
>     here. This means that if CA 1 wants to recognize CA 2, 
>     then CA 2 MUST also recognize CA 1. This mandates mutual cross
>     certification. I do not think that we have ever mandated 
>     *mutual* cross certification in PKIX-1.

I think your concern might be better directed towards the absence of the
word 'optionally' in the 'forward element' description, rather than its
presence here.

X.509 allows both the forward and reverse elements of
crossCertificatePair to be OPTIONAL, the stipulation being that at least
one is present.

A suggested text for this part of OPTION 1 might be:

"Values of the Attribute type crossCertificatePair, if present in a
particular CA's directory entry, shall have at least one of the optional
forward and reverse elements present.

When the forward element is present, it shall contain a certificate
issued to this CA by a different CA in another domain.

When the reverse element is present, it shall contain a certificate
issued by this CA to a different CA in another domain.

When both elements are present in the same value, the value shall
represent a mutual cross-certification of the two CAs. [perhaps add
further statements about compatibility of cross certification here?
(e.g. key usage;  should the certificates mutually verify each other
(probably shouldn't be required)?)]"

The statement about mutual cross-certification is the primary addition
here.  It is an attempt to clarify the meaning when both elements are
present, while leaving room for certificates which, although apparently
representing a mutual cross-certification, represent certificates in
opposite directions which have different policies, key usages, etc.

Does it need to state explicitly that crossCertificatePair is a
multi-valued attribute? 

This text could of course be adapted for OPTION 2.

>
>     Thus OPTION 1 is NOT acceptable and this has nothing to do with 
>     performance or path development.

I think this is not a fundamental flaw of OPTION 1, just an imprecision 
of expression.

>
>In the case of V3 certificates, none of the above CA certificates may
>include a basicConstraints extension with the cA value set to FALSE.
>
>The definition of domain is purely a matter of local policy.

David
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

Date: Fri, 04 Sep 1998 13:19:51 +0200
To: Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[email-masked]>
Sender: [email-masked]

At 08:48 PM 9/2/98 -0400, Santosh Chokhani wrote:
<snip>
>The way I look at the difference between the two options is that if
>n=n1+n2 certificates are issued to a CA, option 1 says CA puts n1 in one
>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>another.  When you retrieve the two buckets (which you must for path
>development efficiency), option 2 gives you n+n1 certificates and option
>1 gives you exactly all n.

I tried to point out before that this is not the whole picture.

The CA is dealing with n CA certificates n=n1+n2+n3+n4 of the form:
n1 = intra domain issued to other CA:s
n2 = intra domain issued by other CA:s to this CA
n3 = inter domain issued to other CA:s
n4 = inter domain issued by other CA:s to this CA

Option 1 stores only n2+n3+n4
(n2 in one bucket and n3+n4 in the other.)

Option 2 stores n1+2(n2)+n3+n4
(n2 in one bucket and n1+n2+n3+n4) in the other)

As you see, n1 is left out of option 1 (according to text)
You said then that it is not forbidden to store n1 (in option 1)
in the cross certificate pair. I guess then that option 1 should
changed-

from:
  Optionally, the reverse element of the
  crossCertificatePair attribute, held in a particular CA's directory entry,
  may contain certificates issued by this CA to CAs in other domains.

to:
  Optionally, the reverse element of the
  crossCertificatePair attribute, held in a particular CA's directory entry,
  may contain certificates issued by this CA to other CAs.

So if this is correct then what we are fighting about is only whether we
should duplicate n2 (out of n1,n2,n3 and n4). To me it sounds reasonable to
have the complete set of n1+n2+n3+n4 in one bucket and the n2 in the
cACertificate attribute as a specific information for those who wants to
have the CA:s guidance to define the inter domain subgroup. And since this
guidance by the CA may be useful in many situations, I consider option 2 as
the perfect compromise.

/Stefan

Date: Fri, 04 Sep 1998 12:20:04 +0200
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[email-masked]>
Sender: [email-masked]

Hi Bob,

At 06:42 PM 9/2/98 -0600, Bob Jueneman wrote:
<snip>
>>I suggest that we stick to the standardized definitions of the key usage
>>bits and leave
>>policy issues out of a common certificate profile.
>
>If there were any sense of the community as to what these definitions really
>mean, or ought to mean, we would probably not be having this discussion.
>Otherwise I would agree with you.
>>
>>non-repudiation is according to standard selected by the NR bit, not NR in
>>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>>other than non-repudiation are allowed for the key.
>
>I believe that is exactly the issue. Are you suggesting that NR plus DS
should not
>be allowed?  Why?

No I do not. I do suggest that such decision is up to local policy. But
there will be some policies where this combination will not be allowed, but
I think you agree to that.

The important thing is that I suggest that the NR bit and DS bit has
separate meaning and that they should be set independently to specify DS,
NR or both.

The vague definition of the NR bit is a problem, I agree to that.

If I were to define some distinguishing property of the NR bit that would be:

   Non repudiation denotes services constructed in such way that:
   1) The signature provides proof of the integrity and 
      origin of data - both in an unforgeable relationship - which can be 
      verified by any third party at any time.[X.509 / ISO 9594-8]
   2) The signature is applied to a message where the signatory is capable
      of, and required to, accept responsibility for the message content 
      before signing.
   3) The signatory's liability for signing the message can be concluded
      from the signed message itself, possibly within a well known and agreed 
      context that can be verified by any third party at any time.

This definitions rules out any signed logon ticket or other data
authentication mechanisms where the signature says "this message wasn't
changed" instead of "I take full responsibility for the message content".

But since this is not defined by the bit (which I regret) the way to go
will be for the CA to include this in it's published certificate policy.

I can't see any other way for now when utilizing the existing standard. I
would not object though to a defect report to get this into the standard.

In the new proposed work item, however, regaring a profile for
non-repudiation certificates supporting legal acceptance of digital
signatures I will try to get this definition in.

Would you support it?

/Stefan

From: [email-masked]
Date: Fri, 4 Sep 1998 05:56:52 -0400
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Content-type: multipart/mixed;  Boundary="0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5"
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Dave Horvath <[email-masked]> writes:

>> The difference between the two options is primarily storage efficiency
vs.
>> retrieval efficiency.  Both options divide a CAs certs into two piles.
>> Option 1 has pile A containing only intra-domain certs, and pile B
>> containing only inter-domain certs; option 2 has pile A containing only
>> intra-domain certs and pite B containing all certs.  Which option is
>> superior depends on two things:
>>
>>...
>>
>> Having the target CA divide its certificates between two places within
the
>> directory is no help to this verifier.  All it does it force the
verifier
>> to make two retrieval operations instead of the one that would be
required
>> by option 2.  The verifier isn't really interested in whether a
particular
>> certificate comes from another CA from the same "domain" as the target's
CA
>> - if it cares about "domains" at all, what it would be interested in is
if
>> any certs come from the same domain as the verifier (or one of its
trusted
>> roots), not the target (and of course that's verifier-specific).
>
>    John,  the verifier does NOT have to invoke two retrieval operations.
>The verifier simply reads the CA entry requesting both the cACertificate
>attribute and the crossCertificatePair attribute in the same search/read
>operation.  All certificates are returned.  The verifier can then decide
>whether to explore inter-domain, intra-domain, both , none, whatever.
>The verifier can lump them all together in the client application if
>they like!  The main advantage to option 1 is we don't store the
>certificates twice which is  a fundamental goal in all database
>applications.   IMHO it applies to repositories and public key
>infrastructures also.

There may not be two protocol actions across the wire, but it's definitely
less work for the client to receive a single set of objects all of the same
type, compared to the two sets of differently typed objects that option 1
requires it to retrieve.  Under option 2, verifiers that don't care about
the CAs ideas about domains can simply retrieve all the CAs certificates.
Having the CA divide its certificates into two piles only adds complexity
to the client's task.

The only place where verifiers will care about which domain the CA thinks
it's in, is if they think they (or one of their roots) are in the same
domain.  Only in that case is a verifier likely to decide to look first at
the CAs intra-domain certs, and option 2 allows for this choice just as
simply as does option 1.

The cost of this in option 2 is the duplication of some certificates in the
directory (we already have duplication in this area, unless the directory
has some intelligence that will enable it to store cross-cert pairs only
once and somehow place a reference to the shared object from both CA
entries).  But this duplication is at the discretion of the CA - if it
doesn't think the benefits of storing hints for local verifiers are
worthwhile, option 2 allows it to use _only_ the crossCertificate entry for
all its certs.

>    The general algorithm we envision is for clients to first explore the
>cACertificate attribute, then explore the crossCertificatePair
>attribute.   That way nothing will get missed.  It's not an all or
>nothing choice.  It's an attempt to store the certificates once and to
>group them to make logical decisions when exploring possibly complex
>paths.

But you can only make logical decisions when you have some data to work
with.  A CA has no idea when it's placing its certs in the directory about
who is going to come look for them.  Without knowing what domain the
verifier is in, the CA can't hope to help it out.  It can make a
special-case optimization under either option for the case where the
verifier is in the same domain as the CA  (which is really the only time
that either option offers any advantage over simply having a single entry
into which all certs are placed).

In summary, my contention is that very few verifiers will ever want to be
bothered with "domains" (or at least, not with some foreign CA's idea of
what a domain is).  Of the two options under discussion, option 2 allows
most verifiers to simply ignore the fact that a CA has chosen to issue
unwanted hints, and just retrieve the certs it wants from a single place.
The few verifiers that want to do something with a CA's hints can choose to
do so under either option, but option 1 would force all client software to
increase in complexity to gain that choice.  Option 2 burdens only those
clients that wish to exploit the hints.

John

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5
Content-type: application/octet-stream; 
	name="$RFC822.eml"
Content-Disposition: attachment; filename="$RFC822.eml"
Content-transfer-encoding: base64

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5--

Date: Fri, 04 Sep 1998 10:32:23 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Robert Zuccherato <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: TemporalData (Time Stamp Protocol)
Sender: [email-masked]

Robert,

In order to facilitate the implementation (and therefore acceptance) of
the Time Stamp Protocol draft, (draft-adams-time-stamp-02.txt) I think
we should provide the ASN.1 material in the 1988 syntax [since only a
few implementers have access to an updated 1994 ASN.1 compiler].

[Stephen Farrell just made the same request yesterday].

NB: [CCP] provides both 1988 and 1994 syntaxes and states that 1988
syntax takes precedence in case of conflict.

Only one adjustment need to be made for that draft : 
the TemporalData definition should be changed from :

TemporalData ::= SEQUENCE  {
     format                  TEMPORALDATACLASS.&id,   --objid
     rawdata                 TEMPORALDATACLASS.&Type  --open type  
}

TEMPORALDATACLASS ::= CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type } WITH SYNTAX  { &Type IDENTIFIED BY &id }

to :

TemporalData ::= SEQUENCE {
     format             OBJECT IDENTIFIER,
     rawdata            ANY DEFINED BY format }

(Please forgive me if I translated the 1994 ASN.1 syntax in a wrong way
since I'm not an ASN.1 fan or expert. :-)

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 04 Sep 1998 10:23:03 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Sender: [email-masked]

Carlisle,

(...)

I follow and fully support your argumentation. I came to the same
conclusions.

IN ADDITION, neither of OPTION 1 or OPTION 2, as written, is acceptable
for reasons which have nothing to do with duplication or location of
information. These reasons are indicated in a separate E-mail and are
related to mandating *mutual* cross certification (OPTION 1) or
forbiding the forward element of a certificate pair (i.e. certificates
issued for this CA by other CAs), if the reverse element is not present
(OPTION 2).

This is why the only acceptable choice for the time is OPTION 0, i.e.
the original text.

I would ask the chairs to :

1) look at the arguments raised about *mutual* cross certification and 
   unilateral cross certification,
2) reconsider the vote and extend it to OPTION 0, i.e. the current text.

A straw poll is not a coin toss, otherwise I would have already
answered. :-)

> The claimed advantage of option 1 is that this retrieval gets me
> certificates that are sorted into "intra-domain" and "inter-domain",
> which can help in efficient path construction.  Let's think about this
> for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
> TRUSTED BY ME  (because if it was directly trusted by me, I would
> already have a trusted copy of its public key and would not need
> certificates in which it was the subject).  If it is not directly
> trusted by me, then why would I necessarily trust it to do this sorting
> in a way that is beneficial to my path construction needs?  How does it
> know what *my* definition of "domain" is?  How does it know whether most
> of my certificate validations will be "intra" its definition of domain
> or "inter" its definition of domain?
 
> If this CA's definition of domain and my definition of domain do not
> coincide exactly (and why should they, since in general this CA and I
> have no pre-established relationship?), then this sorting performed by
> the CA is not merely useless to me, it is actually an explicit
> disadvantage (because the proponents of option 1 are recommending that
> all the intra-domain certificates be examined *before* the inter-domain
> certificates are examined, leading to worst-case path-construction times
> for what may turn out to be a common scenario).
 
> Relying parties know what certificates they will be validating most
> often, depending upon what particular activity they are engaged in at
> the moment.  THAT defines the relying parties' "intra" and "inter"
> domains.  CAs in the middle of a cert. path cannot possibly know this,
> in general, so having THEM define a domain and sort certificates
> according to that definition is really meaningless.
 
> Note that there will be special circumstances in which one definition of
> domain will be understood throughout a given environment (e.g., the
> strict hierarchy of CAs has been cited in previous posts on this topic).
> In such cases there is a clear efficiency advantage to be gained in path
> construction.  This is why option 2 is the perfect compromise:  for such
> environments relying parties need only retrieve the n1 < n certificates
> that they *know* will be useful to them.  Option 2 therefore meets the
> needs of the general case as well as the special case, while
> simultaneously guaranteeing interoperability of two installed bases
> which would otherwise have no hope of interoperating today.
 
> The price of this panacea?  A few redundant certificates in the
> Directory.  Is it really worth sacrificing the general- (and perhaps
> common-) case scenario, as well as interoperability, in order to save a
> few certificates and satisfy a particular special-case?  I haven't yet
> heard any convincing arguments...

Neither do I ...

Denis
 
> Carlisle.

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 04 Sep 1998 10:03:20 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Sharon Boeyen <[email-masked]>
CC: [email-masked], "'Santosh Chokhani'" <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

Sharon, 

> The "two buckets" is exactly what I was trying to avoid in the
> earlier debate on this topic, however I believe that the single 
> bucket option was rejected in the Chicago meeting. 

It was a pity that you could not attend the Chicago meeting. 
"rejected" may be a strong word. During the straw poll, I did not 
raised my hand for any of the three options for the following good 
reasons:

1) I had three weeks of holidays one week ahead of the meeting, :-)
2) When I came back, I had 470 E-mails waiting for me,
3) I completely skipped the thread on the LDAP schema, :-(

As a result I could not understand from the discussion what the topic
was and so I abstained. I would guess that I was not the single one in
that position. There was some support for it anyway, so I do not
understand why the straw poll is not on the three options but instead
only on two options.

> The single bucket option is the
> text which is currently in the Internet Draft. With that text, 
> all self signed (or self issued certificates) were to be placed 
> in the cACertificate attribute and all certificates issued by 
> one CA to a different CA were put in the crossCertificatePair 
> attribute. 

This was pretty nice and simple ! If I were to open the bunch of
messages, maybe I could understand why this is not acceptable.

> Depending on the particular path development algorithm being 
> used by a relying party, directory search tools, especially 
> when we evolve to LDAPv3 could be used to filter the content 
> of the forward and or reverse elements of that SINGLE attribute 
> and provide the relying party with the set of certificates of 
> interest to that particular relying party.

Indeed.
 
> I still believe that this is the best solution because the relying
> party systems are the ones that know which certs are of interest 
> to them, 

I agree with you.

> not the CA that happened to issue the certs, especially in the 
> post PEM world where any CA could legitimately have certs issued 
> for it by several CAs.
 
> My strong support for Option 2 in the straw poll is because 
> the above was rejected by the meeting and I see Option 2 as 
> a workable compromise ONLY because there is a complete set of 
> certs in a single attribute and relying parties can do what is 
> of interest to them without knowing the definition of domain 
> which each individual CA happens to use. For self contained 
> environments wanting to make use of a CA or set of CAs certs
> issued within some locally defined domain, this is still possible.

Let me take a look at option 1 and say why it is not acceptable ... 
because it imposes a model of trust that is too specific.

General comment: The notion of "domain" has never been introduced
before and since the understanding of a domain is "purely a matter 
of local policy" there is no chance that the requester understands 
what it means - unless we are in a close environment. 

I believe that this feature is being introduced to be used in close
environments for some "good" reasons. The text should explain these
"good" reasons otherwise readers of the document will ignore for ever
the rational.  

PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
OPTION 1:
----------------
The cACertificate attribute, held in a particular CA's directory
entry, shall be used to store certificates issued to this CA by CAs 
in the same domain as this CA. 

     When the notion of domain does not exists, then this will 
     be empty.

In addition, the cACertificate attribute shall be used to
store self-issued certificates.

     This is fine.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates
issued to this CA by CAs in other domains.  

     I have a problem here. Cross certification does not mean mutual 
     cross certification. A CA can cross-certify another CA without 
     any knowledge from the CA being cross certified. Even if the CA
     got the knowledge of it, that CA would not like to place that 
     certificate in that entry. Let us pick an example: a CA from 
     the Banana Republic of Baracuda is providing a certificate for 
     the NIST. I do not think that the NIST will necessarilly place
     that certificate in his entry. 

Optionally, the reverse element of the crossCertificatePair attribute, 
held in a particular CA's directory entry, may contain certificates 
issued by this CA to CAs in other domains.

     I have a problem here with the word "Optionally" : if the 
     previous element is not there, then I cannot place an element 
     here. This means that if CA 1 wants to recognize CA 2, 
     then CA 2 MUST also recognize CA 1. This mandates mutual cross
     certification. I do not think that we have ever mandated 
     *mutual* cross certification in PKIX-1.

     Thus OPTION 1 is NOT acceptable and this has nothing to do with 
     performance or path development.

In the case of V3 certificates, none of the above CA certificates may
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

OPTION 2:
-------------
The crossCertificatePair attribute, held in a particular CA's
directory entry, shall be used to store all certificates issued 
by this CA to other CAs, as well as certificates issued 
for this CA by other CAs. Values held in the forward element are 
certificates issued for this CA by other CAs, while values 
in the reverse element are certificates issued by this CA for
other CAs. 

     I would interpret the text as mandating to store the reverse 
     element and optionally the forward element. I would instead
     allow to store only the forward element, only the reverse 
     element or both. 

     Hence the OPTION 2 is NOT acceptable either and this has 
     nothing to do with performance or path development.

The text should be corrected and be something like:

     The crossCertificatePair  attribute,  held  in  a  particular  CA's
     directory  entry,  may be used to store certificates issued by this
     CA to other CAs, as well as certificates  issued  for  this  CA  by
     other  CAs.  Values  held  in  the forward element are certificates
     issued for this CA by other CAs, while values in the  reverse  ele-
     ment  are certificates issued by this CA for other CAs. Either cer-
     tificate, if present,  may be used in  building  certificate  paths
     for  validation  and  may  be published in the directory entries of
     either CA or both.

 ... which is exactly what is in the original text !

The cACertificate attribute, held in a particular CA's directory
entry, shall be used to store certificates issued to this CA by CAs 
in the same domain as this CA. This set of certificates is a subset 
of the values of the forward element of the crossCertificatePair 
attribute in the same CA entry.
 
In addition, the cACertificate attribute shall beused to store
self-issued certificates.  

     When there are no domains, and IF the text was corrected as 
     indicated hereabove (i.e. back to the text of the original 
     version) then we would be "compatible" with the previous 
     text, but this is not the case. Did I understood correctly ?

     I believe that there are "good" resons to introduce the 
     notion of "domain". Are these "good reasons" technical or 
     commercial ? If they are technical then they SHALL be 
     written in the document. But what about if they are 
     "commercial" ?

For the time being, I can only vote for OPTION 0 (i.e. the original
text) !

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Andrea Sansone" <[email-masked]>
To: [email-masked]
Date: Fri, 4 Sep 1998 08:21:29 +0200
Subject: for option 1
Sender: [email-masked]

From: Alan Lloyd <[email-masked]>
To: "'Frank O'Dwyer'" <[email-masked]>, Dave Horvath <[email-masked]>
Cc: [email-masked]
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Fri, 4 Sep 1998 14:22:16 +1000
Sender: [email-masked]

I have a few views in that certs must be supported by mutually
authenticated distributed X.500 directory systems otherwise 509 based
systems just  wont scale and provide the commercial utilitity as
demanded by global EC directed organisations. Not having this foundation
- one just drops into all sorts of operational cost, scaling and
efficiency holes.
The draft I put out attempts to put the onus on a CA to gets its
directory act in order with a common information architecture (DIB) and
not just a set of agreed object classes with multitudes of extensions
and options - and that the CAs and their supporting directories provide
a "sensible" set of validation services, starting  at a very base level
- for simple to implement client applications.

One aspect of the cross cert issue is for the CA/directory system  to
know what the originating and verifying domain is so that it can select
the necessary path information sets. 

there is some of this detail in my draft.

To me its all in the information management design of a CA and its
processing utilities and how that is effectively applied into a mutually
authenticated (cert matching ruled) distributed directory system...
Hence my previous comments about single server LDAP servers - they just
cannot do the job. 
regards alan

> -----Original Message-----
> From:	Frank O'Dwyer [SMTP:[email-masked]]
> Sent:	Friday, 4 September 1998 12:36
> To:	Dave Horvath
> Cc:	[email-masked]
> Subject:	path development complexity (was Re: What the straw poll
> means)
> 
> Dave Horvath wrote:
> >         We are back the problem we raised earlier.  Clients that
> attempt to
> > efficiently develop a path from the end entity to the trusted root
> must
> > explore 'n' paths (worst case scenario)  prior to finding the
> correct
> > one with option 2.  
> 
> This is not on the topic of the straw poll, but I was wondering if
> anyone has really looked into how difficult path development can get
> in
> a full-blown and well-connected global PKI? It seems to me that the
> real
> worst case scenario has you following cross-certificates until you
> have
> downloaded all the cross-certificates in the world. It would not have
> to
> get that bad before it was a serious problem.
> 
> A few things would help prune the search (like the depth you are
> willing
> to search to, constraints within the certificates themselves), but
> still
> in general it has the potential to get truly nasty. Unless I have
> missed
> something, there are no positive hints in the certificates that would
> guide path development (perhaps there should be? There is a
> resemblance
> to the "travelling salesman" problem here, and it would certainly be 
> ironic if building a path turned out to be as hard as factoring.:)
> 
> Anyone looked at this? If it is a problem, then it might be reasonable
> to give recommendations on using constraints (or something else) in
> order to encourage the creation of cross-certificates that are
> "path-development friendly", and in order to discourage scenarios that
> lead to directory search explosions.
> 
> Apologies if I am re-hashing something that has already been discussed
> here.
> 
> Cheers,
> Frank O'Dwyer.

Date: Thu, 03 Sep 1998 23:31:01 -0400
From: Tony Bates <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Fri, 04 Sep 1998 03:35:30 +0100
From: "Frank O'Dwyer" <[email-masked]>
To: Dave Horvath <[email-masked]>
CC: [email-masked]
Subject: path development complexity (was Re: What the straw poll means)
Sender: [email-masked]

Dave Horvath wrote:
>         We are back the problem we raised earlier.  Clients that attempt to
> efficiently develop a path from the end entity to the trusted root must
> explore 'n' paths (worst case scenario)  prior to finding the correct
> one with option 2.  

This is not on the topic of the straw poll, but I was wondering if
anyone has really looked into how difficult path development can get in
a full-blown and well-connected global PKI? It seems to me that the real
worst case scenario has you following cross-certificates until you have
downloaded all the cross-certificates in the world. It would not have to
get that bad before it was a serious problem.

A few things would help prune the search (like the depth you are willing
to search to, constraints within the certificates themselves), but still
in general it has the potential to get truly nasty. Unless I have missed
something, there are no positive hints in the certificates that would
guide path development (perhaps there should be? There is a resemblance
to the "travelling salesman" problem here, and it would certainly be 
ironic if building a path turned out to be as hard as factoring.:)

Anyone looked at this? If it is a problem, then it might be reasonable
to give recommendations on using constraints (or something else) in
order to encourage the creation of cross-certificates that are
"path-development friendly", and in order to discourage scenarios that
lead to directory search explosions.

Apologies if I am re-hashing something that has already been discussed
here.

Cheers,
Frank O'Dwyer.

From: Alan Lloyd <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Where to store CA certificates
Date: Fri, 4 Sep 1998 12:02:04 +1000
Sender: [email-masked]

Agree with this - but in particular - if the directory system does not
correctly support distributed operations (as per X.500 DSP) and does not
implement certificate based matching rules and the client software does
not provide under what guise or domain they are validating from,  then
it (cert path processing and validation) is inefficient, may be fragile
and will be difficult to manage and therefore operationllay risky.

With no dir matching/filter  rules and accessing a CAs entry could bring
back CRLs, a bunch of CA cross certs and the client  may be none the
wiser. 

As per my other comments - dealing with 509 paths in a distributed way
without efficient distributed directories and cert based features seems
odd situation to discuss.

Views on my draft re dir - cert stat could progress the issue re
"complexity" and "efficiency" of validation actions.

regards alan

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Friday, 4 September 1998 10:11
> To:	'Ambarish Malpani'; [email-masked]'
> Subject:	RE: Where to store CA certificates
> 
> Ambarish:
> 
> We should explore your point further.  But, I am assuming that
> features
> such as subject public key identifier and authority public key
> identifier, name constraints (in conjunction with pathToName matching
> rule), key usage are available for proper digital signature
> certificate.
> The question becomes of these which one will lead to the trust anchor
> of
> the relying party from the current CA (assuming you are developing a
> path from subject to the relying party trust anchor).
> 
> I am afraid that the CA may not help much except say which
> certificates
> issued to it are from its domain/family/partners/preferred or whatever
> and which are from others.
> 
> I also see all of us doing rapid fire on this one without considering
> all the ramifications.  I am probably the worst culprit.  I will be
> the
> first one to admit that I am the worst offender.
> 
> I do not claim to have the solutions, full knowledge or the final word
> on the path development, but to use the PKI technology efficiently,
> lot
> may have to fall in place.  I am not sure directory products and
> client
> products are stepping up to offering the potential need for
> efficiency.
> 
> Let me give you simple example in which option 2 may choke the network
> and/or client if there are no matching rules implemented both in the
> directory and the client.  Let us assume that a CA has issued 30
> certificates to other CAs but has been issued very few certificates
> itself.  Under option 2, the CA must populate the reverse component of
> the crossCertificatePair attribute 30 times, and these will be
> returned
> on a query, if both the client and the directory do not implement
> matching rules.
> 
> I have thought long and hard and find that option 1 gives us the best
> hope for path development efficiency.
> 
> 
> > -----Original Message-----
> > From:	Ambarish Malpani [SMTP:[email-masked]]
> > Sent:	Thursday, September 03, 1998 12:54 PM
> > To:	[email-masked]'
> > Subject:	Where to store CA certificates
> > 
> > Hi Guys,
> >     Given the huge amount of passion that the topic of where one
> > stores CA certificates has generated, it seems to me that path
> > building is both a complicated and important thing ;-)
> > 
> >     If the premise above is true, wouldn't one want to prioritize
> > path building more precisely than just lumping CA certs into
> > one of two categories (intra-domain/inter-domain)?
> > 
> >     Would it make sense to have another attribute attached to
> > CA certificates - something like a "priority" field, with say
> > an integer value, where, during path building you first try to
> > build paths with the CA cert with the highest priority?
> > 
> >     Or is this a BAD idea, because it doesn't work with any of
> > the current implementations?
> > 
> > Comments? Sharon, Santosh?
> > 
> > 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: Alan Lloyd <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, Carlisle Adams <[email-masked]>
Cc: [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw		 poll means)
Date: Fri, 4 Sep 1998 11:29:45 +1000
Sender: [email-masked]

comments in line

> -----Original Message-----
> From:	Ambarish Malpani [SMTP:[email-masked]]
> Sent:	Friday, 4 September 1998 6:41
> To:	Carlisle Adams
> Cc:	[email-masked]
> Subject:	Re: Let's try to understand the real issue (was... RE:
> What the straw		 poll means)
> 
> Hi Carlisle,
>     Is the expectation that everybody is directly accessing their
> CA's LDAP directory? I always thought that each orginazation would
> actually maintain its own LDAP directory and, therefore, be able
> to specify which CAs are preferred over others.
> 
>     Are we really expecting people to share their directories with
> everyone in the world?
	[Alan Lloyd]  
	I think so - May be not quite share everything with everyone
but I think there will be vertical market sector directory systems such
as Defence, Finance, Transport, Health, Police, Postal, Telecomms, etc
and that little old me with my directory entry will have certificates in
- issued by them, so I can deal with these areas. And I will
interconnect my directory system so I can use the services and
privileges offered by these sectors. Just like my wallet contents allow
me today with a range of plastic card services. The main distraction
today is that LDAP servers are pointless devices (no distribution) for
wide scale EC or cert path processing. And it seems that most systems
being developed for CAs seem to grab an LDAP server (not an LDAP
accessed X.500 server) and from that point on simply limit their scope
of what a business does. In most cases all the business can do is do
business with its self and its own CA. 
	Its only when one realises that one has to connect ones Org
directory system to other Orgs and multiple CAs that one hits the
distribution issue - and throws the LDAP server in the bin.

	As for domains - I just see that as "the sphere of influence" or
if qualified like Management Domain or Directory Management Domain (see
X.501) it relates to the management influence and implied ownership of a
directory  or directory system. No Protocol or technical boundary is
enforced unless for example with directories by Name containment - its
usually an operational or business issue ie. with certs its how the
certs are applied with a management and business related policy.

	My usual thoughts
	regards alan

> Ambarish
> 
> 
> Carlisle Adams wrote:
> > 
> > Hi all,
> > 
> > I propose that we try (once again) to understand what the real issue
> is
> > here.
> > 
> > > ----------
> > > From:         Ryan Moats[SMTP:[email-masked]]
> > > Sent:         Thursday, September 03, 1998 12:14 PM
> > > To:   [email-masked]
> > > Cc:   [email-masked]
> > > Subject:      Retrieval efficiency herring? (was... RE: What the
> straw
> > > poll means)
> > >
> > > As somebody coming to the party late from the LDAP world, I don't
> see
> > > why
> > > the certificates need to be retrieved from two places.  An LDAP
> lookup
> > > of an
> > > object with a fairly simple filter (objectclass="*") will return
> all
> > > of the
> > > attributes associated with that object.  Therefore a single lookup
> > > will return
> > > both attributes, so I don't understand how retrieval efficiency is
> > > gained.
> > >
> > O.K., so we see that a single LDAP lookup can retrieve all
> certificates
> > (which, after careful enumeration, was found to be "n") in either
> option
> > 1 or option 2.
> > 
> > The claimed advantage of option 1 is that this retrieval gets me
> > certificates that are sorted into "intra-domain" and "inter-domain",
> > which can help in efficient path construction.  Let's think about
> this
> > for a moment.  The CA doing this sorting is, by definition, NOT
> DIRECTLY
> > TRUSTED BY ME  (because if it was directly trusted by me, I would
> > already have a trusted copy of its public key and would not need
> > certificates in which it was the subject).  If it is not directly
> > trusted by me, then why would I necessarily trust it to do this
> sorting
> > in a way that is beneficial to my path construction needs?  How does
> it
> > know what *my* definition of "domain" is?  How does it know whether
> most
> > of my certificate validations will be "intra" its definition of
> domain
> > or "inter" its definition of domain?
> > 
> > If this CA's definition of domain and my definition of domain do not
> > coincide exactly (and why should they, since in general this CA and
> I
> > have no pre-established relationship?), then this sorting performed
> by
> > the CA is not merely useless to me, it is actually an explicit
> > disadvantage (because the proponents of option 1 are recommending
> that
> > all the intra-domain certificates be examined *before* the
> inter-domain
> > certificates are examined, leading to worst-case path-construction
> times
> > for what may turn out to be a common scenario).
> > 
> > Relying parties know what certificates they will be validating most
> > often, depending upon what particular activity they are engaged in
> at
> > the moment.  THAT defines the relying parties' "intra" and "inter"
> > domains.  CAs in the middle of a cert. path cannot possibly know
> this,
> > in general, so having THEM define a domain and sort certificates
> > according to that definition is really meaningless.
> > 
> > Note that there will be special circumstances in which one
> definition of
> > domain will be understood throughout a given environment (e.g., the
> > strict hierarchy of CAs has been cited in previous posts on this
> topic).
> > In such cases there is a clear efficiency advantage to be gained in
> path
> > construction.  This is why option 2 is the perfect compromise:  for
> such
> > environments relying parties need only retrieve the n1 < n
> certificates
> > that they *know* will be useful to them.  Option 2 therefore meets
> the
> > needs of the general case as well as the special case, while
> > simultaneously guaranteeing interoperability of two installed bases
> > which would otherwise have no hope of interoperating today.
> > 
> > The price of this panacea?  A few redundant certificates in the
> > Directory.  Is it really worth sacrificing the general- (and perhaps
> > common-) case scenario, as well as interoperability, in order to
> save a
> > few certificates and satisfy a particular special-case?  I haven't
> yet
> > heard any convincing arguments...
> > 
> > Carlisle.
> 
> -- 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect					         650.567.5457
> ValiCert, Inc.
> [email-masked]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 20:33:53 -0400
Sender: [email-masked]

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 8:19 PM
> To:	[email-masked]'; 'Santosh Chokhani'
> Cc:	[email-masked]
> Subject:	RE: What the straw poll means
> 
>        
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[email-masked]]
> > Sent: 	September 3, 1998 7:50 PM
> > To: 	[email-masked]'; Santosh Chokhani
> > Cc: 	[email-masked]
> > Subject: 	RE: What the straw poll means
> > 
> > John:
> > 
> > As Dave Horvath has replied, retrieval efficiency is the same.
> > 
> > Option 2 also retrieves all multiple certificates and hence
> introduces
> > communication delays and unnecessary bandwidth usage
> This is dependent on the query. 
> 
> For relying parties that have the same understanding of 'domain' as
> the
> CA, they could either 
> a) send an LDAP search request which retrieves ONLY the values of the
> cACertificate attribute and then after exhausting them, send another
> request that would retrieve the crossCertificatePair attribute values
> or
> 
	[]  In a), another bind and access to directory may cause delays

> b) send a single LDAP search request that would retrieve both
> attributes. In b) yes they woud retrieve the multiples. 
> In a) they would retrieve multiples only if they were unsuccessful
> with
> the 'domain' certs. In b) they would receive multiples.
> 
> Relying parties that ignore the 'domain' specifics would send a single
> LDAP search request that would retrieve only the crossCertificatePair
> attribute and would never receive multiples.
> > .
> > 
> > Using option 2, if a client only retrieves crossCertificatePair
> > attribute only, it loses potential for efficiency.
> > 
> > Your last paragraph is precisely my point.  Dividing the
> certificates
> > in
> > two buckets has potential for help and never hurts.
> > 
> > By the way, a class of application may choose to prefer exploring
> > inter-domain certificates first, if so deemed.
> > 
> > > -----Original Message-----
> > > From:	[email-masked] [SMTP:[email-masked]]
> > > Sent:	Thursday, September 03, 1998 8:51 AM
> > > To:	Santosh Chokhani
> > > Cc:	[email-masked]
> > > Subject:	RE: What the straw poll means
> > > 
> > > Santosh Chokhani <[email-masked]> writes:
> > > 
> > > >The basic difference between the two approaches is the under
> option
> > 1
> > > >you store a certificate only one time under a CA's entry.  Which
> > > >certifying CA is in its domain is upto a subject CA to decide.
> > > >
> > > >In all honesty, I do not see a benefit to option 2 except for the
> > > >argument that some installed base already does it this way.
> > > 
> > > The difference between the two options is primarily storage
> > efficiency
> > > vs.
> > > retrieval efficiency.  Both options divide a CAs certs into two
> > piles.
> > > Option 1 has pile A containing only intra-domain certs, and pile B
> > > containing only inter-domain certs; option 2 has pile A containing
> > > only
> > > intra-domain certs and pite B containing all certs.  Which option
> is
> > > superior depends on two things:
> > > 
> > >    whether you care more about storage efficiency in the directory
> > > (option
> > >    2 stores intra-domain certificates twice) or retrieval
> efficiency
> > > for
> > >    the verifier (option 1 require a verifier that wants all a
> target
> > > CA's
> > >    certificates to retrieve them from two places).
> > >    typical usage scenarios by verifiers - i.e. the percentage of
> > > clients
> > >    that are going to want to locate just inter-domain certs,
> > compared
> > > to
> > >    clients that either don't care about the difference or are only
> > >    interested in intra-domain certs.  Retrieval of _just_
> > inter-domain
> > >    certs is easier under option 1, retrieval of _all_ certs is
> > easier
> > > under
> > >    option 2, and retrieval of _just_ intra-domain certs is the
> same
> > > under
> > >    both options.
> > > 
> > > 
> > > Consider a fairly randomly structured PKI, where the verifier has
> a
> > > set of
> > > trusted roots loaded into it (assume they've been loaded under
> user
> > > control, with no particular order to them), and is trying to
> verify
> > > the key
> > > of some server that it hasn't spoken to before.  It has no idea of
> > > which
> > > "domain" the target's CA thinks it belongs to; it just wants to
> pull
> > > all
> > > the certs that have that CA as a subject, and see if it can
> > construct
> > > a
> > > valid chain starting at one of its trusted roots.
> > > 
> > > Having the target CA divide its certificates between two places
> > within
> > > the
> > > directory is no help to this verifier.  All it does it force the
> > > verifier
> > > to make two retrieval operations instead of the one that would be
> > > required
> > > by option 2.  The verifier isn't really interested in whether a
> > > particular
> > > certificate comes from another CA from the same "domain" as the
> > > target's CA
> > > - if it cares about "domains" at all, what it would be interested
> in
> > > is if
> > > any certs come from the same domain as the verifier (or one of its
> > > trusted
> > > roots), not the target (and of course that's verifier-specific).
> > > 
> > > For the special (and probably quite common) case where the
> verifier
> > > and
> > > target happen to be in the same domain, the distinction probably
> is
> > > useful.
> > > Option 2 supports this case just as well as does option 1, by
> > allowing
> > > the
> > > CA to place intra-domain certs in a separate place so that clients
> > in
> > > that
> > > domain can retrieve them first (or possibly even _instead_of_
> going
> > to
> > > the
> > > all-certs list).
> > > 
> > > John
> > > 
> > 

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 01:19:16 +0100
Sender: [email-masked]

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 3, 1998 7:50 PM
> To: 	[email-masked]'; Santosh Chokhani
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> John:
> 
> As Dave Horvath has replied, retrieval efficiency is the same.
> 
> Option 2 also retrieves all multiple certificates and hence introduces
> communication delays and unnecessary bandwidth usage
This is dependent on the query. 

For relying parties that have the same understanding of 'domain' as the
CA, they could either 
a) send an LDAP search request which retrieves ONLY the values of the
cACertificate attribute and then after exhausting them, send another
request that would retrieve the crossCertificatePair attribute values or

b) send a single LDAP search request that would retrieve both
attributes. In b) yes they woud retrieve the multiples. 
In a) they would retrieve multiples only if they were unsuccessful with
the 'domain' certs. In b) they would receive multiples.

Relying parties that ignore the 'domain' specifics would send a single
LDAP search request that would retrieve only the crossCertificatePair
attribute and would never receive multiples.
> .
> 
> Using option 2, if a client only retrieves crossCertificatePair
> attribute only, it loses potential for efficiency.
> 
> Your last paragraph is precisely my point.  Dividing the certificates
> in
> two buckets has potential for help and never hurts.
> 
> By the way, a class of application may choose to prefer exploring
> inter-domain certificates first, if so deemed.
> 
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Thursday, September 03, 1998 8:51 AM
> > To:	Santosh Chokhani
> > Cc:	[email-masked]
> > Subject:	RE: What the straw poll means
> > 
> > Santosh Chokhani <[email-masked]> writes:
> > 
> > >The basic difference between the two approaches is the under option
> 1
> > >you store a certificate only one time under a CA's entry.  Which
> > >certifying CA is in its domain is upto a subject CA to decide.
> > >
> > >In all honesty, I do not see a benefit to option 2 except for the
> > >argument that some installed base already does it this way.
> > 
> > The difference between the two options is primarily storage
> efficiency
> > vs.
> > retrieval efficiency.  Both options divide a CAs certs into two
> piles.
> > Option 1 has pile A containing only intra-domain certs, and pile B
> > containing only inter-domain certs; option 2 has pile A containing
> > only
> > intra-domain certs and pite B containing all certs.  Which option is
> > superior depends on two things:
> > 
> >    whether you care more about storage efficiency in the directory
> > (option
> >    2 stores intra-domain certificates twice) or retrieval efficiency
> > for
> >    the verifier (option 1 require a verifier that wants all a target
> > CA's
> >    certificates to retrieve them from two places).
> >    typical usage scenarios by verifiers - i.e. the percentage of
> > clients
> >    that are going to want to locate just inter-domain certs,
> compared
> > to
> >    clients that either don't care about the difference or are only
> >    interested in intra-domain certs.  Retrieval of _just_
> inter-domain
> >    certs is easier under option 1, retrieval of _all_ certs is
> easier
> > under
> >    option 2, and retrieval of _just_ intra-domain certs is the same
> > under
> >    both options.
> > 
> > 
> > Consider a fairly randomly structured PKI, where the verifier has a
> > set of
> > trusted roots loaded into it (assume they've been loaded under user
> > control, with no particular order to them), and is trying to verify
> > the key
> > of some server that it hasn't spoken to before.  It has no idea of
> > which
> > "domain" the target's CA thinks it belongs to; it just wants to pull
> > all
> > the certs that have that CA as a subject, and see if it can
> construct
> > a
> > valid chain starting at one of its trusted roots.
> > 
> > Having the target CA divide its certificates between two places
> within
> > the
> > directory is no help to this verifier.  All it does it force the
> > verifier
> > to make two retrieval operations instead of the one that would be
> > required
> > by option 2.  The verifier isn't really interested in whether a
> > particular
> > certificate comes from another CA from the same "domain" as the
> > target's CA
> > - if it cares about "domains" at all, what it would be interested in
> > is if
> > any certs come from the same domain as the verifier (or one of its
> > trusted
> > roots), not the target (and of course that's verifier-specific).
> > 
> > For the special (and probably quite common) case where the verifier
> > and
> > target happen to be in the same domain, the distinction probably is
> > useful.
> > Option 2 supports this case just as well as does option 1, by
> allowing
> > the
> > CA to place intra-domain certs in a separate place so that clients
> in
> > that
> > domain can retrieve them first (or possibly even _instead_of_ going
> to
> > the
> > all-certs list).
> > 
> > John
> > 
> 

From: Santosh Chokhani <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 20:10:53 -0400
Sender: [email-masked]

Ambarish:

We should explore your point further.  But, I am assuming that features
such as subject public key identifier and authority public key
identifier, name constraints (in conjunction with pathToName matching
rule), key usage are available for proper digital signature certificate.
The question becomes of these which one will lead to the trust anchor of
the relying party from the current CA (assuming you are developing a
path from subject to the relying party trust anchor).

I am afraid that the CA may not help much except say which certificates
issued to it are from its domain/family/partners/preferred or whatever
and which are from others.

I also see all of us doing rapid fire on this one without considering
all the ramifications.  I am probably the worst culprit.  I will be the
first one to admit that I am the worst offender.

I do not claim to have the solutions, full knowledge or the final word
on the path development, but to use the PKI technology efficiently, lot
may have to fall in place.  I am not sure directory products and client
products are stepping up to offering the potential need for efficiency.

Let me give you simple example in which option 2 may choke the network
and/or client if there are no matching rules implemented both in the
directory and the client.  Let us assume that a CA has issued 30
certificates to other CAs but has been issued very few certificates
itself.  Under option 2, the CA must populate the reverse component of
the crossCertificatePair attribute 30 times, and these will be returned
on a query, if both the client and the directory do not implement
matching rules.

I have thought long and hard and find that option 1 gives us the best
hope for path development efficiency.

> -----Original Message-----
> From:	Ambarish Malpani [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 12:54 PM
> To:	[email-masked]'
> Subject:	Where to store CA certificates
> 
> Hi Guys,
>     Given the huge amount of passion that the topic of where one
> stores CA certificates has generated, it seems to me that path
> building is both a complicated and important thing ;-)
> 
>     If the premise above is true, wouldn't one want to prioritize
> path building more precisely than just lumping CA certs into
> one of two categories (intra-domain/inter-domain)?
> 
>     Would it make sense to have another attribute attached to
> CA certificates - something like a "priority" field, with say
> an integer value, where, during path building you first try to
> build paths with the CA cert with the highest priority?
> 
>     Or is this a BAD idea, because it doesn't work with any of
> the current implementations?
> 
> Comments? Sharon, Santosh?
> 
> 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: Sharon Boeyen <[email-masked]>
To: [email-masked], [email-masked], "'John Everson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:59:48 +0100
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	John Everson[SMTP:[email-masked]]
> Sent: 	September 3, 1998 10:52 AM
> To: 	[email-masked]; [email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> 
> Does this mean there will be a new option (3):
> 
> container/pile of intra-domain certs
> container/pile of inter-domain certs
> container/pile of all certs
> 
> Or do we throw everything into one container and offer a different 
> mechanism for distinction?
> 
> 
	The 'one container' option is the solution as per the current
text in the internet draft. 

> -----Original Message-----
> From: John.Wray [mailto:[email-masked]]
> Sent: Thursday, September 03, 1998 7:51 AM
> To: chokhani
> Cc: John.Wray; ietf-pkix
> Subject: RE: What the straw poll means
> 
> 
> Santosh Chokhani <[email-masked]> writes:
> 
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> 
> The difference between the two options is primarily storage efficiency
> 
> vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing
> only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
> 
>    whether you care more about storage efficiency in the directory 
> (option
>    2 stores intra-domain certificates twice) or retrieval efficiency
> for
>    the verifier (option 1 require a verifier that wants all a target 
> CA's
>    certificates to retrieve them from two places).
>    typical usage scenarios by verifiers - i.e. the percentage of
> clients
>    that are going to want to locate just inter-domain certs, compared
> to
>    clients that either don't care about the difference or are only
>    interested in intra-domain certs.  Retrieval of _just_ inter-domain
>    certs is easier under option 1, retrieval of _all_ certs is easier 
> under
>    option 2, and retrieval of _just_ intra-domain certs is the same 
> under
>    both options.
> 
> 
> Consider a fairly randomly structured PKI, where the verifier has a
> set 
> of
> trusted roots loaded into it (assume they've been loaded under user
> control, with no particular order to them), and is trying to verify
> the 
> key
> of some server that it hasn't spoken to before.  It has no idea of
> which
> "domain" the target's CA thinks it belongs to; it just wants to pull
> all
> the certs that have that CA as a subject, and see if it can construct
> a
> valid chain starting at one of its trusted roots.
> 
> Having the target CA divide its certificates between two places within
> 
> the
> directory is no help to this verifier.  All it does it force the 
> verifier
> to make two retrieval operations instead of the one that would be 
> required
> by option 2.  The verifier isn't really interested in whether a 
> particular
> certificate comes from another CA from the same "domain" as the 
> target's CA
> - if it cares about "domains" at all, what it would be interested in
> is 
> if
> any certs come from the same domain as the verifier (or one of its 
> trusted
> roots), not the target (and of course that's verifier-specific).
> 
> For the special (and probably quite common) case where the verifier
> and
> target happen to be in the same domain, the distinction probably is 
> useful.
> Option 2 supports this case just as well as does option 1, by allowing
> 
> the
> CA to place intra-domain certs in a separate place so that clients in 
> that
> domain can retrieve them first (or possibly even _instead_of_ going to
> 
> the
> all-certs list).
> 
> John
> 
> 
> 

From: "Eaton, James (EATO)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 17:01:52 -0700 
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, Dave Horvath <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:53:58 +0100
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 3, 1998 7:41 PM
> To: 	'Bill Burr'; Dave Horvath
> Cc: 	[email-masked]
> Subject: 	RE: What the straw poll means
> 
> Bill, 
> 
> But under option 1 also all certificates are there since LAP gives you
> all the attributes.
> 
> All option 1 does is reduce the communication load, 
Disagree - this is dependent on the query placed by the client system
> processing load,
Disagree - this is dependent on the certificate and path discovery
algorithm 
and mechanism used by the client system
> storage load 
Agree - in those cases where the local definition of "domain" results in
duplication
> and provide you a potential for efficiency.  
Possibly in a closed specific environment to tthe detriment of other
clients
> With very,
> very little software complexity
Implementation specific
> , you have a potential for gaining a lot
> on the computational complexity.
Algorithm and process specific

> > -----Original Message-----
> > From:	Bill Burr [SMTP:[email-masked]]
> > Sent:	Thursday, September 03, 1998 12:48 PM
> > To:	Dave Horvath
> > Cc:	[email-masked]
> > Subject:	Re: What the straw poll means
> > 
> > But what is a root here?  Does it imply that a domain is PKI
> > hierarchy?  I
> > can think of 3 plausible constructions of root, all of which I
> believe
> > I've
> > seen used: 
> > 
> > (1) any CA whose key you choose to trust and therefore can start a
> > certification path, but which may not imply any other organization
> or
> > structure;
> > 
> > (2) a CA whose key everybody in the domain (what's a domain?) trusts
> > and
> > which sits on top of a hierarchical unidirectional certification
> tree
> > (as
> > in MISSI or PEM);
> > 
> > (3) a CA that exists to cross-certify with other CAs, but issues few
> > or no
> > end entity certificates, and starts few or no certification paths;
> it
> > simply exists to connect other CAs.  Examples would be the ANX
> > "supervisory
> > CA," the Gov. of Canada "Level 0" CA operated by the Canadian
> Central
> > Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is
> often
> > depicted at the hub of a mesh, or the top of a hierarchy, and
> operated
> > in
> > conjunction with the overall domain policy management authority.
> > 
> > 
> > I suppose a "trusted root" can be either 1 or 2 above.
> > 
> > But "root" to me doesn't necessarily say much about path
> development,
> > or
> > PKI certification path structure.
> > 
> > How about domain? What does it mean?  I claim that the term makes
> most
> > sense to mean a part of a PKI that operates under the direction of a
> > policy
> > management entity. Which wouldn't necessarily mean that domain
> > boundaries
> > coincide with distinctions that are meaningful for certification
> path
> > building.
> > 
> > Option 1 is probably useful if you think that a domain is
> everything
> > subordinate to the same root CA, where a root is any CA that
> somebody
> > uses
> > to start a trust path.  So in a cross-certified mesh PKI, every CA
> is
> > a
> > domain onto itself, and all CA certificates wind up only, I think,
> in
> > the
> > crossCertificatePair attribute.  But in a hierarchical PKI most
> > certificates wind up in the cACertificate Attribute.  
> > 
> > I have the feeling that Bob is right at least for option 1, unless
> we
> > know
> > what a domain is we hardly know what we are getting.  With option 2,
> I
> > suppose we are guaranteed that all certificates wind up in
> > crossCertificatePair, whatever domain means.  
> > 
> > At 11:14 AM 9/3/98 -0400, you wrote:
> > >Bob,
> > >
> > >    I feel that the definition of domain is a local policy and that
> > CAs
> > >should be free to define it as they wish.   Clients  that
> search/read
> > CAs
> > >entries and obtain the values from both the cACertificate and
> > >crossCertificatePair attributes can explore the values in the
> > cACertficate
> > >attribute first.  If a path to the trusted root is found,
> processing
> > stops.
> > >If not, they can explore the crossCertificatePair attribute.  Using
> > this
> > >algorithm CAs can define their domain and post each of their CA
> > certificates
> > >to one attribute or the other.  The only adverse affect will be
> > efficiency
> > >in path development  on the client side if the CA does not
> carefully
> > select
> > >intra or inter domain.  WIth option 1, the certificates are not
> > duplicated.
> > >With option 2, they are.
> > >
> > >But if we have an installed base that only looks in the
> > crossCertificatePair
> > >attribute, then we have a problem.  In that case option 2 will help
> > at the
> > >expense of duplicating the data.   I suggest we avoid duplication
> if
> > >possible, but we certainly must evaluate the installed base.
> > >
> > >Dave Horvath
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Bob Jueneman <[email-masked]>
> > >To: [email-masked] <[email-masked]>;
> [email-masked]
> > ><[email-masked]>
> > >Date: Wednesday, September 02, 1998 10:21 PM
> > >Subject: RE: What the straw poll means
> > >
> > >
> > >>Santosh doesn't seem to have answered the questions I've raised
> > >>regarding the definition of the domain, but he seems to believe
> that
> > >>option 2 doesn't solve that problem either.
> > >>
> > >>If so, I am increasingly beginning to lean towards "NONE OF THE
> > >>ABOVE".
> > >>
> > >>Rebuttal, Sharon/Carlisle?
> > >>
> > >>Bob
> > >>
> > >>>Yes Bob.  I hate to say this, but you have misinterpreted.
> > >>>
> > >>>The basic difference between the two approaches is the under
> option
> > 1
> > >>>you store a certificate only one time under a CA's entry.  Which
> > >>>certifying CA is in its domain is upto a subject CA to decide.
> > >>>
> > >>>In all honesty, I do not see a benefit to option 2 except for the
> > >>>argument that some installed base already does it this way.
> > >>>
> > >>>Option 1 achieves everything option 2 and with efficiency.
> > >>>
> > >>>I do not understand how option 2 solves your problems either.  We
> > need
> > >>>to have a discussion on computational complexity of path
> > development to
> > >>>allay your concerns.
> > >>>
> > >>>The way I look at the difference between the two options is that
> if
> > >>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1
> in
> > one
> > >>>bucket and n2 in another.  Option 2 says put n in one bucket and
> n1
> > in
> > >>>another.  When you retrieve the two buckets (which you must for
> > path
> > >>>development efficiency), option 2 gives you n+n1 certificates and
> > option
> > >>>1 gives you exactly all n.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Bob Jueneman [SMTP:[email-masked]]
> > >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> > >>>> To: [email-masked]
> > >>>> Cc: [email-masked]
> > >>>> Subject: What the straw poll means
> > >>>>
> > >>>> This is almost as exciting as watching a horse race!
> > >>>>
> > >>>> But what are we to make of the situation if the vote is as
> > >>>> close as it appears to be at present -- does that truly
> indicate
> > >>>> a "rough consensus"?
> > >>>>
> > >>>> As of earlier this morning, Chromatix was ahead, with
> > >>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> > >>>> cast; and MISSI some others are clustered around third place.
> > >>>>
> > >>>> So far, with the exception of a split between MISSI and NIST
> > >>>> as two US Government factions, the voting seems to be
> > >>>> strictly by company.
> > >>>>
> > >>>> Now, the polite fiction within the IETF is that memberships are
> > by
> > >>>> individual, and that there are no "votes" per se, and certainly
> > not
> > >>>> on a company by company basis. That's the fiction, at least..
> > >>>> Whether this convention shall long endure now that the IETF has
> > >>>> apparently lost some or all of its government funding and has
> > >>>> to become more self-sufficient will be interesting to see.
> > >>>>
> > >>>> But unless one side or the other starts to make some
> significant
> > >>>> in-roads by the dint of more persuasive technical argument,
> then
> > I
> > >>>> think
> > >>>> it's effectively a draw, and we may be counting companies and
> > their
> > >>>> installed base at least as much, and perhaps more, than
> > >>>> balancing the technical alternatives.
> > >>>>
> > >>>> Now, if we are truly at a technical impasse and the vote has to
> > be
> > >>>> binary, i.e., only one way or the other, then maybe counting
> > installed
> > >>>> clients and minimizing the pain is really the way to go, but
> > frankly
> > >>>> that approach makes me uncomfortable.  I want both
> > interoperability
> > >>>> AND efficiency, and I would hate to see us don't want to be
> > >>>> pressured into a less than satisfactory decision, whatever that
> > is,
> > >>>>  just because we are in a rush to get over the next hurdle in
> the
> > >>>> standards progression.
> > >>>>
> > >>>> I originally said that I was inclined to go with option 1,
> > because
> > >>>> it at least appeared to be simpler.  However, I also said that
> I
> > was
> > >>>> concerned about the "local" definition of a domain by a CA,
> > >>>> and the more I think about it, the more concerned I get.
> > >>>>
> > >>>> That approach might be viable for an organization such as
> MISSI,
> > >>>> where everyone presumably knows what community of interest
> > >>>> they fall into, but how would it apply to a public CA such as
> > >>>> VeriSign?
> > >>>>
> > >>>> Would they view all of their certificates as falling into one
> > domain,
> > >>>> including any certificates issued by subordinate CAs, as in the
> > case
> > >>>> of the old RSA Commercial hierarchy?
> > >>>>
> > >>>> What about GTE CyberTrust, considering their presumed affinity
> > >>>> with their ISP business. Would all of those certificates fall
> > into
> > >>>> one domain?
> > >>>>
> > >>>> Now suppose I want to validate a certificate from Erols.  Do I
> > decide
> > >>>> that
> > >>>> because Erols is in the top half of the alphabet that they
> > probably
> > >>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we
> do
> > an
> > >>>> East Coast/West Coast split, like radio and TV stations use W
> or
> > K in
> > >>>> their call sign?
> > >>>>
> > >>>> What if Novell and Microsoft were to become CAs and issue
> > certificates
> > >>>>
> > >>>> to their customers directly, at least their larger accounts.
> > Would
> > >>>> the relying
> > >>>> party have to try to divine whether a subscriber was running
> > NetWare
> > >>>> or
> > >>>> NT in order to decide what domain they would be likely to be
> in?
> > >>>>
> > >>>> Santosh, have I misrepresented the issue here?  Feel free to
> > correct
> > >>>> me, if so.
> > >>>> Maybe I just don't understand.
> > >>>>
> > >>>> Now, if the definition of "domain" were amended somewhat,
> perhaps
> > some
> > >>>> of these difficulties might go away.
> > >>>>
> > >>>> In particular, it seems to me that "domain" probably ought to
> > have a
> > >>>> lot to do
> > >>>> with name subordination, or at least the possibility of doing
> > name
> > >>>> subordination,
> > >>>> so that it would be deterministic.  That might not solve all of
> > the
> > >>>> concerns that those
> > >>>> who are inclined to vote for option 2 might have in mind, but
> it
> > might
> > >>>> help.
> > >>>>
> > >>>> So if I am a Novell employee, and I receive an S/MIME message
> > that
> > >>>> contains
> > >>>> a certificate that begins with c=US, o=Novell, I can probably
> > make an
> > >>>> excellent
> > >>>> good guess of what CA to go to, assuming that Novell operates a
> > CA in
> > >>>> its
> > >>>> own name.  But where do I go for a certificate from Acme
> > >>>> Manufacturing?
> > >>>>
> > >>>> I don't mean to beat up on the option 1 folks exclusively --
> > maybe
> > >>>> there are
> > >>>> some things that could be done within the options 2 that would
> > come
> > >>>> closer to a
> > >>>> compromise without breaking those existing clients.  But I need
> > to
> > >>>> think about that
> > >>>> some more.  maybe someone else could volunteer some
> suggestions.
> > >>>>
> > >>>> Bob
> > >>>>
> > >>>> Robert R. Jueneman
> > >>>> Novell, Inc.
> > >>>> 122 E. 1700 South
> > >>>> Provo, UT 84606
> > >>>> [email-masked]
> > >>>> 1-801-861-7387
> > >>
> > >>
> > >
> > >
> > Regards,
> > 
> > Bill Burr
> 

From: Santosh Chokhani <[email-masked]>
To: "'Carlisle Adams'" <[email-masked]>, [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw poll means)
Date: Thu, 3 Sep 1998 19:57:16 -0400
Sender: [email-masked]

> -----Original Message-----
> From:	Carlisle Adams [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 2:25 PM
> To:	[email-masked]
> Subject:	Let's try to understand the real issue (was... RE: What
> the straw poll means)
> 
> Hi all,
> 
> I propose that we try (once again) to understand what the real issue
> is
> here.
> 
> > ----------
> > From: 	Ryan Moats[SMTP:[email-masked]]
> > Sent: 	Thursday, September 03, 1998 12:14 PM
> > To: 	[email-masked]
> > Cc: 	[email-masked]
> > Subject: 	Retrieval efficiency herring? (was... RE: What the straw
> > poll means)
> > 
> > As somebody coming to the party late from the LDAP world, I don't
> see
> > why
> > the certificates need to be retrieved from two places.  An LDAP
> lookup
> > of an
> > object with a fairly simple filter (objectclass="*") will return all
> > of the
> > attributes associated with that object.  Therefore a single lookup
> > will return
> > both attributes, so I don't understand how retrieval efficiency is
> > gained.
> > 
> O.K., so we see that a single LDAP lookup can retrieve all
> certificates
> (which, after careful enumeration, was found to be "n") in either
> option
> 1 or option 2.
> 
	[]  If you only retrieve crossCertificatePair attribute under
option 2, you view the certificates of a single type and you lose path
development efficiency.

> The claimed advantage of option 1 is that this retrieval gets me
> certificates that are sorted into "intra-domain" and "inter-domain",
> which can help in efficient path construction.  Let's think about this
> for a moment.  The CA doing this sorting is, by definition, NOT
> DIRECTLY
> TRUSTED BY ME  (because if it was directly trusted by me, I would
> already have a trusted copy of its public key and would not need
> certificates in which it was the subject).  If it is not directly
> trusted by me, then why would I necessarily trust it to do this
> sorting
> in a way that is beneficial to my path construction needs?  How does
> it
> know what *my* definition of "domain" is?  How does it know whether
> most
> of my certificate validations will be "intra" its definition of domain
> or "inter" its definition of domain?
> 
> If this CA's definition of domain and my definition of domain do not
> coincide exactly (and why should they, since in general this CA and I
> have no pre-established relationship?), then this sorting performed by
> the CA is not merely useless to me, it is actually an explicit
> disadvantage (because the proponents of option 1 are recommending that
> all the intra-domain certificates be examined *before* the
> inter-domain
> certificates are examined, leading to worst-case path-construction
> times
> for what may turn out to be a common scenario).
> 
	[]  In these situations, you are no worse off than throwing the
certificates in one bucket.

> Relying parties know what certificates they will be validating most
> often, depending upon what particular activity they are engaged in at
> the moment.  THAT defines the relying parties' "intra" and "inter"
> domains.  CAs in the middle of a cert. path cannot possibly know this,
> in general, so having THEM define a domain and sort certificates
> according to that definition is really meaningless.
> 
	[]  This can be easily achieved using certificate and/or
certificate path caching.

> Note that there will be special circumstances in which one definition
> of
> domain will be understood throughout a given environment (e.g., the
> strict hierarchy of CAs has been cited in previous posts on this
> topic).
> In such cases there is a clear efficiency advantage to be gained in
> path
> construction.  This is why option 2 is the perfect compromise:  for
> such
> environments relying parties need only retrieve the n1 < n
> certificates
> that they *know* will be useful to them.  Option 2 therefore meets the
> needs of the general case as well as the special case, while
> simultaneously guaranteeing interoperability of two installed bases
> which would otherwise have no hope of interoperating today.
> 
> The price of this panacea?  A few redundant certificates in the
> Directory.  Is it really worth sacrificing the general- (and perhaps
> common-) case scenario, as well as interoperability, in order to save
> a
> few certificates and satisfy a particular special-case?  I haven't yet
> heard any convincing arguments...
> 
> Carlisle.

From: Santosh Chokhani <[email-masked]>
To: "'Nada Kapidzic Cicovic'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:53:00 -0400
Sender: [email-masked]

> -----Original Message-----
> From:	Nada Kapidzic Cicovic [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 5:03 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [email-masked]
> Cc:	Santosh Chokhani
> Subject:	RE: What the straw poll means
> 
> At 20:48 9/2/98 -0400, Santosh Chokhani wrote:
> >Yes Bob.  I hate to say this, but you have misinterpreted.
> >
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> >
> >Option 1 achieves everything option 2 and with efficiency.
> >
> >I do not understand how option 2 solves your problems either.  We
> need
> >to have a discussion on computational complexity of path development
> to
> >allay your concerns.
> >
> >The way I look at the difference between the two options is that if
> >n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> one
> >bucket and n2 in another.  Option 2 says put n in one bucket and n1
> in
> >another.  When you retrieve the two buckets (which you must for path
> >development efficiency), option 2 gives you n+n1 certificates and
> option
> >1 gives you exactly all n.
> 
> With option 2 you do not have to look at n1 certificates
> (cACertificate
> attribute) at all. The n ones (from crossCertificatePair) are
> sufficient
> for your path building.
> 
	[]  In that case you have potential for inefficiency in path
development.  

> Nada
> 
> >
> >> -----Original Message-----
> >> From:	Bob Jueneman [SMTP:[email-masked]]
> >> Sent:	Wednesday, September 02, 1998 8:33 PM
> >> To:	[email-masked]
> >> Cc:	[email-masked]
> >> Subject:	What the straw poll means
> >> 
> >> This is almost as exciting as watching a horse race!
> >> 
> >> But what are we to make of the situation if the vote is as 
> >> close as it appears to be at present -- does that truly indicate 
> >> a "rough consensus"?
> >> 
> >> As of earlier this morning, Chromatix was ahead, with 
> >> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
> >> cast; and MISSI some others are clustered around third place.
> >> 
> >> So far, with the exception of a split between MISSI and NIST
> >> as two US Government factions, the voting seems to be 
> >> strictly by company.
> >> 
> >> Now, the polite fiction within the IETF is that memberships are by
> >> individual, and that there are no "votes" per se, and certainly not
> 
> >> on a company by company basis. That's the fiction, at least.. 
> >> Whether this convention shall long endure now that the IETF has 
> >> apparently lost some or all of its government funding and has 
> >> to become more self-sufficient will be interesting to see.
> >> 
> >> But unless one side or the other starts to make some significant
> >> in-roads by the dint of more persuasive technical argument, then I
> >> think
> >> it's effectively a draw, and we may be counting companies and their
> 
> >> installed base at least as much, and perhaps more, than 
> >> balancing the technical alternatives.
> >> 
> >> Now, if we are truly at a technical impasse and the vote has to be 
> >> binary, i.e., only one way or the other, then maybe counting
> installed
> >> clients and minimizing the pain is really the way to go, but
> frankly 
> >> that approach makes me uncomfortable.  I want both interoperability
> >> AND efficiency, and I would hate to see us don't want to be 
> >> pressured into a less than satisfactory decision, whatever that is,
> >>  just because we are in a rush to get over the next hurdle in the 
> >> standards progression.
> >> 
> >> I originally said that I was inclined to go with option 1, because 
> >> it at least appeared to be simpler.  However, I also said that I
> was  
> >> concerned about the "local" definition of a domain by a CA,
> >> and the more I think about it, the more concerned I get.
> >> 
> >> That approach might be viable for an organization such as MISSI,
> >> where everyone presumably knows what community of interest 
> >> they fall into, but how would it apply to a public CA such as
> >> VeriSign?
> >> 
> >> Would they view all of their certificates as falling into one
> domain,
> >> including any certificates issued by subordinate CAs, as in the
> case
> >> of the old RSA Commercial hierarchy?
> >> 
> >> What about GTE CyberTrust, considering their presumed affinity
> >> with their ISP business. Would all of those certificates fall into
> >> one domain?
> >> 
> >> Now suppose I want to validate a certificate from Erols.  Do I
> decide
> >> that
> >> because Erols is in the top half of the alphabet that they probably
> 
> >> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
> 
> >> East Coast/West Coast split, like radio and TV stations use W or K
> in 
> >> their call sign?
> >> 
> >> What if Novell and Microsoft were to become CAs and issue
> certificates
> >> 
> >> to their customers directly, at least their larger accounts.  Would
> >> the relying 
> >> party have to try to divine whether a subscriber was running
> NetWare
> >> or
> >> NT in order to decide what domain they would be likely to be in?
> >> 
> >> Santosh, have I misrepresented the issue here?  Feel free to
> correct
> >> me, if so.
> >> Maybe I just don't understand.
> >> 
> >> Now, if the definition of "domain" were amended somewhat, perhaps
> some
> >> of these difficulties might go away.
> >> 
> >> In particular, it seems to me that "domain" probably ought to have
> a
> >> lot to do 
> >> with name subordination, or at least the possibility of doing name
> >> subordination, 
> >> so that it would be deterministic.  That might not solve all of the
> >> concerns that those
> >> who are inclined to vote for option 2 might have in mind, but it
> might
> >> help.
> >> 
> >> So if I am a Novell employee, and I receive an S/MIME message that
> >> contains 
> >> a certificate that begins with c=US, o=Novell, I can probably make
> an
> >> excellent 
> >> good guess of what CA to go to, assuming that Novell operates a CA
> in
> >> its 
> >> own name.  But where do I go for a certificate from Acme
> >> Manufacturing?
> >> 
> >> I don't mean to beat up on the option 1 folks exclusively -- maybe
> >> there are 
> >> some things that could be done within the options 2 that would come
> >> closer to a
> >> compromise without breaking those existing clients.  But I need to
> >> think about that
> >> some more.  maybe someone else could volunteer some suggestions.
> >> 
> >> Bob
> >> 
> >> Robert R. Jueneman
> >> Novell, Inc.
> >> 122 E. 1700 South
> >> Provo, UT 84606
> >> [email-masked]
> >> 1-801-861-7387
> >

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:50:58 -0400
Sender: [email-masked]

John:

As Dave Horvath has replied, retrieval efficiency is the same.

Option 2 also retrieves all multiple certificates and hence introduces
communication delays and unnecessary bandwidth usage.

Using option 2, if a client only retrieves crossCertificatePair
attribute only, it loses potential for efficiency.

Your last paragraph is precisely my point.  Dividing the certificates in
two buckets has potential for help and never hurts.

By the way, a class of application may choose to prefer exploring
inter-domain certificates first, if so deemed.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 8:51 AM
> To:	Santosh Chokhani
> Cc:	[email-masked]
> Subject:	RE: What the straw poll means
> 
> Santosh Chokhani <[email-masked]> writes:
> 
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> 
> The difference between the two options is primarily storage efficiency
> vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing
> only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
> 
>    whether you care more about storage efficiency in the directory
> (option
>    2 stores intra-domain certificates twice) or retrieval efficiency
> for
>    the verifier (option 1 require a verifier that wants all a target
> CA's
>    certificates to retrieve them from two places).
>    typical usage scenarios by verifiers - i.e. the percentage of
> clients
>    that are going to want to locate just inter-domain certs, compared
> to
>    clients that either don't care about the difference or are only
>    interested in intra-domain certs.  Retrieval of _just_ inter-domain
>    certs is easier under option 1, retrieval of _all_ certs is easier
> under
>    option 2, and retrieval of _just_ intra-domain certs is the same
> under
>    both options.
> 
> 
> Consider a fairly randomly structured PKI, where the verifier has a
> set of
> trusted roots loaded into it (assume they've been loaded under user
> control, with no particular order to them), and is trying to verify
> the key
> of some server that it hasn't spoken to before.  It has no idea of
> which
> "domain" the target's CA thinks it belongs to; it just wants to pull
> all
> the certs that have that CA as a subject, and see if it can construct
> a
> valid chain starting at one of its trusted roots.
> 
> Having the target CA divide its certificates between two places within
> the
> directory is no help to this verifier.  All it does it force the
> verifier
> to make two retrieval operations instead of the one that would be
> required
> by option 2.  The verifier isn't really interested in whether a
> particular
> certificate comes from another CA from the same "domain" as the
> target's CA
> - if it cares about "domains" at all, what it would be interested in
> is if
> any certs come from the same domain as the verifier (or one of its
> trusted
> roots), not the target (and of course that's verifier-specific).
> 
> For the special (and probably quite common) case where the verifier
> and
> target happen to be in the same domain, the distinction probably is
> useful.
> Option 2 supports this case just as well as does option 1, by allowing
> the
> CA to place intra-domain certs in a separate place so that clients in
> that
> domain can retrieve them first (or possibly even _instead_of_ going to
> the
> all-certs list).
> 
> John
> 

From: John Everson <[email-masked]>
Date: Thu, 3 Sep 1998 09:52:26 -0500
Subject: RE: What the straw poll means
TO: [email-masked], [email-masked]
CC: [email-masked]
Sender: [email-masked]

--openmail-part-0ef743e1-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.TXT"

Does this mean there will be a new option (3):

container/pile of intra-domain certs
container/pile of inter-domain certs
container/pile of all certs

Or do we throw everything into one container and offer a different 
mechanism for distinction?

-----Original Message-----
From: John.Wray [mailto:[email-masked]]
Sent: Thursday, September 03, 1998 7:51 AM
To: chokhani
Cc: John.Wray; ietf-pkix
Subject: RE: What the straw poll means

Santosh Chokhani <[email-masked]> writes:

>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.

The difference between the two options is primarily storage efficiency 
vs.
retrieval efficiency.  Both options divide a CAs certs into two piles.
Option 1 has pile A containing only intra-domain certs, and pile B
containing only inter-domain certs; option 2 has pile A containing only
intra-domain certs and pite B containing all certs.  Which option is
superior depends on two things:

   whether you care more about storage efficiency in the directory 
(option
   2 stores intra-domain certificates twice) or retrieval efficiency for
   the verifier (option 1 require a verifier that wants all a target 
CA's
   certificates to retrieve them from two places).
   typical usage scenarios by verifiers - i.e. the percentage of clients
   that are going to want to locate just inter-domain certs, compared to
   clients that either don't care about the difference or are only
   interested in intra-domain certs.  Retrieval of _just_ inter-domain
   certs is easier under option 1, retrieval of _all_ certs is easier 
under
   option 2, and retrieval of _just_ intra-domain certs is the same 
under
   both options.

Consider a fairly randomly structured PKI, where the verifier has a set 
of
trusted roots loaded into it (assume they've been loaded under user
control, with no particular order to them), and is trying to verify the 
key
of some server that it hasn't spoken to before.  It has no idea of which
"domain" the target's CA thinks it belongs to; it just wants to pull all
the certs that have that CA as a subject, and see if it can construct a
valid chain starting at one of its trusted roots.

Having the target CA divide its certificates between two places within 
the
directory is no help to this verifier.  All it does it force the 
verifier
to make two retrieval operations instead of the one that would be 
required
by option 2.  The verifier isn't really interested in whether a 
particular
certificate comes from another CA from the same "domain" as the 
target's CA
- if it cares about "domains" at all, what it would be interested in is 
if
any certs come from the same domain as the verifier (or one of its 
trusted
roots), not the target (and of course that's verifier-specific).

For the special (and probably quite common) case where the verifier and
target happen to be in the same domain, the distinction probably is 
useful.
Option 2 supports this case just as well as does option 1, by allowing 
the
CA to place intra-domain certs in a separate place so that clients in 
that
domain can retrieve them first (or possibly even _instead_of_ going to 
the
all-certs list).

John

--openmail-part-0ef743e1-00000001--

Date: Thu, 3 Sep 1998 11:27:34 -0500
Subject: Option 2
FROM: GIUBILEO/unix////////RFC-822/[email-masked]
TO: [email-masked]
Sender: [email-masked]

--openmail-part-0ef92b5d-00000001
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.RTF"

+++++++++++++++++++++++++++++++++++++++++++
John P. Giubileo         
Director IP Security Services
Sprint Corporate Security
Phone: 913.624.4796
[email-masked]
[PICTURE]

--openmail-part-0ef92b5d-00000001--

From: John Everson <[email-masked]>
Date: Thu, 3 Sep 1998 11:20:00 -0500
Subject: Voting Question
TO: [email-masked]
Sender: [email-masked]

--openmail-part-0ef90993-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.TXT"

Are the votes being compared against the "team member list"?

--openmail-part-0ef90993-00000001--

From: Sharon Boeyen <[email-masked]>
To: Bill Burr <[email-masked]>, "'Dave Horvath'" <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:38:06 +0100
Sender: [email-masked]

	I believe we already have the compromise solution on the table.
Option 1 in this straw poll is one end of the spectrum and the text
currently in the Internet Draft is the other end of the spectrum. Option
2 in this straw poll is the compromise that :

	a) provides a single place to find all certificates that a CA
has issued to other CAs and that have been issued to that CA
	b) allows the use of a locally defined 'domain' specific set of
certificates to 
	    be easily retrieved by any relying parties that happen to
understand and
	    prefer that set of certificates
	c) enables existing client systems which implement option 1 as
well as those 
	    that implement the current Internet Draft to continue
without change
	d) provides interoperability by allowing the directory entries
of CAs which use 
	    the proposal in option 1 AND entries of CAs which use the
interpretation as per the current Internet Draft text to be used by
client systems of either type

> ----------
> From: 	Dave Horvath[SMTP:[email-masked]]
> Sent: 	September 3, 1998 2:14 PM
> To: 	Bill Burr
> Cc: 	[email-masked]
> Subject: 	Re: What the straw poll means
> 
> 
> 
>     I understand the problems Bill is having with the definitions of
> roots
> and domains.  I think we are all  having those problems.  It seems
> that
> roughly half of the people I communicated with are concerned with the
> definitions and feel that population of all the cACertificates in one
> attribute may help.   I personally do not feel this helps, however we
> should
> all be interested in a compromise to keep things moving and to keep
> both
> sides happy.
> 
>     I must admit that I like the idea of being able to go to one place
> in
> the directory to find all certificates that a CA has issued (I believe
> Stefan pointed this out).  It appears that populating all CA
> certificates in
> the reverse component of the crossCertificatePair attribute solves
> this
> requirement and does not duplicate certs in a single CAs entry.  This
> gives
> clients that work in a forward direction the ability to determine all
> of the
> certificates that a CA has issued.  This type of population is clearly
> mandated by option 2 and only allowed by option 1.  Option 1 does not
> mandate it.   This type of population avoids duplication of
> certificates in
> a single CA entry (they are duplicated in subordinate, mesh, cross
> whatever), but seems to be advantageous from a clients point of view.
> 
>     Would populating the reverse component with all issued CA
> certificates
> provide a compromise that supports a single attribute to retrieve all
> certs?
> Would this help with the installed base issue?
> 
> Dave Horvath
> 
> 
> -----Original Message-----
> From: Bill Burr <[email-masked]>
> To: Dave Horvath <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> Date: Thursday, September 03, 1998 12:44 PM
> Subject: Re: What the straw poll means
> 
> 
> >But what is a root here?  Does it imply that a domain is PKI
> hierarchy?  I
> >can think of 3 plausible constructions of root, all of which I
> believe I've
> >seen used:
> >
> >(1) any CA whose key you choose to trust and therefore can start a
> >certification path, but which may not imply any other organization or
> >structure;
> >
> >(2) a CA whose key everybody in the domain (what's a domain?) trusts
> and
> >which sits on top of a hierarchical unidirectional certification tree
> (as
> >in MISSI or PEM);
> >
> >(3) a CA that exists to cross-certify with other CAs, but issues few
> or no
> >end entity certificates, and starts few or no certification paths; it
> >simply exists to connect other CAs.  Examples would be the ANX
> "supervisory
> >CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
> >Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is
> often
> >depicted at the hub of a mesh, or the top of a hierarchy, and
> operated in
> >conjunction with the overall domain policy management authority.
> >
> >
> >I suppose a "trusted root" can be either 1 or 2 above.
> >
> >But "root" to me doesn't necessarily say much about path development,
> or
> >PKI certification path structure.
> >
> >How about domain? What does it mean?  I claim that the term makes
> most
> >sense to mean a part of a PKI that operates under the direction of a
> policy
> >management entity. Which wouldn't necessarily mean that domain
> boundaries
> >coincide with distinctions that are meaningful for certification path
> >building.
> >
> >Option 1 is probably useful if you think that a domain is  everything
> >subordinate to the same root CA, where a root is any CA that somebody
> uses
> >to start a trust path.  So in a cross-certified mesh PKI, every CA is
> a
> >domain onto itself, and all CA certificates wind up only, I think, in
> the
> >crossCertificatePair attribute.  But in a hierarchical PKI most
> >certificates wind up in the cACertificate Attribute.
> >
> >I have the feeling that Bob is right at least for option 1, unless we
> know
> >what a domain is we hardly know what we are getting.  With option 2,
> I
> >suppose we are guaranteed that all certificates wind up in
> >crossCertificatePair, whatever domain means.
> >
> >At 11:14 AM 9/3/98 -0400, you wrote:
> >>Bob,
> >>
> >>    I feel that the definition of domain is a local policy and that
> CAs
> >>should be free to define it as they wish.   Clients  that
> search/read CAs
> >>entries and obtain the values from both the cACertificate and
> >>crossCertificatePair attributes can explore the values in the
> cACertficate
> >>attribute first.  If a path to the trusted root is found, processing
> stops.
> >>If not, they can explore the crossCertificatePair attribute.  Using
> this
> >>algorithm CAs can define their domain and post each of their CA
> certificates
> >>to one attribute or the other.  The only adverse affect will be
> efficiency
> >>in path development  on the client side if the CA does not carefully
> select
> >>intra or inter domain.  WIth option 1, the certificates are not
> duplicated.
> >>With option 2, they are.
> >>
> >>But if we have an installed base that only looks in the
> crossCertificatePair
> >>attribute, then we have a problem.  In that case option 2 will help
> at the
> >>expense of duplicating the data.   I suggest we avoid duplication if
> >>possible, but we certainly must evaluate the installed base.
> >>
> >>Dave Horvath
> >>
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: Bob Jueneman <[email-masked]>
> >>To: [email-masked] <[email-masked]>; [email-masked]
> >><[email-masked]>
> >>Date: Wednesday, September 02, 1998 10:21 PM
> >>Subject: RE: What the straw poll means
> >>
> >>
> >>>Santosh doesn't seem to have answered the questions I've raised
> >>>regarding the definition of the domain, but he seems to believe
> that
> >>>option 2 doesn't solve that problem either.
> >>>
> >>>If so, I am increasingly beginning to lean towards "NONE OF THE
> >>>ABOVE".
> >>>
> >>>Rebuttal, Sharon/Carlisle?
> >>>
> >>>Bob
> >>>
> >>>>Yes Bob.  I hate to say this, but you have misinterpreted.
> >>>>
> >>>>The basic difference between the two approaches is the under
> option 1
> >>>>you store a certificate only one time under a CA's entry.  Which
> >>>>certifying CA is in its domain is upto a subject CA to decide.
> >>>>
> >>>>In all honesty, I do not see a benefit to option 2 except for the
> >>>>argument that some installed base already does it this way.
> >>>>
> >>>>Option 1 achieves everything option 2 and with efficiency.
> >>>>
> >>>>I do not understand how option 2 solves your problems either.  We
> need
> >>>>to have a discussion on computational complexity of path
> development to
> >>>>allay your concerns.
> >>>>
> >>>>The way I look at the difference between the two options is that
> if
> >>>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1
> in one
> >>>>bucket and n2 in another.  Option 2 says put n in one bucket and
> n1 in
> >>>>another.  When you retrieve the two buckets (which you must for
> path
> >>>>development efficiency), option 2 gives you n+n1 certificates and
> option
> >>>>1 gives you exactly all n.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Bob Jueneman [SMTP:[email-masked]]
> >>>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>>> To: [email-masked]
> >>>>> Cc: [email-masked]
> >>>>> Subject: What the straw poll means
> >>>>>
> >>>>> This is almost as exciting as watching a horse race!
> >>>>>
> >>>>> But what are we to make of the situation if the vote is as
> >>>>> close as it appears to be at present -- does that truly indicate
> >>>>> a "rough consensus"?
> >>>>>
> >>>>> As of earlier this morning, Chromatix was ahead, with
> >>>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> >>>>> cast; and MISSI some others are clustered around third place.
> >>>>>
> >>>>> So far, with the exception of a split between MISSI and NIST
> >>>>> as two US Government factions, the voting seems to be
> >>>>> strictly by company.
> >>>>>
> >>>>> Now, the polite fiction within the IETF is that memberships are
> by
> >>>>> individual, and that there are no "votes" per se, and certainly
> not
> >>>>> on a company by company basis. That's the fiction, at least..
> >>>>> Whether this convention shall long endure now that the IETF has
> >>>>> apparently lost some or all of its government funding and has
> >>>>> to become more self-sufficient will be interesting to see.
> >>>>>
> >>>>> But unless one side or the other starts to make some significant
> >>>>> in-roads by the dint of more persuasive technical argument, then
> I
> >>>>> think
> >>>>> it's effectively a draw, and we may be counting companies and
> their
> >>>>> installed base at least as much, and perhaps more, than
> >>>>> balancing the technical alternatives.
> >>>>>
> >>>>> Now, if we are truly at a technical impasse and the vote has to
> be
> >>>>> binary, i.e., only one way or the other, then maybe counting
> installed
> >>>>> clients and minimizing the pain is really the way to go, but
> frankly
> >>>>> that approach makes me uncomfortable.  I want both
> interoperability
> >>>>> AND efficiency, and I would hate to see us don't want to be
> >>>>> pressured into a less than satisfactory decision, whatever that
> is,
> >>>>>  just because we are in a rush to get over the next hurdle in
> the
> >>>>> standards progression.
> >>>>>
> >>>>> I originally said that I was inclined to go with option 1,
> because
> >>>>> it at least appeared to be simpler.  However, I also said that I
> was
> >>>>> concerned about the "local" definition of a domain by a CA,
> >>>>> and the more I think about it, the more concerned I get.
> >>>>>
> >>>>> That approach might be viable for an organization such as MISSI,
> >>>>> where everyone presumably knows what community of interest
> >>>>> they fall into, but how would it apply to a public CA such as
> >>>>> VeriSign?
> >>>>>
> >>>>> Would they view all of their certificates as falling into one
> domain,
> >>>>> including any certificates issued by subordinate CAs, as in the
> case
> >>>>> of the old RSA Commercial hierarchy?
> >>>>>
> >>>>> What about GTE CyberTrust, considering their presumed affinity
> >>>>> with their ISP business. Would all of those certificates fall
> into
> >>>>> one domain?
> >>>>>
> >>>>> Now suppose I want to validate a certificate from Erols.  Do I
> decide
> >>>>> that
> >>>>> because Erols is in the top half of the alphabet that they
> probably
> >>>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do
> an
> >>>>> East Coast/West Coast split, like radio and TV stations use W or
> K in
> >>>>> their call sign?
> >>>>>
> >>>>> What if Novell and Microsoft were to become CAs and issue
> certificates
> >>>>>
> >>>>> to their customers directly, at least their larger accounts.
> Would
> >>>>> the relying
> >>>>> party have to try to divine whether a subscriber was running
> NetWare
> >>>>> or
> >>>>> NT in order to decide what domain they would be likely to be in?
> >>>>>
> >>>>> Santosh, have I misrepresented the issue here?  Feel free to
> correct
> >>>>> me, if so.
> >>>>> Maybe I just don't understand.
> >>>>>
> >>>>> Now, if the definition of "domain" were amended somewhat,
> perhaps some
> >>>>> of these difficulties might go away.
> >>>>>
> >>>>> In particular, it seems to me that "domain" probably ought to
> have a
> >>>>> lot to do
> >>>>> with name subordination, or at least the possibility of doing
> name
> >>>>> subordination,
> >>>>> so that it would be deterministic.  That might not solve all of
> the
> >>>>> concerns that those
> >>>>> who are inclined to vote for option 2 might have in mind, but it
> might
> >>>>> help.
> >>>>>
> >>>>> So if I am a Novell employee, and I receive an S/MIME message
> that
> >>>>> contains
> >>>>> a certificate that begins with c=US, o=Novell, I can probably
> make an
> >>>>> excellent
> >>>>> good guess of what CA to go to, assuming that Novell operates a
> CA in
> >>>>> its
> >>>>> own name.  But where do I go for a certificate from Acme
> >>>>> Manufacturing?
> >>>>>
> >>>>> I don't mean to beat up on the option 1 folks exclusively --
> maybe
> >>>>> there are
> >>>>> some things that could be done within the options 2 that would
> come
> >>>>> closer to a
> >>>>> compromise without breaking those existing clients.  But I need
> to
> >>>>> think about that
> >>>>> some more.  maybe someone else could volunteer some suggestions.
> >>>>>
> >>>>> Bob
> >>>>>
> >>>>> Robert R. Jueneman
> >>>>> Novell, Inc.
> >>>>> 122 E. 1700 South
> >>>>> Provo, UT 84606
> >>>>> [email-masked]
> >>>>> 1-801-861-7387
> >>>
> >>>
> >>
> >>
> >Regards,
> >
> >Bill Burr
> >
> 

From: Santosh Chokhani <[email-masked]>
To: "'Bill Burr'" <[email-masked]>, Dave Horvath <[email-masked]>
Cc: [email-masked]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:41:37 -0400
Sender: [email-masked]

Bill, 

But under option 1 also all certificates are there since LAP gives you
all the attributes.

All option 1 does is reduce the communication load, processing load,
storage load and provide you a potential for efficiency.  With very,
very little software complexity, you have a potential for gaining a lot
on the computational complexity.

> -----Original Message-----
> From:	Bill Burr [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 12:48 PM
> To:	Dave Horvath
> Cc:	[email-masked]
> Subject:	Re: What the straw poll means
> 
> But what is a root here?  Does it imply that a domain is PKI
> hierarchy?  I
> can think of 3 plausible constructions of root, all of which I believe
> I've
> seen used: 
> 
> (1) any CA whose key you choose to trust and therefore can start a
> certification path, but which may not imply any other organization or
> structure;
> 
> (2) a CA whose key everybody in the domain (what's a domain?) trusts
> and
> which sits on top of a hierarchical unidirectional certification tree
> (as
> in MISSI or PEM);
> 
> (3) a CA that exists to cross-certify with other CAs, but issues few
> or no
> end entity certificates, and starts few or no certification paths; it
> simply exists to connect other CAs.  Examples would be the ANX
> "supervisory
> CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
> Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is often
> depicted at the hub of a mesh, or the top of a hierarchy, and operated
> in
> conjunction with the overall domain policy management authority.
> 
> 
> I suppose a "trusted root" can be either 1 or 2 above.
> 
> But "root" to me doesn't necessarily say much about path development,
> or
> PKI certification path structure.
> 
> How about domain? What does it mean?  I claim that the term makes most
> sense to mean a part of a PKI that operates under the direction of a
> policy
> management entity. Which wouldn't necessarily mean that domain
> boundaries
> coincide with distinctions that are meaningful for certification path
> building.
> 
> Option 1 is probably useful if you think that a domain is  everything
> subordinate to the same root CA, where a root is any CA that somebody
> uses
> to start a trust path.  So in a cross-certified mesh PKI, every CA is
> a
> domain onto itself, and all CA certificates wind up only, I think, in
> the
> crossCertificatePair attribute.  But in a hierarchical PKI most
> certificates wind up in the cACertificate Attribute.  
> 
> I have the feeling that Bob is right at least for option 1, unless we
> know
> what a domain is we hardly know what we are getting.  With option 2, I
> suppose we are guaranteed that all certificates wind up in
> crossCertificatePair, whatever domain means.  
> 
> At 11:14 AM 9/3/98 -0400, you wrote:
> >Bob,
> >
> >    I feel that the definition of domain is a local policy and that
> CAs
> >should be free to define it as they wish.   Clients  that search/read
> CAs
> >entries and obtain the values from both the cACertificate and
> >crossCertificatePair attributes can explore the values in the
> cACertficate
> >attribute first.  If a path to the trusted root is found, processing
> stops.
> >If not, they can explore the crossCertificatePair attribute.  Using
> this
> >algorithm CAs can define their domain and post each of their CA
> certificates
> >to one attribute or the other.  The only adverse affect will be
> efficiency
> >in path development  on the client side if the CA does not carefully
> select
> >intra or inter domain.  WIth option 1, the certificates are not
> duplicated.
> >With option 2, they are.
> >
> >But if we have an installed base that only looks in the
> crossCertificatePair
> >attribute, then we have a problem.  In that case option 2 will help
> at the
> >expense of duplicating the data.   I suggest we avoid duplication if
> >possible, but we certainly must evaluate the installed base.
> >
> >Dave Horvath
> >
> >
> >
> >
> >-----Original Message-----
> >From: Bob Jueneman <[email-masked]>
> >To: [email-masked] <[email-masked]>; [email-masked]
> ><[email-masked]>
> >Date: Wednesday, September 02, 1998 10:21 PM
> >Subject: RE: What the straw poll means
> >
> >
> >>Santosh doesn't seem to have answered the questions I've raised
> >>regarding the definition of the domain, but he seems to believe that
> >>option 2 doesn't solve that problem either.
> >>
> >>If so, I am increasingly beginning to lean towards "NONE OF THE
> >>ABOVE".
> >>
> >>Rebuttal, Sharon/Carlisle?
> >>
> >>Bob
> >>
> >>>Yes Bob.  I hate to say this, but you have misinterpreted.
> >>>
> >>>The basic difference between the two approaches is the under option
> 1
> >>>you store a certificate only one time under a CA's entry.  Which
> >>>certifying CA is in its domain is upto a subject CA to decide.
> >>>
> >>>In all honesty, I do not see a benefit to option 2 except for the
> >>>argument that some installed base already does it this way.
> >>>
> >>>Option 1 achieves everything option 2 and with efficiency.
> >>>
> >>>I do not understand how option 2 solves your problems either.  We
> need
> >>>to have a discussion on computational complexity of path
> development to
> >>>allay your concerns.
> >>>
> >>>The way I look at the difference between the two options is that if
> >>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> one
> >>>bucket and n2 in another.  Option 2 says put n in one bucket and n1
> in
> >>>another.  When you retrieve the two buckets (which you must for
> path
> >>>development efficiency), option 2 gives you n+n1 certificates and
> option
> >>>1 gives you exactly all n.
> >>>
> >>>> -----Original Message-----
> >>>> From: Bob Jueneman [SMTP:[email-masked]]
> >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>> To: [email-masked]
> >>>> Cc: [email-masked]
> >>>> Subject: What the straw poll means
> >>>>
> >>>> This is almost as exciting as watching a horse race!
> >>>>
> >>>> But what are we to make of the situation if the vote is as
> >>>> close as it appears to be at present -- does that truly indicate
> >>>> a "rough consensus"?
> >>>>
> >>>> As of earlier this morning, Chromatix was ahead, with
> >>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> >>>> cast; and MISSI some others are clustered around third place.
> >>>>
> >>>> So far, with the exception of a split between MISSI and NIST
> >>>> as two US Government factions, the voting seems to be
> >>>> strictly by company.
> >>>>
> >>>> Now, the polite fiction within the IETF is that memberships are
> by
> >>>> individual, and that there are no "votes" per se, and certainly
> not
> >>>> on a company by company basis. That's the fiction, at least..
> >>>> Whether this convention shall long endure now that the IETF has
> >>>> apparently lost some or all of its government funding and has
> >>>> to become more self-sufficient will be interesting to see.
> >>>>
> >>>> But unless one side or the other starts to make some significant
> >>>> in-roads by the dint of more persuasive technical argument, then
> I
> >>>> think
> >>>> it's effectively a draw, and we may be counting companies and
> their
> >>>> installed base at least as much, and perhaps more, than
> >>>> balancing the technical alternatives.
> >>>>
> >>>> Now, if we are truly at a technical impasse and the vote has to
> be
> >>>> binary, i.e., only one way or the other, then maybe counting
> installed
> >>>> clients and minimizing the pain is really the way to go, but
> frankly
> >>>> that approach makes me uncomfortable.  I want both
> interoperability
> >>>> AND efficiency, and I would hate to see us don't want to be
> >>>> pressured into a less than satisfactory decision, whatever that
> is,
> >>>>  just because we are in a rush to get over the next hurdle in the
> >>>> standards progression.
> >>>>
> >>>> I originally said that I was inclined to go with option 1,
> because
> >>>> it at least appeared to be simpler.  However, I also said that I
> was
> >>>> concerned about the "local" definition of a domain by a CA,
> >>>> and the more I think about it, the more concerned I get.
> >>>>
> >>>> That approach might be viable for an organization such as MISSI,
> >>>> where everyone presumably knows what community of interest
> >>>> they fall into, but how would it apply to a public CA such as
> >>>> VeriSign?
> >>>>
> >>>> Would they view all of their certificates as falling into one
> domain,
> >>>> including any certificates issued by subordinate CAs, as in the
> case
> >>>> of the old RSA Commercial hierarchy?
> >>>>
> >>>> What about GTE CyberTrust, considering their presumed affinity
> >>>> with their ISP business. Would all of those certificates fall
> into
> >>>> one domain?
> >>>>
> >>>> Now suppose I want to validate a certificate from Erols.  Do I
> decide
> >>>> that
> >>>> because Erols is in the top half of the alphabet that they
> probably
> >>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do
> an
> >>>> East Coast/West Coast split, like radio and TV stations use W or
> K in
> >>>> their call sign?
> >>>>
> >>>> What if Novell and Microsoft were to become CAs and issue
> certificates
> >>>>
> >>>> to their customers directly, at least their larger accounts.
> Would
> >>>> the relying
> >>>> party have to try to divine whether a subscriber was running
> NetWare
> >>>> or
> >>>> NT in order to decide what domain they would be likely to be in?
> >>>>
> >>>> Santosh, have I misrepresented the issue here?  Feel free to
> correct
> >>>> me, if so.
> >>>> Maybe I just don't understand.
> >>>>
> >>>> Now, if the definition of "domain" were amended somewhat, perhaps
> some
> >>>> of these difficulties might go away.
> >>>>
> >>>> In particular, it seems to me that "domain" probably ought to
> have a
> >>>> lot to do
> >>>> with name subordination, or at least the possibility of doing
> name
> >>>> subordination,
> >>>> so that it would be deterministic.  That might not solve all of
> the
> >>>> concerns that those
> >>>> who are inclined to vote for option 2 might have in mind, but it
> might
> >>>> help.
> >>>>
> >>>> So if I am a Novell employee, and I receive an S/MIME message
> that
> >>>> contains
> >>>> a certificate that begins with c=US, o=Novell, I can probably
> make an
> >>>> excellent
> >>>> good guess of what CA to go to, assuming that Novell operates a
> CA in
> >>>> its
> >>>> own name.  But where do I go for a certificate from Acme
> >>>> Manufacturing?
> >>>>
> >>>> I don't mean to beat up on the option 1 folks exclusively --
> maybe
> >>>> there are
> >>>> some things that could be done within the options 2 that would
> come
> >>>> closer to a
> >>>> compromise without breaking those existing clients.  But I need
> to
> >>>> think about that
> >>>> some more.  maybe someone else could volunteer some suggestions.
> >>>>
> >>>> Bob
> >>>>
> >>>> Robert R. Jueneman
> >>>> Novell, Inc.
> >>>> 122 E. 1700 South
> >>>> Provo, UT 84606
> >>>> [email-masked]
> >>>> 1-801-861-7387
> >>
> >>
> >
> >
> Regards,
> 
> Bill Burr

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Carlisle Adams <[email-masked]>, [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw poll means)
Date: Thu, 3 Sep 1998 19:28:59 -0400
Sender: [email-masked]

Actually your arguments heavily favor option 1.  You state that since
the request will retrieve all the certificates, there is no need to
retrieve n1+n2+n1 certificates when n1 will do.

So, that is the first point of efficiency.

Now, the second point of efficiency is that these certificate come as
different type (let us call them red and green) in option 1.  In option
2, these have to be separated.

The third point of efficiency is that an application can select which
type of link to pursue red or green.  At the risk of being redundant, CA
does not preordain that.  It is up to the application.  For a given
relying party, this could vary from application type to application
type.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, September 03, 1998 5:09 PM
> To:	Carlisle Adams; [email-masked]
> Subject:	Re: Let's try to understand the real issue (was... RE:
> What the straw poll means)
> 
> Call me slow, but I don't follow the argument the whole way...
> 
> | Hi all,
> | 
> | I propose that we try (once again) to understand what the real issue
> is
> | here.
> | 
> | > As somebody coming to the party late from the LDAP world, I don't
> see
> | > why
> | > the certificates need to be retrieved from two places.  An LDAP
> lookup
> | > of an
> | > object with a fairly simple filter (objectclass="*") will return
> all
> | > of the
> | > attributes associated with that object.  Therefore a single lookup
> | > will return
> | > both attributes, so I don't understand how retrieval efficiency is
> | > gained.
> | > 
> | O.K., so we see that a single LDAP lookup can retrieve all
> certificates
> | (which, after careful enumeration, was found to be "n") in either
> option
> | 1 or option 2.
> | 
> | The claimed advantage of option 1 is that this retrieval gets me
> | certificates that are sorted into "intra-domain" and "inter-domain",
> | which can help in efficient path construction.  Let's think about
> this
> | for a moment.  The CA doing this sorting is, by definition, NOT
> DIRECTLY
> | TRUSTED BY ME  (because if it was directly trusted by me, I would
> | already have a trusted copy of its public key and would not need
> | certificates in which it was the subject).  If it is not directly
> | trusted by me, then why would I necessarily trust it to do this
> sorting
> | in a way that is beneficial to my path construction needs?  How does
> it
> | know what *my* definition of "domain" is?  How does it know whether
> most
> | of my certificate validations will be "intra" its definition of
> domain
> | or "inter" its definition of domain?
> 
> I follow this portion of the argument...
> 
> | If this CA's definition of domain and my definition of domain do not
> | coincide exactly (and why should they, since in general this CA and
> I
> | have no pre-established relationship?), then this sorting performed
> by
> | the CA is not merely useless to me, it is actually an explicit
> | disadvantage (because the proponents of option 1 are recommending
> that
> | all the intra-domain certificates be examined *before* the
> inter-domain
> | certificates are examined, leading to worst-case path-construction
> times
> | for what may turn out to be a common scenario).
> 
> I don't see that falling out of the Option 1 text as I read the
> straw poll message.  If such is the case, then I would say that text
> should be present.
> 
> | Relying parties know what certificates they will be validating most
> | often, depending upon what particular activity they are engaged in
> at
> | the moment.  THAT defines the relying parties' "intra" and "inter"
> | domains.  CAs in the middle of a cert. path cannot possibly know
> this,
> | in general, so having THEM define a domain and sort certificates
> | according to that definition is really meaningless.
> 
> Agreed.
> 
> | Note that there will be special circumstances in which one
> definition of
> | domain will be understood throughout a given environment (e.g., the
> | strict hierarchy of CAs has been cited in previous posts on this
> topic).
> | In such cases there is a clear efficiency advantage to be gained in
> path
> | construction.  This is why option 2 is the perfect compromise:  for
> such
> | environments relying parties need only retrieve the n1 < n
> certificates
> | that they *know* will be useful to them.  Option 2 therefore meets
> the
> | needs of the general case as well as the special case, while
> | simultaneously guaranteeing interoperability of two installed bases
> | which would otherwise have no hope of interoperating today.
> 
> Stop. Here's where I really fall off the wagon. How does the relying
> party
> retrieve ONLY the n1 certificates that they know will be useful to
> them for
> a CA?  I can see retrieving the CA object from the directory (which
> unless
> you do something real clever will have ALL certificates independent of
> which
> option is chosen) and then doing your own sorting, but I don't see how
> CA 
> "presorting" is going to make a difference, because ALL certificates
> will
> be there.
> 
> | The price of this panacea?  A few redundant certificates in the
> | Directory.  Is it really worth sacrificing the general- (and perhaps
> | common-) case scenario, as well as interoperability, in order to
> save a
> | few certificates and satisfy a particular special-case?  I haven't
> yet
> | heard any convincing arguments...
> 
> Well, I'm not convinced of your argument here the other way (other
> than
> the interoperability consideration), but that's what e-mail is for :-)
> 
> My current reasoning is that given that a single LDAP lookup is going
> to 
> return ALL of the certificates independent of the option chosen, the
> client
> is going to have to process those certificates to build its path.
> Since
> this begins to look like a wash in terms of client complexity (yes,
> yes, this is where interoperability shows up), why not argue for
> the choice that conserves directory space?
> 
> Ryan
> 
> P.S.  I'm really beginning to like the original text, given that the
> concept of a "domain" is looking more and more useless (causing
> confusion
> and concern without appreciable positive points) in this discussion.

From: "Tuttle, Kimberly (OSSC)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2.
Date: Thu, 3 Sep 1998 16:10:29 -0700 
Sender: [email-masked]

From: "Evans,  Jim (OSSC)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 15:52:45 -0700 
Sender: [email-masked]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Evans
Frank Russell Company

Security is what YOU Practice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Let's try to understand the real issue (was... RE: What the s traw poll means)
Date: Thu, 3 Sep 1998 23:05:31 +0100
Sender: [email-masked]

Hi Ryan,

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Thursday, September 03, 1998 5:09 PM
> To: 	Carlisle Adams; [email-masked]
> Subject: 	Re: Let's try to understand the real issue (was... RE:
> What the straw poll means)
> 
> Call me slow, but I don't follow the argument the whole way...
> 
> | If this CA's definition of domain and my definition of domain do not
> | coincide exactly (and why should they, since in general this CA and
> I
> | have no pre-established relationship?), then this sorting performed
> by
> | the CA is not merely useless to me, it is actually an explicit
> | disadvantage (because the proponents of option 1 are recommending
> that
> | all the intra-domain certificates be examined *before* the
> inter-domain
> | certificates are examined, leading to worst-case path-construction
> times
> | for what may turn out to be a common scenario).
> 
> I don't see that falling out of the Option 1 text as I read the
> straw poll message.  If such is the case, then I would say that text
> should be present.
> 
Dave Horvath's message to Bob Jueneman earlier today said the following:

    "I feel that the definition of domain is a local policy and that CAs
should be free to define it as they wish.   Clients  that search/read
CAs
entries and obtain the values from both the cACertificate and
crossCertificatePair attributes can explore the values in the
cACertficate
attribute first.  If a path to the trusted root is found, processing
stops.
If not, they can explore the crossCertificatePair attribute.  Using this
algorithm CAs can define their domain and post each of their CA
certificates
to one attribute or the other.  The only adverse affect will be
efficiency
in path development  on the client side if the CA does not carefully
select
intra or inter domain."

This was also mentioned at the meeting in Chicago.

> | Note that there will be special circumstances in which one
> definition of
> | domain will be understood throughout a given environment (e.g., the
> | strict hierarchy of CAs has been cited in previous posts on this
> topic).
> | In such cases there is a clear efficiency advantage to be gained in
> path
> | construction.  This is why option 2 is the perfect compromise:  for
> such
> | environments relying parties need only retrieve the n1 < n
> certificates
> | that they *know* will be useful to them.  Option 2 therefore meets
> the
> | needs of the general case as well as the special case, while
> | simultaneously guaranteeing interoperability of two installed bases
> | which would otherwise have no hope of interoperating today.
> 
> Stop. Here's where I really fall off the wagon. How does the relying
> party
> retrieve ONLY the n1 certificates that they know will be useful to
> them for
> a CA?  
> 
If the relying party knows that its definition of domain matches that of
the CA exactly, then it can simply retrieve all certificates in the
cACertificate attribute (rather than all certificates in the
crossCertificatePair attribute) in option 2.  This is n1 rather than n.

> Ryan
> 
> P.S.  I'm really beginning to like the original text, given that the
> concept of a "domain" is looking more and more useless (causing
> confusion
> and concern without appreciable positive points) in this discussion.
> 
Me too...  :-)

Carlisle.

From: "Les Mitchell" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Fri, 4 Sep 1998 08:07:40 +1000
Sender: [email-masked]

Date: Thu, 3 Sep 1998 17:09:01 -0400
From: [email-masked] (Ryan Moats)
To: Carlisle Adams <[email-masked]>, [email-masked]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Sender: [email-masked]

Call me slow, but I don't follow the argument the whole way...

| Hi all,
| 
| I propose that we try (once again) to understand what the real issue is
| here.
| 
| > As somebody coming to the party late from the LDAP world, I don't see
| > why
| > the certificates need to be retrieved from two places.  An LDAP lookup
| > of an
| > object with a fairly simple filter (objectclass="*") will return all
| > of the
| > attributes associated with that object.  Therefore a single lookup
| > will return
| > both attributes, so I don't understand how retrieval efficiency is
| > gained.
| > 
| O.K., so we see that a single LDAP lookup can retrieve all certificates
| (which, after careful enumeration, was found to be "n") in either option
| 1 or option 2.
| 
| The claimed advantage of option 1 is that this retrieval gets me
| certificates that are sorted into "intra-domain" and "inter-domain",
| which can help in efficient path construction.  Let's think about this
| for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
| TRUSTED BY ME  (because if it was directly trusted by me, I would
| already have a trusted copy of its public key and would not need
| certificates in which it was the subject).  If it is not directly
| trusted by me, then why would I necessarily trust it to do this sorting
| in a way that is beneficial to my path construction needs?  How does it
| know what *my* definition of "domain" is?  How does it know whether most
| of my certificate validations will be "intra" its definition of domain
| or "inter" its definition of domain?

I follow this portion of the argument...

| If this CA's definition of domain and my definition of domain do not
| coincide exactly (and why should they, since in general this CA and I
| have no pre-established relationship?), then this sorting performed by
| the CA is not merely useless to me, it is actually an explicit
| disadvantage (because the proponents of option 1 are recommending that
| all the intra-domain certificates be examined *before* the inter-domain
| certificates are examined, leading to worst-case path-construction times
| for what may turn out to be a common scenario).

I don't see that falling out of the Option 1 text as I read the
straw poll message.  If such is the case, then I would say that text
should be present.

| Relying parties know what certificates they will be validating most
| often, depending upon what particular activity they are engaged in at
| the moment.  THAT defines the relying parties' "intra" and "inter"
| domains.  CAs in the middle of a cert. path cannot possibly know this,
| in general, so having THEM define a domain and sort certificates
| according to that definition is really meaningless.

Agreed.

| Note that there will be special circumstances in which one definition of
| domain will be understood throughout a given environment (e.g., the
| strict hierarchy of CAs has been cited in previous posts on this topic).
| In such cases there is a clear efficiency advantage to be gained in path
| construction.  This is why option 2 is the perfect compromise:  for such
| environments relying parties need only retrieve the n1 < n certificates
| that they *know* will be useful to them.  Option 2 therefore meets the
| needs of the general case as well as the special case, while
| simultaneously guaranteeing interoperability of two installed bases
| which would otherwise have no hope of interoperating today.

Stop. Here's where I really fall off the wagon. How does the relying party
retrieve ONLY the n1 certificates that they know will be useful to them for
a CA?  I can see retrieving the CA object from the directory (which unless
you do something real clever will have ALL certificates independent of which
option is chosen) and then doing your own sorting, but I don't see how CA 
"presorting" is going to make a difference, because ALL certificates will
be there.

| The price of this panacea?  A few redundant certificates in the
| Directory.  Is it really worth sacrificing the general- (and perhaps
| common-) case scenario, as well as interoperability, in order to save a
| few certificates and satisfy a particular special-case?  I haven't yet
| heard any convincing arguments...

Well, I'm not convinced of your argument here the other way (other than
the interoperability consideration), but that's what e-mail is for :-)

My current reasoning is that given that a single LDAP lookup is going to 
return ALL of the certificates independent of the option chosen, the client
is going to have to process those certificates to build its path.  Since
this begins to look like a wash in terms of client complexity (yes,
yes, this is where interoperability shows up), why not argue for
the choice that conserves directory space?

Ryan

P.S.  I'm really beginning to like the original text, given that the
concept of a "domain" is looking more and more useless (causing confusion
and concern without appreciable positive points) in this discussion.

Date: Thu, 03 Sep 1998 17:14:02 -0400
To: [email-masked]
From: Bill Burr <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Regards,

Bill Burr

Date: Thu, 03 Sep 1998 17:02:06 -0400
From: Susan Lang <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Thu, 03 Sep 1998 16:52:36 -0400
From: David Solo <[email-masked]>
Reply-To: [email-masked]
Organization: Citicorp
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Thu, 03 Sep 1998 13:41:00 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Sender: [email-masked]

Hi Carlisle,
    Is the expectation that everybody is directly accessing their
CA's LDAP directory? I always thought that each orginazation would
actually maintain its own LDAP directory and, therefore, be able
to specify which CAs are preferred over others.

    Are we really expecting people to share their directories with
everyone in the world?

Ambarish

Carlisle Adams wrote:
> 
> Hi all,
> 
> I propose that we try (once again) to understand what the real issue is
> here.
> 
> > ----------
> > From:         Ryan Moats[SMTP:[email-masked]]
> > Sent:         Thursday, September 03, 1998 12:14 PM
> > To:   [email-masked]
> > Cc:   [email-masked]
> > Subject:      Retrieval efficiency herring? (was... RE: What the straw
> > poll means)
> >
> > As somebody coming to the party late from the LDAP world, I don't see
> > why
> > the certificates need to be retrieved from two places.  An LDAP lookup
> > of an
> > object with a fairly simple filter (objectclass="*") will return all
> > of the
> > attributes associated with that object.  Therefore a single lookup
> > will return
> > both attributes, so I don't understand how retrieval efficiency is
> > gained.
> >
> O.K., so we see that a single LDAP lookup can retrieve all certificates
> (which, after careful enumeration, was found to be "n") in either option
> 1 or option 2.
> 
> The claimed advantage of option 1 is that this retrieval gets me
> certificates that are sorted into "intra-domain" and "inter-domain",
> which can help in efficient path construction.  Let's think about this
> for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
> TRUSTED BY ME  (because if it was directly trusted by me, I would
> already have a trusted copy of its public key and would not need
> certificates in which it was the subject).  If it is not directly
> trusted by me, then why would I necessarily trust it to do this sorting
> in a way that is beneficial to my path construction needs?  How does it
> know what *my* definition of "domain" is?  How does it know whether most
> of my certificate validations will be "intra" its definition of domain
> or "inter" its definition of domain?
> 
> If this CA's definition of domain and my definition of domain do not
> coincide exactly (and why should they, since in general this CA and I
> have no pre-established relationship?), then this sorting performed by
> the CA is not merely useless to me, it is actually an explicit
> disadvantage (because the proponents of option 1 are recommending that
> all the intra-domain certificates be examined *before* the inter-domain
> certificates are examined, leading to worst-case path-construction times
> for what may turn out to be a common scenario).
> 
> Relying parties know what certificates they will be validating most
> often, depending upon what particular activity they are engaged in at
> the moment.  THAT defines the relying parties' "intra" and "inter"
> domains.  CAs in the middle of a cert. path cannot possibly know this,
> in general, so having THEM define a domain and sort certificates
> according to that definition is really meaningless.
> 
> Note that there will be special circumstances in which one definition of
> domain will be understood throughout a given environment (e.g., the
> strict hierarchy of CAs has been cited in previous posts on this topic).
> In such cases there is a clear efficiency advantage to be gained in path
> construction.  This is why option 2 is the perfect compromise:  for such
> environments relying parties need only retrieve the n1 < n certificates
> that they *know* will be useful to them.  Option 2 therefore meets the
> needs of the general case as well as the special case, while
> simultaneously guaranteeing interoperability of two installed bases
> which would otherwise have no hope of interoperating today.
> 
> The price of this panacea?  A few redundant certificates in the
> Directory.  Is it really worth sacrificing the general- (and perhaps
> common-) case scenario, as well as interoperability, in order to save a
> few certificates and satisfy a particular special-case?  I haven't yet
> heard any convincing arguments...
> 
> Carlisle.

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

Date: Thu, 03 Sep 1998 16:33:13 -0400
From: Robert Sabourin <[email-masked]>
Organization: TBS TechWatch
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: GMurphy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Option 2
Date: Thu, 3 Sep 1998 15:02:18 -0400 
Sender: [email-masked]

From: Carlisle Adams <[email-masked]>
To: [email-masked]
Subject: Let's try to understand the real issue (was... RE: What the straw poll means)
Date: Thu, 3 Sep 1998 19:25:07 +0100
Sender: [email-masked]

Hi all,

I propose that we try (once again) to understand what the real issue is
here.

> ----------
> From: 	Ryan Moats[SMTP:[email-masked]]
> Sent: 	Thursday, September 03, 1998 12:14 PM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	Retrieval efficiency herring? (was... RE: What the straw
> poll means)
> 
> As somebody coming to the party late from the LDAP world, I don't see
> why
> the certificates need to be retrieved from two places.  An LDAP lookup
> of an
> object with a fairly simple filter (objectclass="*") will return all
> of the
> attributes associated with that object.  Therefore a single lookup
> will return
> both attributes, so I don't understand how retrieval efficiency is
> gained.
> 
O.K., so we see that a single LDAP lookup can retrieve all certificates
(which, after careful enumeration, was found to be "n") in either option
1 or option 2.

The claimed advantage of option 1 is that this retrieval gets me
certificates that are sorted into "intra-domain" and "inter-domain",
which can help in efficient path construction.  Let's think about this
for a moment.  The CA doing this sorting is, by definition, NOT DIRECTLY
TRUSTED BY ME  (because if it was directly trusted by me, I would
already have a trusted copy of its public key and would not need
certificates in which it was the subject).  If it is not directly
trusted by me, then why would I necessarily trust it to do this sorting
in a way that is beneficial to my path construction needs?  How does it
know what *my* definition of "domain" is?  How does it know whether most
of my certificate validations will be "intra" its definition of domain
or "inter" its definition of domain?

If this CA's definition of domain and my definition of domain do not
coincide exactly (and why should they, since in general this CA and I
have no pre-established relationship?), then this sorting performed by
the CA is not merely useless to me, it is actually an explicit
disadvantage (because the proponents of option 1 are recommending that
all the intra-domain certificates be examined *before* the inter-domain
certificates are examined, leading to worst-case path-construction times
for what may turn out to be a common scenario).

Relying parties know what certificates they will be validating most
often, depending upon what particular activity they are engaged in at
the moment.  THAT defines the relying parties' "intra" and "inter"
domains.  CAs in the middle of a cert. path cannot possibly know this,
in general, so having THEM define a domain and sort certificates
according to that definition is really meaningless.

Note that there will be special circumstances in which one definition of
domain will be understood throughout a given environment (e.g., the
strict hierarchy of CAs has been cited in previous posts on this topic).
In such cases there is a clear efficiency advantage to be gained in path
construction.  This is why option 2 is the perfect compromise:  for such
environments relying parties need only retrieve the n1 < n certificates
that they *know* will be useful to them.  Option 2 therefore meets the
needs of the general case as well as the special case, while
simultaneously guaranteeing interoperability of two installed bases
which would otherwise have no hope of interoperating today.

The price of this panacea?  A few redundant certificates in the
Directory.  Is it really worth sacrificing the general- (and perhaps
common-) case scenario, as well as interoperability, in order to save a
few certificates and satisfy a particular special-case?  I haven't yet
heard any convincing arguments...

Carlisle.

From: "Dave Horvath" <[email-masked]>
To: "Bill Burr" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 14:14:16 -0400
Sender: [email-masked]

    I understand the problems Bill is having with the definitions of roots
and domains.  I think we are all  having those problems.  It seems that
roughly half of the people I communicated with are concerned with the
definitions and feel that population of all the cACertificates in one
attribute may help.   I personally do not feel this helps, however we should
all be interested in a compromise to keep things moving and to keep both
sides happy.

    I must admit that I like the idea of being able to go to one place in
the directory to find all certificates that a CA has issued (I believe
Stefan pointed this out).  It appears that populating all CA certificates in
the reverse component of the crossCertificatePair attribute solves this
requirement and does not duplicate certs in a single CAs entry.  This gives
clients that work in a forward direction the ability to determine all of the
certificates that a CA has issued.  This type of population is clearly
mandated by option 2 and only allowed by option 1.  Option 1 does not
mandate it.   This type of population avoids duplication of certificates in
a single CA entry (they are duplicated in subordinate, mesh, cross
whatever), but seems to be advantageous from a clients point of view.

    Would populating the reverse component with all issued CA certificates
provide a compromise that supports a single attribute to retrieve all certs?
Would this help with the installed base issue?

Dave Horvath

-----Original Message-----
From: Bill Burr <[email-masked]>
To: Dave Horvath <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, September 03, 1998 12:44 PM
Subject: Re: What the straw poll means

>But what is a root here?  Does it imply that a domain is PKI hierarchy?  I
>can think of 3 plausible constructions of root, all of which I believe I've
>seen used:
>
>(1) any CA whose key you choose to trust and therefore can start a
>certification path, but which may not imply any other organization or
>structure;
>
>(2) a CA whose key everybody in the domain (what's a domain?) trusts and
>which sits on top of a hierarchical unidirectional certification tree (as
>in MISSI or PEM);
>
>(3) a CA that exists to cross-certify with other CAs, but issues few or no
>end entity certificates, and starts few or no certification paths; it
>simply exists to connect other CAs.  Examples would be the ANX "supervisory
>CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
>Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is often
>depicted at the hub of a mesh, or the top of a hierarchy, and operated in
>conjunction with the overall domain policy management authority.
>
>
>I suppose a "trusted root" can be either 1 or 2 above.
>
>But "root" to me doesn't necessarily say much about path development, or
>PKI certification path structure.
>
>How about domain? What does it mean?  I claim that the term makes most
>sense to mean a part of a PKI that operates under the direction of a policy
>management entity. Which wouldn't necessarily mean that domain boundaries
>coincide with distinctions that are meaningful for certification path
>building.
>
>Option 1 is probably useful if you think that a domain is  everything
>subordinate to the same root CA, where a root is any CA that somebody uses
>to start a trust path.  So in a cross-certified mesh PKI, every CA is a
>domain onto itself, and all CA certificates wind up only, I think, in the
>crossCertificatePair attribute.  But in a hierarchical PKI most
>certificates wind up in the cACertificate Attribute.
>
>I have the feeling that Bob is right at least for option 1, unless we know
>what a domain is we hardly know what we are getting.  With option 2, I
>suppose we are guaranteed that all certificates wind up in
>crossCertificatePair, whatever domain means.
>
>At 11:14 AM 9/3/98 -0400, you wrote:
>>Bob,
>>
>>    I feel that the definition of domain is a local policy and that CAs
>>should be free to define it as they wish.   Clients  that search/read CAs
>>entries and obtain the values from both the cACertificate and
>>crossCertificatePair attributes can explore the values in the cACertficate
>>attribute first.  If a path to the trusted root is found, processing
stops.
>>If not, they can explore the crossCertificatePair attribute.  Using this
>>algorithm CAs can define their domain and post each of their CA
certificates
>>to one attribute or the other.  The only adverse affect will be efficiency
>>in path development  on the client side if the CA does not carefully
select
>>intra or inter domain.  WIth option 1, the certificates are not
duplicated.
>>With option 2, they are.
>>
>>But if we have an installed base that only looks in the
crossCertificatePair
>>attribute, then we have a problem.  In that case option 2 will help at the
>>expense of duplicating the data.   I suggest we avoid duplication if
>>possible, but we certainly must evaluate the installed base.
>>
>>Dave Horvath
>>
>>
>>
>>
>>-----Original Message-----
>>From: Bob Jueneman <[email-masked]>
>>To: [email-masked] <[email-masked]>; [email-masked]
>><[email-masked]>
>>Date: Wednesday, September 02, 1998 10:21 PM
>>Subject: RE: What the straw poll means
>>
>>
>>>Santosh doesn't seem to have answered the questions I've raised
>>>regarding the definition of the domain, but he seems to believe that
>>>option 2 doesn't solve that problem either.
>>>
>>>If so, I am increasingly beginning to lean towards "NONE OF THE
>>>ABOVE".
>>>
>>>Rebuttal, Sharon/Carlisle?
>>>
>>>Bob
>>>
>>>>Yes Bob.  I hate to say this, but you have misinterpreted.
>>>>
>>>>The basic difference between the two approaches is the under option 1
>>>>you store a certificate only one time under a CA's entry.  Which
>>>>certifying CA is in its domain is upto a subject CA to decide.
>>>>
>>>>In all honesty, I do not see a benefit to option 2 except for the
>>>>argument that some installed base already does it this way.
>>>>
>>>>Option 1 achieves everything option 2 and with efficiency.
>>>>
>>>>I do not understand how option 2 solves your problems either.  We need
>>>>to have a discussion on computational complexity of path development to
>>>>allay your concerns.
>>>>
>>>>The way I look at the difference between the two options is that if
>>>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>>>>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>>>>another.  When you retrieve the two buckets (which you must for path
>>>>development efficiency), option 2 gives you n+n1 certificates and option
>>>>1 gives you exactly all n.
>>>>
>>>>> -----Original Message-----
>>>>> From: Bob Jueneman [SMTP:[email-masked]]
>>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>>> To: [email-masked]
>>>>> Cc: [email-masked]
>>>>> Subject: What the straw poll means
>>>>>
>>>>> This is almost as exciting as watching a horse race!
>>>>>
>>>>> But what are we to make of the situation if the vote is as
>>>>> close as it appears to be at present -- does that truly indicate
>>>>> a "rough consensus"?
>>>>>
>>>>> As of earlier this morning, Chromatix was ahead, with
>>>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
>>>>> cast; and MISSI some others are clustered around third place.
>>>>>
>>>>> So far, with the exception of a split between MISSI and NIST
>>>>> as two US Government factions, the voting seems to be
>>>>> strictly by company.
>>>>>
>>>>> Now, the polite fiction within the IETF is that memberships are by
>>>>> individual, and that there are no "votes" per se, and certainly not
>>>>> on a company by company basis. That's the fiction, at least..
>>>>> Whether this convention shall long endure now that the IETF has
>>>>> apparently lost some or all of its government funding and has
>>>>> to become more self-sufficient will be interesting to see.
>>>>>
>>>>> But unless one side or the other starts to make some significant
>>>>> in-roads by the dint of more persuasive technical argument, then I
>>>>> think
>>>>> it's effectively a draw, and we may be counting companies and their
>>>>> installed base at least as much, and perhaps more, than
>>>>> balancing the technical alternatives.
>>>>>
>>>>> Now, if we are truly at a technical impasse and the vote has to be
>>>>> binary, i.e., only one way or the other, then maybe counting installed
>>>>> clients and minimizing the pain is really the way to go, but frankly
>>>>> that approach makes me uncomfortable.  I want both interoperability
>>>>> AND efficiency, and I would hate to see us don't want to be
>>>>> pressured into a less than satisfactory decision, whatever that is,
>>>>>  just because we are in a rush to get over the next hurdle in the
>>>>> standards progression.
>>>>>
>>>>> I originally said that I was inclined to go with option 1, because
>>>>> it at least appeared to be simpler.  However, I also said that I was
>>>>> concerned about the "local" definition of a domain by a CA,
>>>>> and the more I think about it, the more concerned I get.
>>>>>
>>>>> That approach might be viable for an organization such as MISSI,
>>>>> where everyone presumably knows what community of interest
>>>>> they fall into, but how would it apply to a public CA such as
>>>>> VeriSign?
>>>>>
>>>>> Would they view all of their certificates as falling into one domain,
>>>>> including any certificates issued by subordinate CAs, as in the case
>>>>> of the old RSA Commercial hierarchy?
>>>>>
>>>>> What about GTE CyberTrust, considering their presumed affinity
>>>>> with their ISP business. Would all of those certificates fall into
>>>>> one domain?
>>>>>
>>>>> Now suppose I want to validate a certificate from Erols.  Do I decide
>>>>> that
>>>>> because Erols is in the top half of the alphabet that they probably
>>>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
>>>>> East Coast/West Coast split, like radio and TV stations use W or K in
>>>>> their call sign?
>>>>>
>>>>> What if Novell and Microsoft were to become CAs and issue certificates
>>>>>
>>>>> to their customers directly, at least their larger accounts.  Would
>>>>> the relying
>>>>> party have to try to divine whether a subscriber was running NetWare
>>>>> or
>>>>> NT in order to decide what domain they would be likely to be in?
>>>>>
>>>>> Santosh, have I misrepresented the issue here?  Feel free to correct
>>>>> me, if so.
>>>>> Maybe I just don't understand.
>>>>>
>>>>> Now, if the definition of "domain" were amended somewhat, perhaps some
>>>>> of these difficulties might go away.
>>>>>
>>>>> In particular, it seems to me that "domain" probably ought to have a
>>>>> lot to do
>>>>> with name subordination, or at least the possibility of doing name
>>>>> subordination,
>>>>> so that it would be deterministic.  That might not solve all of the
>>>>> concerns that those
>>>>> who are inclined to vote for option 2 might have in mind, but it might
>>>>> help.
>>>>>
>>>>> So if I am a Novell employee, and I receive an S/MIME message that
>>>>> contains
>>>>> a certificate that begins with c=US, o=Novell, I can probably make an
>>>>> excellent
>>>>> good guess of what CA to go to, assuming that Novell operates a CA in
>>>>> its
>>>>> own name.  But where do I go for a certificate from Acme
>>>>> Manufacturing?
>>>>>
>>>>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>>>>> there are
>>>>> some things that could be done within the options 2 that would come
>>>>> closer to a
>>>>> compromise without breaking those existing clients.  But I need to
>>>>> think about that
>>>>> some more.  maybe someone else could volunteer some suggestions.
>>>>>
>>>>> Bob
>>>>>
>>>>> Robert R. Jueneman
>>>>> Novell, Inc.
>>>>> 122 E. 1700 South
>>>>> Provo, UT 84606
>>>>> [email-masked]
>>>>> 1-801-861-7387
>>>
>>>
>>
>>
>Regards,
>
>Bill Burr
>

From: Rainer Rueppel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 19:01:41 +0100
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 18:26:10 +0100
Sender: [email-masked]

Hi Ambarish

It is the relying party, not the CA, which knows the priority for
identifying the most efficient set of certificates for path building for
a specific certificate validation. Further,  the priority for a single
relying party can change from operation to operation depending on the
particular environment in which they are operating. For that primary
reason, I don't think the CA's domain (whatever they define it to be) is
a very useful split, but rather allowing client systems to perform
flexible filtering of the contents of the directory with matching rules
that allow them to match on particular elements of the certificates is
the most generic and flexible approach. While a CA could provide some
helpful hints to relying parties (e.g. through the use of cACertificate
attribute or other attributes and prioritization tags) this can only
help a subset of relying parties who understand that CAs definition of
domain and/or prioritization criteria. Other relying parties may have
completely opposite priorities and relying parties for which the CA
hints are useless should be equally supported.   

As we migrate to LDAPv3, the extensible match capability of that
protocol, combined with the matching rules currently in X.509 (or some
evolution of them) should enable ONLY the certificates of interest to a
particular relying party and for a particular validation instance to be
retrieved. While it is true that an extensible match can be applied to
more than one attribute on a single directory protocol exchange, this
does require extra processing on the directory side, provides no
additional value,  and is obviously more work for the directory  than to
filter on a single attribute rather than always on two.

There would be nothing to prevent the use of additional attributes
(either locally defined or standardized), or some other technologies
(e.g. the use of directory contexts to flag particular values of a
single attribute) but at this point I believe those would be more
locally contained than standardized so I see them as additional helpful
hints potentially.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Ambarish Malpani[SMTP:[email-masked]]
> Sent: 	September 3, 1998 12:54 PM
> To: 	[email-masked]'
> Subject: 	Where to store CA certificates
> 
> Hi Guys,
>     Given the huge amount of passion that the topic of where one
> stores CA certificates has generated, it seems to me that path
> building is both a complicated and important thing ;-)
> 
>     If the premise above is true, wouldn't one want to prioritize
> path building more precisely than just lumping CA certs into
> one of two categories (intra-domain/inter-domain)?
> 
>     Would it make sense to have another attribute attached to
> CA certificates - something like a "priority" field, with say
> an integer value, where, during path building you first try to
> build paths with the CA cert with the highest priority?
> 
>     Or is this a BAD idea, because it doesn't work with any of
> the current implementations?
> 
> Comments? Sharon, Santosh?
> 
> 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
> 

Date: Thu, 03 Sep 1998 09:54:19 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: "[email-masked]'" <[email-masked]>
Subject: Where to store CA certificates
Sender: [email-masked]

Hi Guys,
    Given the huge amount of passion that the topic of where one
stores CA certificates has generated, it seems to me that path
building is both a complicated and important thing ;-)

    If the premise above is true, wouldn't one want to prioritize
path building more precisely than just lumping CA certs into
one of two categories (intra-domain/inter-domain)?

    Would it make sense to have another attribute attached to
CA certificates - something like a "priority" field, with say
an integer value, where, during path building you first try to
build paths with the CA cert with the highest priority?

    Or is this a BAD idea, because it doesn't work with any of
the current implementations?

Comments? Sharon, Santosh?

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

Date: Thu, 03 Sep 1998 11:14:45 -0600
From: "Russel F. Weiser" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------4DB9C958A073A47F89771625
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm a new to the PKIX in general and am more familiar with  LDAP v3 then the
CA
environment. I did understand the orignal draft and would have voted for
it.  That is if  I would have been able to attend the wg meeting, but alas;
I was in the LDAPEXT wg instead.
I have voted for option 1, because it sounds like it minimizes storage as
well as providing
consistent knowledge of what goes in which attribute without duplicating
storage.

Now I would like to know the reason the orignal text was voted down since I
couldn't be there.

I  know Bob keeps bringing up the DOMAIN issue and I do think that this is
an issue since no one has of yet given it a definition. .

Sharon Boeyen wrote:

> The "two buckets" is exactly what I was trying to avoid in the earlier
> debate on this topic, however I believe that the single bucket option
> was rejected in the Chicago meeting. The single bucket option is the
> text which is currently in the Internet Draft. With that text, all self
> signed (or self issued certificates) were to be placed in the
> cACertificate attribute and all certificates issued by one CA to a
> different CA were put in the crossCertificatePair attribute. Depending
> on the particular path development algorithm being used by a relying
> party, directory search tools, especially when we evolve to LDAPv3 could
> be used to filter the content of the forward and or reverse elements of
> that SINGLE attribute and provide the relying party with the set of
> certificates of interest to that particular relying party.
>
> I still believe that this is the best solution because the relying party
> systems are the ones that know which certs are of interest to them, not
> the CA that happened to issue the certs, especially in the post PEM
> world where any CA could legitimately have certs issued for it by
> several CAs.
>
> My strong support for Option 2 in the straw poll is because the above
> was rejected by the meeting and I see Option 2 as a workable compromise
> ONLY because there is a complete set of certs in a single attribute and
> relying parties can do what is of interest to them without knowing the
> definition of domain which each individual CA happens to use. For self
> contained environments wanting to make use of a CA or set of CAs certs
> issued within some locally defined domain, this is still possible.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies
>
> mailto:[email-masked]  Tel: (613) 247-3181
> http://www.entrust.com            Fax: (613) 247-3690
>
>
> > ----------
> > From:         Santosh Chokhani[SMTP:[email-masked]]
> > Sent:         September 2, 1998 8:48 PM
> > To:   'Bob Jueneman'; [email-masked]
> > Cc:   Santosh Chokhani
> > Subject:      RE: What the straw poll means
> >
> > Yes Bob.  I hate to say this, but you have misinterpreted.
> >
> > The basic difference between the two approaches is the under option 1
> > you store a certificate only one time under a CA's entry.  Which
> > certifying CA is in its domain is upto a subject CA to decide.
> >
> > In all honesty, I do not see a benefit to option 2 except for the
> > argument that some installed base already does it this way.
> >
> > Option 1 achieves everything option 2 and with efficiency.
> >
> > I do not understand how option 2 solves your problems either.  We need
> > to have a discussion on computational complexity of path development
> > to
> > allay your concerns.
> >
> > The way I look at the difference between the two options is that if
> > n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> > one
> > bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
> > another.  When you retrieve the two buckets (which you must for path
> > development efficiency), option 2 gives you n+n1 certificates and
> > option
> > 1 gives you exactly all n.
> >
> > > -----Original Message-----
> > > From:       Bob Jueneman [SMTP:[email-masked]]
> > > Sent:       Wednesday, September 02, 1998 8:33 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject:    What the straw poll means
> > >
> > > This is almost as exciting as watching a horse race!
> > >
> > > But what are we to make of the situation if the vote is as
> > > close as it appears to be at present -- does that truly indicate
> > > a "rough consensus"?
> > >
> > > As of earlier this morning, Chromatix was ahead, with
> > > 8 votes cast; Entrust was tied with Microsoft with 4 votes
> > > cast; and MISSI some others are clustered around third place.
> > >
> > > So far, with the exception of a split between MISSI and NIST
> > > as two US Government factions, the voting seems to be
> > > strictly by company.
> > >
> > > Now, the polite fiction within the IETF is that memberships are by
> > > individual, and that there are no "votes" per se, and certainly not
> > > on a company by company basis. That's the fiction, at least..
> > > Whether this convention shall long endure now that the IETF has
> > > apparently lost some or all of its government funding and has
> > > to become more self-sufficient will be interesting to see.
> > >
> > > But unless one side or the other starts to make some significant
> > > in-roads by the dint of more persuasive technical argument, then I
> > > think
> > > it's effectively a draw, and we may be counting companies and their
> > > installed base at least as much, and perhaps more, than
> > > balancing the technical alternatives.
> > >
> > > Now, if we are truly at a technical impasse and the vote has to be
> > > binary, i.e., only one way or the other, then maybe counting
> > installed
> > > clients and minimizing the pain is really the way to go, but frankly
> >
> > > that approach makes me uncomfortable.  I want both interoperability
> > > AND efficiency, and I would hate to see us don't want to be
> > > pressured into a less than satisfactory decision, whatever that is,
> > >  just because we are in a rush to get over the next hurdle in the
> > > standards progression.
> > >
> > > I originally said that I was inclined to go with option 1, because
> > > it at least appeared to be simpler.  However, I also said that I was
> >
> > > concerned about the "local" definition of a domain by a CA,
> > > and the more I think about it, the more concerned I get.
> > >
> > > That approach might be viable for an organization such as MISSI,
> > > where everyone presumably knows what community of interest
> > > they fall into, but how would it apply to a public CA such as
> > > VeriSign?
> > >
> > > Would they view all of their certificates as falling into one
> > domain,
> > > including any certificates issued by subordinate CAs, as in the case
> > > of the old RSA Commercial hierarchy?
> > >
> > > What about GTE CyberTrust, considering their presumed affinity
> > > with their ISP business. Would all of those certificates fall into
> > > one domain?
> > >
> > > Now suppose I want to validate a certificate from Erols.  Do I
> > decide
> > > that
> > > because Erols is in the top half of the alphabet that they probably
> > > use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
> > > East Coast/West Coast split, like radio and TV stations use W or K
> > in
> > > their call sign?
> > >
> > > What if Novell and Microsoft were to become CAs and issue
> > certificates
> > >
> > > to their customers directly, at least their larger accounts.  Would
> > > the relying
> > > party have to try to divine whether a subscriber was running NetWare
> > > or
> > > NT in order to decide what domain they would be likely to be in?
> > >
> > > Santosh, have I misrepresented the issue here?  Feel free to correct
> > > me, if so.
> > > Maybe I just don't understand.
> > >
> > > Now, if the definition of "domain" were amended somewhat, perhaps
> > some
> > > of these difficulties might go away.
> > >
> > > In particular, it seems to me that "domain" probably ought to have a
> > > lot to do
> > > with name subordination, or at least the possibility of doing name
> > > subordination,
> > > so that it would be deterministic.  That might not solve all of the
> > > concerns that those
> > > who are inclined to vote for option 2 might have in mind, but it
> > might
> > > help.
> > >
> > > So if I am a Novell employee, and I receive an S/MIME message that
> > > contains
> > > a certificate that begins with c=US, o=Novell, I can probably make
> > an
> > > excellent
> > > good guess of what CA to go to, assuming that Novell operates a CA
> > in
> > > its
> > > own name.  But where do I go for a certificate from Acme
> > > Manufacturing?
> > >
> > > I don't mean to beat up on the option 1 folks exclusively -- maybe
> > > there are
> > > some things that could be done within the options 2 that would come
> > > closer to a
> > > compromise without breaking those existing clients.  But I need to
> > > think about that
> > > some more.  maybe someone else could volunteer some suggestions.
> > >
> > > Bob
> > >
> > > Robert R. Jueneman
> > > Novell, Inc.
> > > 122 E. 1700 South
> > > Provo, UT 84606
> > > [email-masked]
> > > 1-801-861-7387
> >

--------------4DB9C958A073A47F89771625
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Russel Weiser
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Russel Weiser
n:              Weiser;Russel
org:            DST
email;internet: [email-masked]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------4DB9C958A073A47F89771625--

Date: Thu, 03 Sep 1998 12:47:53 -0400
To: "Dave Horvath" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject: Re: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

But what is a root here?  Does it imply that a domain is PKI hierarchy?  I
can think of 3 plausible constructions of root, all of which I believe I've
seen used: 

(1) any CA whose key you choose to trust and therefore can start a
certification path, but which may not imply any other organization or
structure;

(2) a CA whose key everybody in the domain (what's a domain?) trusts and
which sits on top of a hierarchical unidirectional certification tree (as
in MISSI or PEM);

(3) a CA that exists to cross-certify with other CAs, but issues few or no
end entity certificates, and starts few or no certification paths; it
simply exists to connect other CAs.  Examples would be the ANX "supervisory
CA," the Gov. of Canada "Level 0" CA operated by the Canadian Central
Facility, or the proposed Federal PKI "Bridge CA."  Such a CA is often
depicted at the hub of a mesh, or the top of a hierarchy, and operated in
conjunction with the overall domain policy management authority.

I suppose a "trusted root" can be either 1 or 2 above.

But "root" to me doesn't necessarily say much about path development, or
PKI certification path structure.

How about domain? What does it mean?  I claim that the term makes most
sense to mean a part of a PKI that operates under the direction of a policy
management entity. Which wouldn't necessarily mean that domain boundaries
coincide with distinctions that are meaningful for certification path
building.

Option 1 is probably useful if you think that a domain is  everything
subordinate to the same root CA, where a root is any CA that somebody uses
to start a trust path.  So in a cross-certified mesh PKI, every CA is a
domain onto itself, and all CA certificates wind up only, I think, in the
crossCertificatePair attribute.  But in a hierarchical PKI most
certificates wind up in the cACertificate Attribute.  

I have the feeling that Bob is right at least for option 1, unless we know
what a domain is we hardly know what we are getting.  With option 2, I
suppose we are guaranteed that all certificates wind up in
crossCertificatePair, whatever domain means.  

At 11:14 AM 9/3/98 -0400, you wrote:
>Bob,
>
>    I feel that the definition of domain is a local policy and that CAs
>should be free to define it as they wish.   Clients  that search/read CAs
>entries and obtain the values from both the cACertificate and
>crossCertificatePair attributes can explore the values in the cACertficate
>attribute first.  If a path to the trusted root is found, processing stops.
>If not, they can explore the crossCertificatePair attribute.  Using this
>algorithm CAs can define their domain and post each of their CA certificates
>to one attribute or the other.  The only adverse affect will be efficiency
>in path development  on the client side if the CA does not carefully select
>intra or inter domain.  WIth option 1, the certificates are not duplicated.
>With option 2, they are.
>
>But if we have an installed base that only looks in the crossCertificatePair
>attribute, then we have a problem.  In that case option 2 will help at the
>expense of duplicating the data.   I suggest we avoid duplication if
>possible, but we certainly must evaluate the installed base.
>
>Dave Horvath
>
>
>
>
>-----Original Message-----
>From: Bob Jueneman <[email-masked]>
>To: [email-masked] <[email-masked]>; [email-masked]
><[email-masked]>
>Date: Wednesday, September 02, 1998 10:21 PM
>Subject: RE: What the straw poll means
>
>
>>Santosh doesn't seem to have answered the questions I've raised
>>regarding the definition of the domain, but he seems to believe that
>>option 2 doesn't solve that problem either.
>>
>>If so, I am increasingly beginning to lean towards "NONE OF THE
>>ABOVE".
>>
>>Rebuttal, Sharon/Carlisle?
>>
>>Bob
>>
>>>Yes Bob.  I hate to say this, but you have misinterpreted.
>>>
>>>The basic difference between the two approaches is the under option 1
>>>you store a certificate only one time under a CA's entry.  Which
>>>certifying CA is in its domain is upto a subject CA to decide.
>>>
>>>In all honesty, I do not see a benefit to option 2 except for the
>>>argument that some installed base already does it this way.
>>>
>>>Option 1 achieves everything option 2 and with efficiency.
>>>
>>>I do not understand how option 2 solves your problems either.  We need
>>>to have a discussion on computational complexity of path development to
>>>allay your concerns.
>>>
>>>The way I look at the difference between the two options is that if
>>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>>>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>>>another.  When you retrieve the two buckets (which you must for path
>>>development efficiency), option 2 gives you n+n1 certificates and option
>>>1 gives you exactly all n.
>>>
>>>> -----Original Message-----
>>>> From: Bob Jueneman [SMTP:[email-masked]]
>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>> To: [email-masked]
>>>> Cc: [email-masked]
>>>> Subject: What the straw poll means
>>>>
>>>> This is almost as exciting as watching a horse race!
>>>>
>>>> But what are we to make of the situation if the vote is as
>>>> close as it appears to be at present -- does that truly indicate
>>>> a "rough consensus"?
>>>>
>>>> As of earlier this morning, Chromatix was ahead, with
>>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
>>>> cast; and MISSI some others are clustered around third place.
>>>>
>>>> So far, with the exception of a split between MISSI and NIST
>>>> as two US Government factions, the voting seems to be
>>>> strictly by company.
>>>>
>>>> Now, the polite fiction within the IETF is that memberships are by
>>>> individual, and that there are no "votes" per se, and certainly not
>>>> on a company by company basis. That's the fiction, at least..
>>>> Whether this convention shall long endure now that the IETF has
>>>> apparently lost some or all of its government funding and has
>>>> to become more self-sufficient will be interesting to see.
>>>>
>>>> But unless one side or the other starts to make some significant
>>>> in-roads by the dint of more persuasive technical argument, then I
>>>> think
>>>> it's effectively a draw, and we may be counting companies and their
>>>> installed base at least as much, and perhaps more, than
>>>> balancing the technical alternatives.
>>>>
>>>> Now, if we are truly at a technical impasse and the vote has to be
>>>> binary, i.e., only one way or the other, then maybe counting installed
>>>> clients and minimizing the pain is really the way to go, but frankly
>>>> that approach makes me uncomfortable.  I want both interoperability
>>>> AND efficiency, and I would hate to see us don't want to be
>>>> pressured into a less than satisfactory decision, whatever that is,
>>>>  just because we are in a rush to get over the next hurdle in the
>>>> standards progression.
>>>>
>>>> I originally said that I was inclined to go with option 1, because
>>>> it at least appeared to be simpler.  However, I also said that I was
>>>> concerned about the "local" definition of a domain by a CA,
>>>> and the more I think about it, the more concerned I get.
>>>>
>>>> That approach might be viable for an organization such as MISSI,
>>>> where everyone presumably knows what community of interest
>>>> they fall into, but how would it apply to a public CA such as
>>>> VeriSign?
>>>>
>>>> Would they view all of their certificates as falling into one domain,
>>>> including any certificates issued by subordinate CAs, as in the case
>>>> of the old RSA Commercial hierarchy?
>>>>
>>>> What about GTE CyberTrust, considering their presumed affinity
>>>> with their ISP business. Would all of those certificates fall into
>>>> one domain?
>>>>
>>>> Now suppose I want to validate a certificate from Erols.  Do I decide
>>>> that
>>>> because Erols is in the top half of the alphabet that they probably
>>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
>>>> East Coast/West Coast split, like radio and TV stations use W or K in
>>>> their call sign?
>>>>
>>>> What if Novell and Microsoft were to become CAs and issue certificates
>>>>
>>>> to their customers directly, at least their larger accounts.  Would
>>>> the relying
>>>> party have to try to divine whether a subscriber was running NetWare
>>>> or
>>>> NT in order to decide what domain they would be likely to be in?
>>>>
>>>> Santosh, have I misrepresented the issue here?  Feel free to correct
>>>> me, if so.
>>>> Maybe I just don't understand.
>>>>
>>>> Now, if the definition of "domain" were amended somewhat, perhaps some
>>>> of these difficulties might go away.
>>>>
>>>> In particular, it seems to me that "domain" probably ought to have a
>>>> lot to do
>>>> with name subordination, or at least the possibility of doing name
>>>> subordination,
>>>> so that it would be deterministic.  That might not solve all of the
>>>> concerns that those
>>>> who are inclined to vote for option 2 might have in mind, but it might
>>>> help.
>>>>
>>>> So if I am a Novell employee, and I receive an S/MIME message that
>>>> contains
>>>> a certificate that begins with c=US, o=Novell, I can probably make an
>>>> excellent
>>>> good guess of what CA to go to, assuming that Novell operates a CA in
>>>> its
>>>> own name.  But where do I go for a certificate from Acme
>>>> Manufacturing?
>>>>
>>>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>>>> there are
>>>> some things that could be done within the options 2 that would come
>>>> closer to a
>>>> compromise without breaking those existing clients.  But I need to
>>>> think about that
>>>> some more.  maybe someone else could volunteer some suggestions.
>>>>
>>>> Bob
>>>>
>>>> Robert R. Jueneman
>>>> Novell, Inc.
>>>> 122 E. 1700 South
>>>> Provo, UT 84606
>>>> [email-masked]
>>>> 1-801-861-7387
>>
>>
>
>
Regards,

Bill Burr

Date: Thu, 03 Sep 1998 10:41:47 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

Bill,

I was only gently tweaking the USG -- anyone who has ever 
dealt with NIST, NSA, or the FBI on issues like export controls 
knows that each agency has its one separate agenda and priorities.
I for one would hate to have to be the President or Vice President 
who has to knock heads and try to get the Administration to speak with 
one voice.

But your comments on the pioneers are very apropos. 

As a major player in the directory space, Novell certainly has an interest 
in this area. We would hate to see a solution adopted that unnecessarily 
wastes directory space. On the other hand, memory is getting cheaper 
and cheaper, but Internet congestion is getting worse, and it isn't clear 
that caching or other approaches would be likely to apply here. so I'm 
not sure that I completely buy Tim's argument that interoperability is 
more important than efficiency.

To further complicate the problem, Novell has a relationship with Entrust,
and we certainly have no desire to see their interests harmed. But likewise,
we consider the US Government a very important customer, and we would 
hate to see a solution adopted that would fly in the face of MISSI's and 
DMS's needs. 

Knowing both Sharon and Santosh reasonably well, I can certainly say that
they are both bright, and have an excellent understanding of the technology. 
The fact that they and others come out on opposite sides of the issue 
probably means that their views of the underlying problem space and 
their priorities, are probably different, rather than being due to some flaw 
in their logic.

If all else fails and we have to make a choice, I also would favor not shafting
the early developer who has helped the market grow.  The trouble is,
I'm not exactly sure whose ox would be gored, and how much effort it
would take to fix it.  Entrust obviously has an investment in their current 
client, but what the cost of changing it would be I don't know. Likewise,
I'm not sure who many other players in this space have already developed
clients that might also be impacted.

What is pretty obvious by now is that there isn't a clear consensus, at least 
not yet, and that cogent arguments can be made on both sides depending
on what your assumptions are regarding the behavior of the clients, which
may require a crystal ball.

So maybe we should go back to the drawing board and see if we have 
exhausted all of the possible alternatives.

For example, Sharon mentioned that she thought that the "single bucket" 
approach was ruled out in Chicago. I wasn't there and so I don't know 
the pros and cons, but it would seem that reexamining that possibility 
might be worthwhile. At least on the surface it seems to solve both problems.

Others have commented that with appropriate LDAP filters it is possible to 
retrieve certificates from both piles simultaneously.  Maybe there is a pony 
in there somewhere that could be explored more fully, especially for those 
of us who are not LDAP gurus.

I WANT my cake and eat it, too!

Bob

From: WHenry <[email-masked]>
To: [email-masked]
Subject: For Option #2
Date: Thu, 3 Sep 1998 12:42:32 -0400 
Sender: [email-masked]

From: "Boby Joseph" <[email-masked]>
To: [email-masked]
Date: Thu, 3 Sep 1998 11:36:24 -0500
Subject: For option 1
Sender: [email-masked]

Date: Thu, 3 Sep 1998 12:32:04 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: What the straw poll means
Sender: [email-masked]

Folks,

A straw poll is not a vote, since we don't vote in the IETF or in WGs.  The
WG chair(s) retain discretion to interpret the outcome of s straw poll,
e.g., to discount any apparent ballot box stuffing by a given organization.
I asked Sharon to extend the polling period because this is clearly a
contentious issue and because we usually allow about a week for such
activities, although we have gone through shorter polling intervals on
occasion.

have a nice Labor Day weekend,

Steve

From: "Ryan Moats" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Retrieval efficiency herring? (was... RE: What the straw poll means)
Date: Thu, 3 Sep 1998 11:14:31 -0500
Importance: Normal
Sender: [email-masked]

[email-masked] writes:

> Santosh Chokhani <[email-masked]> writes:
>
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
>
> The difference between the two options is primarily storage efficiency vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
>
>    whether you care more about storage efficiency in the directory (option
>    2 stores intra-domain certificates twice) or retrieval efficiency for
>    the verifier (option 1 require a verifier that wants all a target CA's
>    certificates to retrieve them from two places).

As somebody coming to the party late from the LDAP world, I don't see why
the certificates need to be retrieved from two places.  An LDAP lookup of an
object with a fairly simple filter (objectclass="*") will return all of the
attributes associated with that object.  Therefore a single lookup will
return
both attributes, so I don't understand how retrieval efficiency is gained.

Ryan Moats

From: [email-masked]
To: [email-masked]
Date: Thu, 3 Sep 1998 11:53:53 -0400
Subject: For Option 2
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [email-masked]
Precedence: bulk

From: "Dave Horvath" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 11:14:45 -0400
Sender: [email-masked]

Bob,

    I feel that the definition of domain is a local policy and that CAs
should be free to define it as they wish.   Clients  that search/read CAs
entries and obtain the values from both the cACertificate and
crossCertificatePair attributes can explore the values in the cACertficate
attribute first.  If a path to the trusted root is found, processing stops.
If not, they can explore the crossCertificatePair attribute.  Using this
algorithm CAs can define their domain and post each of their CA certificates
to one attribute or the other.  The only adverse affect will be efficiency
in path development  on the client side if the CA does not carefully select
intra or inter domain.  WIth option 1, the certificates are not duplicated.
With option 2, they are.

But if we have an installed base that only looks in the crossCertificatePair
attribute, then we have a problem.  In that case option 2 will help at the
expense of duplicating the data.   I suggest we avoid duplication if
possible, but we certainly must evaluate the installed base.

Dave Horvath

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, September 02, 1998 10:21 PM
Subject: RE: What the straw poll means

>Santosh doesn't seem to have answered the questions I've raised
>regarding the definition of the domain, but he seems to believe that
>option 2 doesn't solve that problem either.
>
>If so, I am increasingly beginning to lean towards "NONE OF THE
>ABOVE".
>
>Rebuttal, Sharon/Carlisle?
>
>Bob
>
>>Yes Bob.  I hate to say this, but you have misinterpreted.
>>
>>The basic difference between the two approaches is the under option 1
>>you store a certificate only one time under a CA's entry.  Which
>>certifying CA is in its domain is upto a subject CA to decide.
>>
>>In all honesty, I do not see a benefit to option 2 except for the
>>argument that some installed base already does it this way.
>>
>>Option 1 achieves everything option 2 and with efficiency.
>>
>>I do not understand how option 2 solves your problems either.  We need
>>to have a discussion on computational complexity of path development to
>>allay your concerns.
>>
>>The way I look at the difference between the two options is that if
>>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>>another.  When you retrieve the two buckets (which you must for path
>>development efficiency), option 2 gives you n+n1 certificates and option
>>1 gives you exactly all n.
>>
>>> -----Original Message-----
>>> From: Bob Jueneman [SMTP:[email-masked]]
>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: What the straw poll means
>>>
>>> This is almost as exciting as watching a horse race!
>>>
>>> But what are we to make of the situation if the vote is as
>>> close as it appears to be at present -- does that truly indicate
>>> a "rough consensus"?
>>>
>>> As of earlier this morning, Chromatix was ahead, with
>>> 8 votes cast; Entrust was tied with Microsoft with 4 votes
>>> cast; and MISSI some others are clustered around third place.
>>>
>>> So far, with the exception of a split between MISSI and NIST
>>> as two US Government factions, the voting seems to be
>>> strictly by company.
>>>
>>> Now, the polite fiction within the IETF is that memberships are by
>>> individual, and that there are no "votes" per se, and certainly not
>>> on a company by company basis. That's the fiction, at least..
>>> Whether this convention shall long endure now that the IETF has
>>> apparently lost some or all of its government funding and has
>>> to become more self-sufficient will be interesting to see.
>>>
>>> But unless one side or the other starts to make some significant
>>> in-roads by the dint of more persuasive technical argument, then I
>>> think
>>> it's effectively a draw, and we may be counting companies and their
>>> installed base at least as much, and perhaps more, than
>>> balancing the technical alternatives.
>>>
>>> Now, if we are truly at a technical impasse and the vote has to be
>>> binary, i.e., only one way or the other, then maybe counting installed
>>> clients and minimizing the pain is really the way to go, but frankly
>>> that approach makes me uncomfortable.  I want both interoperability
>>> AND efficiency, and I would hate to see us don't want to be
>>> pressured into a less than satisfactory decision, whatever that is,
>>>  just because we are in a rush to get over the next hurdle in the
>>> standards progression.
>>>
>>> I originally said that I was inclined to go with option 1, because
>>> it at least appeared to be simpler.  However, I also said that I was
>>> concerned about the "local" definition of a domain by a CA,
>>> and the more I think about it, the more concerned I get.
>>>
>>> That approach might be viable for an organization such as MISSI,
>>> where everyone presumably knows what community of interest
>>> they fall into, but how would it apply to a public CA such as
>>> VeriSign?
>>>
>>> Would they view all of their certificates as falling into one domain,
>>> including any certificates issued by subordinate CAs, as in the case
>>> of the old RSA Commercial hierarchy?
>>>
>>> What about GTE CyberTrust, considering their presumed affinity
>>> with their ISP business. Would all of those certificates fall into
>>> one domain?
>>>
>>> Now suppose I want to validate a certificate from Erols.  Do I decide
>>> that
>>> because Erols is in the top half of the alphabet that they probably
>>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
>>> East Coast/West Coast split, like radio and TV stations use W or K in
>>> their call sign?
>>>
>>> What if Novell and Microsoft were to become CAs and issue certificates
>>>
>>> to their customers directly, at least their larger accounts.  Would
>>> the relying
>>> party have to try to divine whether a subscriber was running NetWare
>>> or
>>> NT in order to decide what domain they would be likely to be in?
>>>
>>> Santosh, have I misrepresented the issue here?  Feel free to correct
>>> me, if so.
>>> Maybe I just don't understand.
>>>
>>> Now, if the definition of "domain" were amended somewhat, perhaps some
>>> of these difficulties might go away.
>>>
>>> In particular, it seems to me that "domain" probably ought to have a
>>> lot to do
>>> with name subordination, or at least the possibility of doing name
>>> subordination,
>>> so that it would be deterministic.  That might not solve all of the
>>> concerns that those
>>> who are inclined to vote for option 2 might have in mind, but it might
>>> help.
>>>
>>> So if I am a Novell employee, and I receive an S/MIME message that
>>> contains
>>> a certificate that begins with c=US, o=Novell, I can probably make an
>>> excellent
>>> good guess of what CA to go to, assuming that Novell operates a CA in
>>> its
>>> own name.  But where do I go for a certificate from Acme
>>> Manufacturing?
>>>
>>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>>> there are
>>> some things that could be done within the options 2 that would come
>>> closer to a
>>> compromise without breaking those existing clients.  But I need to
>>> think about that
>>> some more.  maybe someone else could volunteer some suggestions.
>>>
>>> Bob
>>>
>>> Robert R. Jueneman
>>> Novell, Inc.
>>> 122 E. 1700 South
>>> Provo, UT 84606
>>> [email-masked]
>>> 1-801-861-7387
>
>

Date: Thu, 03 Sep 1998 11:08:28 -0400
From: Peter Lindstrom <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Thu, 03 Sep 1998 10:33:58 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: [email-masked]
CC: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: Re: What the straw poll means
Sender: [email-masked]

See comment below.

[email-masked] wrote:
> 
> Santosh Chokhani <[email-masked]> writes:
> 
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> 
> The difference between the two options is primarily storage efficiency vs.
> retrieval efficiency.  Both options divide a CAs certs into two piles.
> Option 1 has pile A containing only intra-domain certs, and pile B
> containing only inter-domain certs; option 2 has pile A containing only
> intra-domain certs and pite B containing all certs.  Which option is
> superior depends on two things:
> 
>    whether you care more about storage efficiency in the directory (option
>    2 stores intra-domain certificates twice) or retrieval efficiency for
>    the verifier (option 1 require a verifier that wants all a target CA's
>    certificates to retrieve them from two places).
>    typical usage scenarios by verifiers - i.e. the percentage of clients
>    that are going to want to locate just inter-domain certs, compared to
>    clients that either don't care about the difference or are only
>    interested in intra-domain certs.  Retrieval of _just_ inter-domain
>    certs is easier under option 1, retrieval of _all_ certs is easier under
>    option 2, and retrieval of _just_ intra-domain certs is the same under
>    both options.
> 
> Consider a fairly randomly structured PKI, where the verifier has a set of
> trusted roots loaded into it (assume they've been loaded under user
> control, with no particular order to them), and is trying to verify the key
> of some server that it hasn't spoken to before.  It has no idea of which
> "domain" the target's CA thinks it belongs to; it just wants to pull all
> the certs that have that CA as a subject, and see if it can construct a
> valid chain starting at one of its trusted roots.
> 
> Having the target CA divide its certificates between two places within the
> directory is no help to this verifier.  All it does it force the verifier
> to make two retrieval operations instead of the one that would be required
> by option 2.  The verifier isn't really interested in whether a particular
> certificate comes from another CA from the same "domain" as the target's CA
> - if it cares about "domains" at all, what it would be interested in is if
> any certs come from the same domain as the verifier (or one of its trusted
> roots), not the target (and of course that's verifier-specific).

	John,  the verifier does NOT have to invoke two retrieval operations. 
The verifier simply reads the CA entry requesting both the cACertificate
attribute and the crossCertificatePair attribute in the same search/read
operation.  All certificates are returned.  The verifier can then decide
whether to explore inter-domain, intra-domain, both , none, whatever. 
The verifier can lump them all together in the client application if
they like!  The main advantage to option 1 is we don't store the
certificates twice which is  a fundamental goal in all database
applications.   IMHO it applies to repositories and public key
infrastructures also.

	In summary option 1 never ever hurts the client.  It only helps to
organize the two types of certs based on the CAs definition of domain.  

	The general algorithm we envision is for clients to first explore the
cACertificate attribute, then explore the crossCertificatePair
attribute.   That way nothing will get missed.  It's not an all or
nothing choice.  It's an attempt to store the certificates once and to
group them to make logical decisions when exploring possibly complex
paths.
 
> 
> For the special (and probably quite common) case where the verifier and
> target happen to be in the same domain, the distinction probably is useful.
> Option 2 supports this case just as well as does option 1, by allowing the
> CA to place intra-domain certs in a separate place so that clients in that
> domain can retrieve them first (or possibly even _instead_of_ going to the
> all-certs list).

	But it duplicates the data, for which there is no technically sound
reason.

Dave Horvath
> John

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Thu, 03 Sep 1998 10:34:19 -0400
To: "Bob Jueneman" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject: Re: What the straw poll means
Cc: [email-masked]
Sender: [email-masked]

Bob,

At 06:33 PM 9/2/98 -0600, you wrote:
>This is almost as exciting as watching a horse race!
>
>But what are we to make of the situation if the vote is as 
>close as it appears to be at present -- does that truly indicate 
>a "rough consensus"?
>
>As of earlier this morning, Chromatix was ahead, with 
>8 votes cast; Entrust was tied with Microsoft with 4 votes 
>cast; and MISSI some others are clustered around third place.
>
>So far, with the exception of a split between MISSI and NIST
>as two US Government factions, the voting seems to be 
>strictly by company.

I hope you don't think that the government is particularly monolithic about
such things.

Tim Polk at times has lived in dread of the possibility that I might vote
for something on one of the PKIX 1 straw polls, that would have caused him
a lot of grief as editor.  That's entirely within NIST.

>
>Now, the polite fiction within the IETF is that memberships are by
>individual, and that there are no "votes" per se, and certainly not 
>on a company by company basis. That's the fiction, at least.. 
>Whether this convention shall long endure now that the IETF has 
>apparently lost some or all of its government funding and has 
>to become more self-sufficient will be interesting to see.
>
>But unless one side or the other starts to make some significant
>in-roads by the dint of more persuasive technical argument, then I think
>it's effectively a draw, and we may be counting companies and their 
>installed base at least as much, and perhaps more, than 
>balancing the technical alternatives.

As a Government guy, who has been doing computer standards work for a
couple of decades, I have a rough philosophy about this, which gives a lot
of deference to the investments of early implementors.  In most cases, for
new technologies at least, we the government, haven't made much up front
development investment in implementing technology alternatives. Of course
MISSI and DMS are the exception to this rule here, but, on the civil side
of the government, we don't have big money to put into development.  We
don't usually have a big investment already on the table.  So it's easy to
advocate an "ignore the developer's investment" viewpoint.  But we don't
ever have a competitive reason to want to shaft a competitor who'se ahead
of us in the marketplace, either.  

I think that it's destructive of standards development in general to
unnecessarily shaft early implementors.  I want to encourage companies to
take the plunge and go ahead and build something, not wait for a standard
to get finished first.  There are a lot of risks in this for the
implementors, and I don't want to add to them.  So I tend to give a lot of
deference to the investments of early implementors, because I think that it
makes the process of creating standards work better.

Now there are some minor Government installed base issues.  Many, perhaps
most, of the PKI applications and pilots in the civil part of the
government that use what I would call a "full function" PKI, are based on
one commercial product at this point. But we're not talking a lot of big
operational systems here.  What is important to me is that the vendor of
that product has been effective in pioneering commercial PKI products that
actually build nontrivial certification paths and do nice things like
revocation. I frankly like Option 1 better, in the abstract, but I think
that the technical effect of either choice is not profound as far as I can
see, and I'm quite uncomfortable voting for something that apparently
shafts the pioneer commercial implementor a bit.  

Regards,

Bill Burr

Date: Thu, 03 Sep 1998 09:56:48 -0400
From: Susan Joseph <[email-masked]>
Reply-To: [email-masked]
Organization: BBN
To: [email-masked]
Subject: Option 1
Sender: [email-masked]

--
Susan Joseph
GTE Internetworking
9810 Patuxent Woods Drive
Columbia, MD 21046
Tel:  (410) 309-8324
Fax: (410) 309-8315
E-Mail:  [email-masked]

Date: 3 Sep 1998 08:52:29 -0400
Subject: For Option 1
To: "PKIX Mail List" <[email-masked]>
From: "Chris Francis" <[email-masked]>
Sender: [email-masked]

                                             Inter-Office Memo
                                      For Option 1

Chris Francis
Raytheon Systems

Date: Thu, 03 Sep 1998 08:53:19 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: Nada Kapidzic Cicovic <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
Subject: Re: What the straw poll means
Sender: [email-masked]

Nada Kapidzic Cicovic wrote:
> 
> At 20:48 9/2/98 -0400, Santosh Chokhani wrote:
> >Yes Bob.  I hate to say this, but you have misinterpreted.
> >
> >The basic difference between the two approaches is the under option 1
> >you store a certificate only one time under a CA's entry.  Which
> >certifying CA is in its domain is upto a subject CA to decide.
> >
> >In all honesty, I do not see a benefit to option 2 except for the
> >argument that some installed base already does it this way.
> >
> >Option 1 achieves everything option 2 and with efficiency.
> >
> >I do not understand how option 2 solves your problems either.  We need
> >to have a discussion on computational complexity of path development to
> >allay your concerns.
> >
> >The way I look at the difference between the two options is that if
> >n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
> >bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
> >another.  When you retrieve the two buckets (which you must for path
> >development efficiency), option 2 gives you n+n1 certificates and option
> >1 gives you exactly all n.
> 
> With option 2 you do not have to look at n1 certificates (cACertificate
> attribute) at all. The n ones (from crossCertificatePair) are sufficient
> for your path building.

	We are back the problem we raised earlier.  Clients that attempt to
efficiently develop a path from the end entity to the trusted root must
explore 'n' paths (worst case scenario)  prior to finding the correct
one with option 2.  Option 1 helps in this area, but this gets back to
the definition of domain since paths in our domain will probably be the
most efficient.  Is it really a problem if all CAs do NOT standardize on
a definition for domain?  I don't think so.  An algorithm for efficient
path development (end entity to root) should always explore paths using
the cACertifcate first, then fall back to the crossCertificatePair
attribute.  That way the last resort is to explore cross
certifications.   With option 1 this is accomplished without duplication
of data. 

	Using this algorithm a CA may interpret the domain as it wishes, with
only performance impacts to path development on the client side.  

	Building a path from the root to the end entity is not a problem
either.  If the CA chooses, it may store all certificates that it issues
in the reverse component of the crossCertificatePair attribute.  That
way a client can explore all possibilities.

	Option 1 satisfies requirements for building path in either direction
without duplicating data and adds increased efficiency at the CAs
discretion.

Dave Horvath

> 
> Nada
> 
> >
> >> -----Original Message-----
> >> From:        Bob Jueneman [SMTP:[email-masked]]
> >> Sent:        Wednesday, September 02, 1998 8:33 PM
> >> To:  [email-masked]
> >> Cc:  [email-masked]
> >> Subject:     What the straw poll means
> >>
> >> This is almost as exciting as watching a horse race!
> >>
> >> But what are we to make of the situation if the vote is as
> >> close as it appears to be at present -- does that truly indicate
> >> a "rough consensus"?
> >>
> >> As of earlier this morning, Chromatix was ahead, with
> >> 8 votes cast; Entrust was tied with Microsoft with 4 votes
> >> cast; and MISSI some others are clustered around third place.
> >>
> >> So far, with the exception of a split between MISSI and NIST
> >> as two US Government factions, the voting seems to be
> >> strictly by company.
> >>
> >> Now, the polite fiction within the IETF is that memberships are by
> >> individual, and that there are no "votes" per se, and certainly not
> >> on a company by company basis. That's the fiction, at least..
> >> Whether this convention shall long endure now that the IETF has
> >> apparently lost some or all of its government funding and has
> >> to become more self-sufficient will be interesting to see.
> >>
> >> But unless one side or the other starts to make some significant
> >> in-roads by the dint of more persuasive technical argument, then I
> >> think
> >> it's effectively a draw, and we may be counting companies and their
> >> installed base at least as much, and perhaps more, than
> >> balancing the technical alternatives.
> >>
> >> Now, if we are truly at a technical impasse and the vote has to be
> >> binary, i.e., only one way or the other, then maybe counting installed
> >> clients and minimizing the pain is really the way to go, but frankly
> >> that approach makes me uncomfortable.  I want both interoperability
> >> AND efficiency, and I would hate to see us don't want to be
> >> pressured into a less than satisfactory decision, whatever that is,
> >>  just because we are in a rush to get over the next hurdle in the
> >> standards progression.
> >>
> >> I originally said that I was inclined to go with option 1, because
> >> it at least appeared to be simpler.  However, I also said that I was
> >> concerned about the "local" definition of a domain by a CA,
> >> and the more I think about it, the more concerned I get.
> >>
> >> That approach might be viable for an organization such as MISSI,
> >> where everyone presumably knows what community of interest
> >> they fall into, but how would it apply to a public CA such as
> >> VeriSign?
> >>
> >> Would they view all of their certificates as falling into one domain,
> >> including any certificates issued by subordinate CAs, as in the case
> >> of the old RSA Commercial hierarchy?
> >>
> >> What about GTE CyberTrust, considering their presumed affinity
> >> with their ISP business. Would all of those certificates fall into
> >> one domain?
> >>
> >> Now suppose I want to validate a certificate from Erols.  Do I decide
> >> that
> >> because Erols is in the top half of the alphabet that they probably
> >> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an
> >> East Coast/West Coast split, like radio and TV stations use W or K in
> >> their call sign?
> >>
> >> What if Novell and Microsoft were to become CAs and issue certificates
> >>
> >> to their customers directly, at least their larger accounts.  Would
> >> the relying
> >> party have to try to divine whether a subscriber was running NetWare
> >> or
> >> NT in order to decide what domain they would be likely to be in?
> >>
> >> Santosh, have I misrepresented the issue here?  Feel free to correct
> >> me, if so.
> >> Maybe I just don't understand.
> >>
> >> Now, if the definition of "domain" were amended somewhat, perhaps some
> >> of these difficulties might go away.
> >>
> >> In particular, it seems to me that "domain" probably ought to have a
> >> lot to do
> >> with name subordination, or at least the possibility of doing name
> >> subordination,
> >> so that it would be deterministic.  That might not solve all of the
> >> concerns that those
> >> who are inclined to vote for option 2 might have in mind, but it might
> >> help.
> >>
> >> So if I am a Novell employee, and I receive an S/MIME message that
> >> contains
> >> a certificate that begins with c=US, o=Novell, I can probably make an
> >> excellent
> >> good guess of what CA to go to, assuming that Novell operates a CA in
> >> its
> >> own name.  But where do I go for a certificate from Acme
> >> Manufacturing?
> >>
> >> I don't mean to beat up on the option 1 folks exclusively -- maybe
> >> there are
> >> some things that could be done within the options 2 that would come
> >> closer to a
> >> compromise without breaking those existing clients.  But I need to
> >> think about that
> >> some more.  maybe someone else could volunteer some suggestions.
> >>
> >> Bob
> >>
> >> Robert R. Jueneman
> >> Novell, Inc.
> >> 122 E. 1700 South
> >> Provo, UT 84606
> >> [email-masked]
> >> 1-801-861-7387
> >

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

From: [email-masked]
To: Santosh Chokhani <[email-masked]>
cc: [email-masked]
Date: Thu, 3 Sep 1998 08:50:38 -0400
Subject: RE: What the straw poll means
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk

Santosh Chokhani <[email-masked]> writes:

>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.

The difference between the two options is primarily storage efficiency vs.
retrieval efficiency.  Both options divide a CAs certs into two piles.
Option 1 has pile A containing only intra-domain certs, and pile B
containing only inter-domain certs; option 2 has pile A containing only
intra-domain certs and pite B containing all certs.  Which option is
superior depends on two things:

   whether you care more about storage efficiency in the directory (option
   2 stores intra-domain certificates twice) or retrieval efficiency for
   the verifier (option 1 require a verifier that wants all a target CA's
   certificates to retrieve them from two places).
   typical usage scenarios by verifiers - i.e. the percentage of clients
   that are going to want to locate just inter-domain certs, compared to
   clients that either don't care about the difference or are only
   interested in intra-domain certs.  Retrieval of _just_ inter-domain
   certs is easier under option 1, retrieval of _all_ certs is easier under
   option 2, and retrieval of _just_ intra-domain certs is the same under
   both options.

Consider a fairly randomly structured PKI, where the verifier has a set of
trusted roots loaded into it (assume they've been loaded under user
control, with no particular order to them), and is trying to verify the key
of some server that it hasn't spoken to before.  It has no idea of which
"domain" the target's CA thinks it belongs to; it just wants to pull all
the certs that have that CA as a subject, and see if it can construct a
valid chain starting at one of its trusted roots.

Having the target CA divide its certificates between two places within the
directory is no help to this verifier.  All it does it force the verifier
to make two retrieval operations instead of the one that would be required
by option 2.  The verifier isn't really interested in whether a particular
certificate comes from another CA from the same "domain" as the target's CA
- if it cares about "domains" at all, what it would be interested in is if
any certs come from the same domain as the verifier (or one of its trusted
roots), not the target (and of course that's verifier-specific).

For the special (and probably quite common) case where the verifier and
target happen to be in the same domain, the distinction probably is useful.
Option 2 supports this case just as well as does option 1, by allowing the
CA to place intra-domain certs in a separate place so that clients in that
domain can retrieve them first (or possibly even _instead_of_ going to the
all-certs list).

John

Date: Thu, 03 Sep 1998 08:27:50 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: Sean Mullan <[email-masked]>
CC: Sharon Boeyen <[email-masked]>, [email-masked]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
Sender: [email-masked]

Sean Mullan wrote:
> 
> I agree that the forward & reverse elements of the crossCertificatePair
> are useful. It would be nice if the cACertificate attribute contained
> forward and reverse elements too.
> 
> One issue I have with the crossCertificatePair and the forward &
> reverse elements is that I believe they are a single-valued pair (meaning
> you can't have more than one forward/reverse element per pair).
> What do you do if CA1 issues more than 1 cross certificate to CA2
> (or vice versa)?

	Sean,
		The attribute is multi-valued, therefore, you would construct multiple
"single valued" pairs, and place them in the attribute.  The clients
could then determine the appropriate CA relationship
(crossCertificatePair) for the particular application.

Dave H

> 
> --Sean
> 
> Sharon Boeyen wrote:
> >
> > Hi Bob,
> >
> > I don't think we'll every get to a point where people stop populating the
> > crossCertificatePair attribute, regardless of the result of the straw poll.
> > The forward/reverse elements in the syntax of this attribute are very useful
> > since not all path discovery algorithms are identical. Path discovery can be
> > done many ways including beginning from the subject and moving toward a
> > trust anchor, beginning from a trust anchor and moving toward a subject,
> > beginning at both ends etc etc.   Being able to retrieve both forward and
> > reverse certificates from a single entry rather than checking the directory
> > entries of two CAs is a useful feature for some algorithms.
> > ------------------
> > Sharon Boeyen
> > Entrust Technologies
> >
> > mailto:[email-masked]  Tel: (613) 247-3181
> > http://www.entrust.com            Fax: (613) 247-3690
> >
> >
> > > ----------
> > > From:         Bob Jueneman[SMTP:[email-masked]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [email-masked]; [email-masked]; [email-masked]
> > > Subject:      Re: Straw Poll cACertificate &
> > > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > >
> > > I'm still on the fence, and trying to decide between the two options.
> > >
> > > But why is a binary decision necessary?
> > >
> > > If I understand Tim's points, option 2 is a superset of option 1,
> > > and a significant number of clients only support option 2.
> > >
> > > Option 1, however, is at least arguably superior from a network and
> > > directory performance standpoint, although I am still very confused
> > > about exactly who defines a "domain" and how the relying party is
> > > supposed to intuit what "local choice" some CA made.
> > >
> > > Would a viable compromise position be to support option 2 as the initial
> > > direction, and to transition to option 1 at some later point in time, say
> > > 36 months from now, assuming further work clearly establishes that
> > > option 1 is completely workable?
> > >
> > > My directory guys assure me that the directory is effectively neutral in
> > > this,
> > > except for the possible performance issues.  So all that has to happen
> > > is for CAs to stop populating the crossCertificate pair. Is that correct?
> > >
> > > On the other hand, does this give rise to a worst of both worlds case
> > > from the perspective of the client software complexity?
> > >
> > > Bob
> > >

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

Date: Thu, 03 Sep 1998 08:00:17 -0400
From: Richard Pimental <[email-masked]>
Organization: Chromatix, Inc.
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------BBC97F524D955BDFBA611C8B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------BBC97F524D955BDFBA611C8B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Pimental
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Richard Pimental
n:              Pimental;Richard
org:            Chromatix, Inc.
adr:            Chromatix, Inc.;;10451 Twin Rivers Road, Suite 265;Columbia;MD;21044;US
email;internet: [email-masked]
title:          Software Engineer
tel;work:       (301) 596-8466
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------BBC97F524D955BDFBA611C8B--

From: Sharon Boeyen <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], "'Santosh Chokhani'" <[email-masked]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 12:35:00 +0100
Sender: [email-masked]

The "two buckets" is exactly what I was trying to avoid in the earlier
debate on this topic, however I believe that the single bucket option
was rejected in the Chicago meeting. The single bucket option is the
text which is currently in the Internet Draft. With that text, all self
signed (or self issued certificates) were to be placed in the
cACertificate attribute and all certificates issued by one CA to a
different CA were put in the crossCertificatePair attribute. Depending
on the particular path development algorithm being used by a relying
party, directory search tools, especially when we evolve to LDAPv3 could
be used to filter the content of the forward and or reverse elements of
that SINGLE attribute and provide the relying party with the set of
certificates of interest to that particular relying party. 

I still believe that this is the best solution because the relying party
systems are the ones that know which certs are of interest to them, not
the CA that happened to issue the certs, especially in the post PEM
world where any CA could legitimately have certs issued for it by
several CAs.

My strong support for Option 2 in the straw poll is because the above
was rejected by the meeting and I see Option 2 as a workable compromise
ONLY because there is a complete set of certs in a single attribute and
relying parties can do what is of interest to them without knowing the
definition of domain which each individual CA happens to use. For self
contained environments wanting to make use of a CA or set of CAs certs
issued within some locally defined domain, this is still possible.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 2, 1998 8:48 PM
> To: 	'Bob Jueneman'; [email-masked]
> Cc: 	Santosh Chokhani
> Subject: 	RE: What the straw poll means
> 
> Yes Bob.  I hate to say this, but you have misinterpreted.
> 
> The basic difference between the two approaches is the under option 1
> you store a certificate only one time under a CA's entry.  Which
> certifying CA is in its domain is upto a subject CA to decide.
> 
> In all honesty, I do not see a benefit to option 2 except for the
> argument that some installed base already does it this way.
> 
> Option 1 achieves everything option 2 and with efficiency.
> 
> I do not understand how option 2 solves your problems either.  We need
> to have a discussion on computational complexity of path development
> to
> allay your concerns.
> 
> The way I look at the difference between the two options is that if
> n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in
> one
> bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
> another.  When you retrieve the two buckets (which you must for path
> development efficiency), option 2 gives you n+n1 certificates and
> option
> 1 gives you exactly all n.
> 
> > -----Original Message-----
> > From:	Bob Jueneman [SMTP:[email-masked]]
> > Sent:	Wednesday, September 02, 1998 8:33 PM
> > To:	[email-masked]
> > Cc:	[email-masked]
> > Subject:	What the straw poll means
> > 
> > This is almost as exciting as watching a horse race!
> > 
> > But what are we to make of the situation if the vote is as 
> > close as it appears to be at present -- does that truly indicate 
> > a "rough consensus"?
> > 
> > As of earlier this morning, Chromatix was ahead, with 
> > 8 votes cast; Entrust was tied with Microsoft with 4 votes 
> > cast; and MISSI some others are clustered around third place.
> > 
> > So far, with the exception of a split between MISSI and NIST
> > as two US Government factions, the voting seems to be 
> > strictly by company.
> > 
> > Now, the polite fiction within the IETF is that memberships are by
> > individual, and that there are no "votes" per se, and certainly not 
> > on a company by company basis. That's the fiction, at least.. 
> > Whether this convention shall long endure now that the IETF has 
> > apparently lost some or all of its government funding and has 
> > to become more self-sufficient will be interesting to see.
> > 
> > But unless one side or the other starts to make some significant
> > in-roads by the dint of more persuasive technical argument, then I
> > think
> > it's effectively a draw, and we may be counting companies and their 
> > installed base at least as much, and perhaps more, than 
> > balancing the technical alternatives.
> > 
> > Now, if we are truly at a technical impasse and the vote has to be 
> > binary, i.e., only one way or the other, then maybe counting
> installed
> > clients and minimizing the pain is really the way to go, but frankly
> 
> > that approach makes me uncomfortable.  I want both interoperability
> > AND efficiency, and I would hate to see us don't want to be 
> > pressured into a less than satisfactory decision, whatever that is,
> >  just because we are in a rush to get over the next hurdle in the 
> > standards progression.
> > 
> > I originally said that I was inclined to go with option 1, because 
> > it at least appeared to be simpler.  However, I also said that I was
> 
> > concerned about the "local" definition of a domain by a CA,
> > and the more I think about it, the more concerned I get.
> > 
> > That approach might be viable for an organization such as MISSI,
> > where everyone presumably knows what community of interest 
> > they fall into, but how would it apply to a public CA such as
> > VeriSign?
> > 
> > Would they view all of their certificates as falling into one
> domain,
> > including any certificates issued by subordinate CAs, as in the case
> > of the old RSA Commercial hierarchy?
> > 
> > What about GTE CyberTrust, considering their presumed affinity
> > with their ISP business. Would all of those certificates fall into
> > one domain?
> > 
> > Now suppose I want to validate a certificate from Erols.  Do I
> decide
> > that
> > because Erols is in the top half of the alphabet that they probably 
> > use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
> > East Coast/West Coast split, like radio and TV stations use W or K
> in 
> > their call sign?
> > 
> > What if Novell and Microsoft were to become CAs and issue
> certificates
> > 
> > to their customers directly, at least their larger accounts.  Would
> > the relying 
> > party have to try to divine whether a subscriber was running NetWare
> > or
> > NT in order to decide what domain they would be likely to be in?
> > 
> > Santosh, have I misrepresented the issue here?  Feel free to correct
> > me, if so.
> > Maybe I just don't understand.
> > 
> > Now, if the definition of "domain" were amended somewhat, perhaps
> some
> > of these difficulties might go away.
> > 
> > In particular, it seems to me that "domain" probably ought to have a
> > lot to do 
> > with name subordination, or at least the possibility of doing name
> > subordination, 
> > so that it would be deterministic.  That might not solve all of the
> > concerns that those
> > who are inclined to vote for option 2 might have in mind, but it
> might
> > help.
> > 
> > So if I am a Novell employee, and I receive an S/MIME message that
> > contains 
> > a certificate that begins with c=US, o=Novell, I can probably make
> an
> > excellent 
> > good guess of what CA to go to, assuming that Novell operates a CA
> in
> > its 
> > own name.  But where do I go for a certificate from Acme
> > Manufacturing?
> > 
> > I don't mean to beat up on the option 1 folks exclusively -- maybe
> > there are 
> > some things that could be done within the options 2 that would come
> > closer to a
> > compromise without breaking those existing clients.  But I need to
> > think about that
> > some more.  maybe someone else could volunteer some suggestions.
> > 
> > Bob
> > 
> > Robert R. Jueneman
> > Novell, Inc.
> > 122 E. 1700 South
> > Provo, UT 84606
> > [email-masked]
> > 1-801-861-7387
> 

From: Sharon Boeyen <[email-masked]>
To: Sharon Boeyen <[email-masked]>, "'Sean Mullan'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX  LDAPv2 schema I-D
Date: Thu, 3 Sep 1998 11:57:20 +0100
Sender: [email-masked]

Sean, re your question on crossCertificatePair - This is a multi-valued
attribute and there can be any number of instances of
CrossCertificatePair. So if CA1 issued more than one certificate to CA2,
these can all be present in the same attribute, just in a different
instance of CertificatePair.    

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Sean Mullan[SMTP:[email-masked]]
> Sent: 	September 2, 1998 4:32 PM
> To: 	Sharon Boeyen
> Cc: 	[email-masked]
> Subject: 	Re: Straw Poll cACertificate &
> crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
> 
> I agree that the forward & reverse elements of the
> crossCertificatePair
> are useful. It would be nice if the cACertificate attribute contained
> forward and reverse elements too.
> 
> One issue I have with the crossCertificatePair and the forward & 
> reverse elements is that I believe they are a single-valued pair
> (meaning
> you can't have more than one forward/reverse element per pair).
> What do you do if CA1 issues more than 1 cross certificate to CA2
> (or vice versa)?
> 
> --Sean
>  
> Sharon Boeyen wrote:
> > 
> > Hi Bob,
> > 
> > I don't think we'll every get to a point where people stop
> populating the
> > crossCertificatePair attribute, regardless of the result of the
> straw poll.
> > The forward/reverse elements in the syntax of this attribute are
> very useful
> > since not all path discovery algorithms are identical. Path
> discovery can be
> > done many ways including beginning from the subject and moving
> toward a
> > trust anchor, beginning from a trust anchor and moving toward a
> subject,
> > beginning at both ends etc etc.   Being able to retrieve both
> forward and
> > reverse certificates from a single entry rather than checking the
> directory
> > entries of two CAs is a useful feature for some algorithms.
> > ------------------
> > Sharon Boeyen
> > Entrust Technologies
> > 
> > mailto:[email-masked]  Tel: (613) 247-3181
> > http://www.entrust.com            Fax: (613) 247-3690
> > 
> > 
> > > ----------
> > > From:         Bob Jueneman[SMTP:[email-masked]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [email-masked]; [email-masked]; [email-masked]
> > > Subject:      Re: Straw Poll cACertificate &
> > > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > >
> > > I'm still on the fence, and trying to decide between the two
> options.
> > >
> > > But why is a binary decision necessary?
> > >
> > > If I understand Tim's points, option 2 is a superset of option 1,
> > > and a significant number of clients only support option 2.
> > >
> > > Option 1, however, is at least arguably superior from a network
> and
> > > directory performance standpoint, although I am still very
> confused
> > > about exactly who defines a "domain" and how the relying party is
> > > supposed to intuit what "local choice" some CA made.
> > >
> > > Would a viable compromise position be to support option 2 as the
> initial
> > > direction, and to transition to option 1 at some later point in
> time, say
> > > 36 months from now, assuming further work clearly establishes that
> > > option 1 is completely workable?
> > >
> > > My directory guys assure me that the directory is effectively
> neutral in
> > > this,
> > > except for the possible performance issues.  So all that has to
> happen
> > > is for CAs to stop populating the crossCertificate pair. Is that
> correct?
> > >
> > > On the other hand, does this give rise to a worst of both worlds
> case
> > > from the perspective of the client software complexity?
> > >
> > > Bob
> > >
> 

Date: Thu, 03 Sep 1998 11:02:39 +0200
To: Santosh Chokhani <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[email-masked]>
Sender: [email-masked]

At 20:48 9/2/98 -0400, Santosh Chokhani wrote:
>Yes Bob.  I hate to say this, but you have misinterpreted.
>
>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.
>
>Option 1 achieves everything option 2 and with efficiency.
>
>I do not understand how option 2 solves your problems either.  We need
>to have a discussion on computational complexity of path development to
>allay your concerns.
>
>The way I look at the difference between the two options is that if
>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>another.  When you retrieve the two buckets (which you must for path
>development efficiency), option 2 gives you n+n1 certificates and option
>1 gives you exactly all n.

With option 2 you do not have to look at n1 certificates (cACertificate
attribute) at all. The n ones (from crossCertificatePair) are sufficient
for your path building.

Nada

>
>> -----Original Message-----
>> From:	Bob Jueneman [SMTP:[email-masked]]
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[email-masked]
>> Cc:	[email-masked]
>> Subject:	What the straw poll means
>> 
>> This is almost as exciting as watching a horse race!
>> 
>> But what are we to make of the situation if the vote is as 
>> close as it appears to be at present -- does that truly indicate 
>> a "rough consensus"?
>> 
>> As of earlier this morning, Chromatix was ahead, with 
>> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
>> cast; and MISSI some others are clustered around third place.
>> 
>> So far, with the exception of a split between MISSI and NIST
>> as two US Government factions, the voting seems to be 
>> strictly by company.
>> 
>> Now, the polite fiction within the IETF is that memberships are by
>> individual, and that there are no "votes" per se, and certainly not 
>> on a company by company basis. That's the fiction, at least.. 
>> Whether this convention shall long endure now that the IETF has 
>> apparently lost some or all of its government funding and has 
>> to become more self-sufficient will be interesting to see.
>> 
>> But unless one side or the other starts to make some significant
>> in-roads by the dint of more persuasive technical argument, then I
>> think
>> it's effectively a draw, and we may be counting companies and their 
>> installed base at least as much, and perhaps more, than 
>> balancing the technical alternatives.
>> 
>> Now, if we are truly at a technical impasse and the vote has to be 
>> binary, i.e., only one way or the other, then maybe counting installed
>> clients and minimizing the pain is really the way to go, but frankly 
>> that approach makes me uncomfortable.  I want both interoperability
>> AND efficiency, and I would hate to see us don't want to be 
>> pressured into a less than satisfactory decision, whatever that is,
>>  just because we are in a rush to get over the next hurdle in the 
>> standards progression.
>> 
>> I originally said that I was inclined to go with option 1, because 
>> it at least appeared to be simpler.  However, I also said that I was  
>> concerned about the "local" definition of a domain by a CA,
>> and the more I think about it, the more concerned I get.
>> 
>> That approach might be viable for an organization such as MISSI,
>> where everyone presumably knows what community of interest 
>> they fall into, but how would it apply to a public CA such as
>> VeriSign?
>> 
>> Would they view all of their certificates as falling into one domain,
>> including any certificates issued by subordinate CAs, as in the case
>> of the old RSA Commercial hierarchy?
>> 
>> What about GTE CyberTrust, considering their presumed affinity
>> with their ISP business. Would all of those certificates fall into
>> one domain?
>> 
>> Now suppose I want to validate a certificate from Erols.  Do I decide
>> that
>> because Erols is in the top half of the alphabet that they probably 
>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
>> East Coast/West Coast split, like radio and TV stations use W or K in 
>> their call sign?
>> 
>> What if Novell and Microsoft were to become CAs and issue certificates
>> 
>> to their customers directly, at least their larger accounts.  Would
>> the relying 
>> party have to try to divine whether a subscriber was running NetWare
>> or
>> NT in order to decide what domain they would be likely to be in?
>> 
>> Santosh, have I misrepresented the issue here?  Feel free to correct
>> me, if so.
>> Maybe I just don't understand.
>> 
>> Now, if the definition of "domain" were amended somewhat, perhaps some
>> of these difficulties might go away.
>> 
>> In particular, it seems to me that "domain" probably ought to have a
>> lot to do 
>> with name subordination, or at least the possibility of doing name
>> subordination, 
>> so that it would be deterministic.  That might not solve all of the
>> concerns that those
>> who are inclined to vote for option 2 might have in mind, but it might
>> help.
>> 
>> So if I am a Novell employee, and I receive an S/MIME message that
>> contains 
>> a certificate that begins with c=US, o=Novell, I can probably make an
>> excellent 
>> good guess of what CA to go to, assuming that Novell operates a CA in
>> its 
>> own name.  But where do I go for a certificate from Acme
>> Manufacturing?
>> 
>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>> there are 
>> some things that could be done within the options 2 that would come
>> closer to a
>> compromise without breaking those existing clients.  But I need to
>> think about that
>> some more.  maybe someone else could volunteer some suggestions.
>> 
>> Bob
>> 
>> Robert R. Jueneman
>> Novell, Inc.
>> 122 E. 1700 South
>> Provo, UT 84606
>> [email-masked]
>> 1-801-861-7387
>

Date: Wed, 02 Sep 1998 19:09:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: What the straw poll means
Sender: [email-masked]

Santosh doesn't seem to have answered the questions I've raised
regarding the definition of the domain, but he seems to believe that
option 2 doesn't solve that problem either.

If so, I am increasingly beginning to lean towards "NONE OF THE 
ABOVE".

Rebuttal, Sharon/Carlisle?

Bob

>Yes Bob.  I hate to say this, but you have misinterpreted.
>
>The basic difference between the two approaches is the under option 1
>you store a certificate only one time under a CA's entry.  Which
>certifying CA is in its domain is upto a subject CA to decide.
>
>In all honesty, I do not see a benefit to option 2 except for the
>argument that some installed base already does it this way.
>
>Option 1 achieves everything option 2 and with efficiency.
>
>I do not understand how option 2 solves your problems either.  We need
>to have a discussion on computational complexity of path development to
>allay your concerns.
>
>The way I look at the difference between the two options is that if
>n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
>bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
>another.  When you retrieve the two buckets (which you must for path
>development efficiency), option 2 gives you n+n1 certificates and option
>1 gives you exactly all n.
>
>> -----Original Message-----
>> From:	Bob Jueneman [SMTP:[email-masked]] 
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[email-masked] 
>> Cc:	[email-masked] 
>> Subject:	What the straw poll means
>> 
>> This is almost as exciting as watching a horse race!
>> 
>> But what are we to make of the situation if the vote is as 
>> close as it appears to be at present -- does that truly indicate 
>> a "rough consensus"?
>> 
>> As of earlier this morning, Chromatix was ahead, with 
>> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
>> cast; and MISSI some others are clustered around third place.
>> 
>> So far, with the exception of a split between MISSI and NIST
>> as two US Government factions, the voting seems to be 
>> strictly by company.
>> 
>> Now, the polite fiction within the IETF is that memberships are by
>> individual, and that there are no "votes" per se, and certainly not 
>> on a company by company basis. That's the fiction, at least.. 
>> Whether this convention shall long endure now that the IETF has 
>> apparently lost some or all of its government funding and has 
>> to become more self-sufficient will be interesting to see.
>> 
>> But unless one side or the other starts to make some significant
>> in-roads by the dint of more persuasive technical argument, then I
>> think
>> it's effectively a draw, and we may be counting companies and their 
>> installed base at least as much, and perhaps more, than 
>> balancing the technical alternatives.
>> 
>> Now, if we are truly at a technical impasse and the vote has to be 
>> binary, i.e., only one way or the other, then maybe counting installed
>> clients and minimizing the pain is really the way to go, but frankly 
>> that approach makes me uncomfortable.  I want both interoperability
>> AND efficiency, and I would hate to see us don't want to be 
>> pressured into a less than satisfactory decision, whatever that is,
>>  just because we are in a rush to get over the next hurdle in the 
>> standards progression.
>> 
>> I originally said that I was inclined to go with option 1, because 
>> it at least appeared to be simpler.  However, I also said that I was  
>> concerned about the "local" definition of a domain by a CA,
>> and the more I think about it, the more concerned I get.
>> 
>> That approach might be viable for an organization such as MISSI,
>> where everyone presumably knows what community of interest 
>> they fall into, but how would it apply to a public CA such as
>> VeriSign?
>> 
>> Would they view all of their certificates as falling into one domain,
>> including any certificates issued by subordinate CAs, as in the case
>> of the old RSA Commercial hierarchy?
>> 
>> What about GTE CyberTrust, considering their presumed affinity
>> with their ISP business. Would all of those certificates fall into
>> one domain?
>> 
>> Now suppose I want to validate a certificate from Erols.  Do I decide
>> that
>> because Erols is in the top half of the alphabet that they probably 
>> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
>> East Coast/West Coast split, like radio and TV stations use W or K in 
>> their call sign?
>> 
>> What if Novell and Microsoft were to become CAs and issue certificates
>> 
>> to their customers directly, at least their larger accounts.  Would
>> the relying 
>> party have to try to divine whether a subscriber was running NetWare
>> or
>> NT in order to decide what domain they would be likely to be in?
>> 
>> Santosh, have I misrepresented the issue here?  Feel free to correct
>> me, if so.
>> Maybe I just don't understand.
>> 
>> Now, if the definition of "domain" were amended somewhat, perhaps some
>> of these difficulties might go away.
>> 
>> In particular, it seems to me that "domain" probably ought to have a
>> lot to do 
>> with name subordination, or at least the possibility of doing name
>> subordination, 
>> so that it would be deterministic.  That might not solve all of the
>> concerns that those
>> who are inclined to vote for option 2 might have in mind, but it might
>> help.
>> 
>> So if I am a Novell employee, and I receive an S/MIME message that
>> contains 
>> a certificate that begins with c=US, o=Novell, I can probably make an
>> excellent 
>> good guess of what CA to go to, assuming that Novell operates a CA in
>> its 
>> own name.  But where do I go for a certificate from Acme
>> Manufacturing?
>> 
>> I don't mean to beat up on the option 1 folks exclusively -- maybe
>> there are 
>> some things that could be done within the options 2 that would come
>> closer to a
>> compromise without breaking those existing clients.  But I need to
>> think about that
>> some more.  maybe someone else could volunteer some suggestions.
>> 
>> Bob
>> 
>> Robert R. Jueneman
>> Novell, Inc.
>> 122 E. 1700 South
>> Provo, UT 84606
>> [email-masked] 
>> 1-801-861-7387

From: Santosh Chokhani <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: Santosh Chokhani <[email-masked]>
Subject: RE: What the straw poll means
Date: Wed, 2 Sep 1998 20:48:05 -0400
Sender: [email-masked]

Yes Bob.  I hate to say this, but you have misinterpreted.

The basic difference between the two approaches is the under option 1
you store a certificate only one time under a CA's entry.  Which
certifying CA is in its domain is upto a subject CA to decide.

In all honesty, I do not see a benefit to option 2 except for the
argument that some installed base already does it this way.

Option 1 achieves everything option 2 and with efficiency.

I do not understand how option 2 solves your problems either.  We need
to have a discussion on computational complexity of path development to
allay your concerns.

The way I look at the difference between the two options is that if
n=n1+n2 certificates are issued to a CA, option 1says CA puts n1 in one
bucket and n2 in another.  Option 2 says put n in one bucket and n1 in
another.  When you retrieve the two buckets (which you must for path
development efficiency), option 2 gives you n+n1 certificates and option
1 gives you exactly all n.

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Wednesday, September 02, 1998 8:33 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	What the straw poll means
> 
> This is almost as exciting as watching a horse race!
> 
> But what are we to make of the situation if the vote is as 
> close as it appears to be at present -- does that truly indicate 
> a "rough consensus"?
> 
> As of earlier this morning, Chromatix was ahead, with 
> 8 votes cast; Entrust was tied with Microsoft with 4 votes 
> cast; and MISSI some others are clustered around third place.
> 
> So far, with the exception of a split between MISSI and NIST
> as two US Government factions, the voting seems to be 
> strictly by company.
> 
> Now, the polite fiction within the IETF is that memberships are by
> individual, and that there are no "votes" per se, and certainly not 
> on a company by company basis. That's the fiction, at least.. 
> Whether this convention shall long endure now that the IETF has 
> apparently lost some or all of its government funding and has 
> to become more self-sufficient will be interesting to see.
> 
> But unless one side or the other starts to make some significant
> in-roads by the dint of more persuasive technical argument, then I
> think
> it's effectively a draw, and we may be counting companies and their 
> installed base at least as much, and perhaps more, than 
> balancing the technical alternatives.
> 
> Now, if we are truly at a technical impasse and the vote has to be 
> binary, i.e., only one way or the other, then maybe counting installed
> clients and minimizing the pain is really the way to go, but frankly 
> that approach makes me uncomfortable.  I want both interoperability
> AND efficiency, and I would hate to see us don't want to be 
> pressured into a less than satisfactory decision, whatever that is,
>  just because we are in a rush to get over the next hurdle in the 
> standards progression.
> 
> I originally said that I was inclined to go with option 1, because 
> it at least appeared to be simpler.  However, I also said that I was  
> concerned about the "local" definition of a domain by a CA,
> and the more I think about it, the more concerned I get.
> 
> That approach might be viable for an organization such as MISSI,
> where everyone presumably knows what community of interest 
> they fall into, but how would it apply to a public CA such as
> VeriSign?
> 
> Would they view all of their certificates as falling into one domain,
> including any certificates issued by subordinate CAs, as in the case
> of the old RSA Commercial hierarchy?
> 
> What about GTE CyberTrust, considering their presumed affinity
> with their ISP business. Would all of those certificates fall into
> one domain?
> 
> Now suppose I want to validate a certificate from Erols.  Do I decide
> that
> because Erols is in the top half of the alphabet that they probably 
> use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
> East Coast/West Coast split, like radio and TV stations use W or K in 
> their call sign?
> 
> What if Novell and Microsoft were to become CAs and issue certificates
> 
> to their customers directly, at least their larger accounts.  Would
> the relying 
> party have to try to divine whether a subscriber was running NetWare
> or
> NT in order to decide what domain they would be likely to be in?
> 
> Santosh, have I misrepresented the issue here?  Feel free to correct
> me, if so.
> Maybe I just don't understand.
> 
> Now, if the definition of "domain" were amended somewhat, perhaps some
> of these difficulties might go away.
> 
> In particular, it seems to me that "domain" probably ought to have a
> lot to do 
> with name subordination, or at least the possibility of doing name
> subordination, 
> so that it would be deterministic.  That might not solve all of the
> concerns that those
> who are inclined to vote for option 2 might have in mind, but it might
> help.
> 
> So if I am a Novell employee, and I receive an S/MIME message that
> contains 
> a certificate that begins with c=US, o=Novell, I can probably make an
> excellent 
> good guess of what CA to go to, assuming that Novell operates a CA in
> its 
> own name.  But where do I go for a certificate from Acme
> Manufacturing?
> 
> I don't mean to beat up on the option 1 folks exclusively -- maybe
> there are 
> some things that could be done within the options 2 that would come
> closer to a
> compromise without breaking those existing clients.  But I need to
> think about that
> some more.  maybe someone else could volunteer some suggestions.
> 
> Bob
> 
> Robert R. Jueneman
> Novell, Inc.
> 122 E. 1700 South
> Provo, UT 84606
> [email-masked]
> 1-801-861-7387

Date: Wed, 02 Sep 1998 18:42:40 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Sender: [email-masked]

><snip>
>>I'll grant that by suggesting that NR might apply to encryption, I am
>stretching the 
>>popular concept a bit, and effectively redefining the key usage to mean
>"exclusive
>>control of the private key by the names user".  But isn't that effectively
>what we have 
>>been saying?
>>
>
>I suggest that we stick to the standardized definitions of the key usage
>bits and leave
>policy issues out of a common certificate profile.

If there were any sense of the community as to what these definitions really
mean, or ought to mean, we would probably not be having this discussion.
Otherwise I would agree with you.
>
>non-repudiation is according to standard selected by the NR bit, not NR in
>combination with DS bit. Inclusion of the DS bit means that DS mechanisms
>other than non-repudiation are allowed for the key.

I believe that is exactly the issue. Are you suggesting that NR plus DS should not
be allowed?  Why?
>
>Restrictions regarding combinations of key usages are policy issues.
>Whether a particular key usage combination is good or bad has to be decided
>through the perspective of a community with common security requirements.
>
>Non-repudiation is defined to be (according to X.509):
>  non-repudiation - This service provides proof of the integrity and 
>  origin of data - both in an unforgeable relationship - which can be 
>  verified by any third party at any time.

That particular definition is both circular and could also apply to any kind
of digital signature, and so is conspicuously unhelpful, regardless of its
origins.  It's broken, and must be fixed, whether we provide an overlay
within PKIX that further refines it, or we start the process to drive through 
a defect report.
>
>Key escrow is not defined by non-repudiation so I would not use the NR bit
>as a "no-recovery" declaration.

I guess I could agree with you, as I don't like to overload bits.  So there is yet
another reason to submit a defect report, to add a key escrow/key recovery/GAK
notification bit.
>/Stefan

Bob

Date: Wed, 02 Sep 1998 18:33:01 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: What the straw poll means
Sender: [email-masked]

This is almost as exciting as watching a horse race!

But what are we to make of the situation if the vote is as 
close as it appears to be at present -- does that truly indicate 
a "rough consensus"?

As of earlier this morning, Chromatix was ahead, with 
8 votes cast; Entrust was tied with Microsoft with 4 votes 
cast; and MISSI some others are clustered around third place.

So far, with the exception of a split between MISSI and NIST
as two US Government factions, the voting seems to be 
strictly by company.

Now, the polite fiction within the IETF is that memberships are by
individual, and that there are no "votes" per se, and certainly not 
on a company by company basis. That's the fiction, at least.. 
Whether this convention shall long endure now that the IETF has 
apparently lost some or all of its government funding and has 
to become more self-sufficient will be interesting to see.

But unless one side or the other starts to make some significant
in-roads by the dint of more persuasive technical argument, then I think
it's effectively a draw, and we may be counting companies and their 
installed base at least as much, and perhaps more, than 
balancing the technical alternatives.

Now, if we are truly at a technical impasse and the vote has to be 
binary, i.e., only one way or the other, then maybe counting installed
clients and minimizing the pain is really the way to go, but frankly 
that approach makes me uncomfortable.  I want both interoperability
AND efficiency, and I would hate to see us don't want to be 
pressured into a less than satisfactory decision, whatever that is,
 just because we are in a rush to get over the next hurdle in the 
standards progression.

I originally said that I was inclined to go with option 1, because 
it at least appeared to be simpler.  However, I also said that I was  
concerned about the "local" definition of a domain by a CA,
and the more I think about it, the more concerned I get.

That approach might be viable for an organization such as MISSI,
where everyone presumably knows what community of interest 
they fall into, but how would it apply to a public CA such as VeriSign?

Would they view all of their certificates as falling into one domain,
including any certificates issued by subordinate CAs, as in the case
of the old RSA Commercial hierarchy?

What about GTE CyberTrust, considering their presumed affinity
with their ISP business. Would all of those certificates fall into
one domain?

Now suppose I want to validate a certificate from Erols.  Do I decide that
because Erols is in the top half of the alphabet that they probably 
use GTE, whereas Xerox would probably use VeriSign?  Or do we do an 
East Coast/West Coast split, like radio and TV stations use W or K in 
their call sign?

What if Novell and Microsoft were to become CAs and issue certificates 
to their customers directly, at least their larger accounts.  Would the relying 
party have to try to divine whether a subscriber was running NetWare or
NT in order to decide what domain they would be likely to be in?

Santosh, have I misrepresented the issue here?  Feel free to correct me, if so.
Maybe I just don't understand.

Now, if the definition of "domain" were amended somewhat, perhaps some
of these difficulties might go away.

In particular, it seems to me that "domain" probably ought to have a lot to do 
with name subordination, or at least the possibility of doing name subordination, 
so that it would be deterministic.  That might not solve all of the concerns that those
who are inclined to vote for option 2 might have in mind, but it might help.

So if I am a Novell employee, and I receive an S/MIME message that contains 
a certificate that begins with c=US, o=Novell, I can probably make an excellent 
good guess of what CA to go to, assuming that Novell operates a CA in its 
own name.  But where do I go for a certificate from Acme Manufacturing?

I don't mean to beat up on the option 1 folks exclusively -- maybe there are 
some things that could be done within the options 2 that would come closer to a
compromise without breaking those existing clients.  But I need to think about that
some more.  maybe someone else could volunteer some suggestions.

Bob

Robert R. Jueneman
Novell, Inc.
122 E. 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Wed, 02 Sep 1998 19:35:39 -0400
From: bgmiller <[email-masked]>
Reply-To: [email-masked]
Organization: Jones Internet Channel
To: ietf-pkix <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 19:19:11 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01BDD6A6.90B777E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_000A_01BDD6A6.90B777E0
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>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000A_01BDD6A6.90B777E0--

From: "Maloney, Teresa A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 15:58:03 -0700 
Sender: [email-masked]

Thanks

From: John Everson <[email-masked]>
Date: Wed, 2 Sep 1998 17:52:31 -0500
Subject: For Option 2
TO: [email-masked]
Sender: [email-masked]

From: "PACHL, Jan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 16:22:19 -0500
Sender: [email-masked]

From: Charles Moore <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: for Option 1
Date: Thu, 3 Sep 1998 07:03:54 +1000 
Sender: [email-masked]

From: MA Crane <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 17:09:46 -0400
Sender: [email-masked]

From: Rick Johnson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:59:20 -0700 
Sender: [email-masked]

Date: Wed, 02 Sep 1998 16:32:03 -0400
From: Sean Mullan <[email-masked]>
Organization: Sun Microsystems
To: Sharon Boeyen <[email-masked]>
CC: [email-masked]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
Sender: [email-masked]

I agree that the forward & reverse elements of the crossCertificatePair
are useful. It would be nice if the cACertificate attribute contained
forward and reverse elements too.

One issue I have with the crossCertificatePair and the forward & 
reverse elements is that I believe they are a single-valued pair (meaning
you can't have more than one forward/reverse element per pair).
What do you do if CA1 issues more than 1 cross certificate to CA2
(or vice versa)?

--Sean
 
Sharon Boeyen wrote:
> 
> Hi Bob,
> 
> I don't think we'll every get to a point where people stop populating the
> crossCertificatePair attribute, regardless of the result of the straw poll.
> The forward/reverse elements in the syntax of this attribute are very useful
> since not all path discovery algorithms are identical. Path discovery can be
> done many ways including beginning from the subject and moving toward a
> trust anchor, beginning from a trust anchor and moving toward a subject,
> beginning at both ends etc etc.   Being able to retrieve both forward and
> reverse certificates from a single entry rather than checking the directory
> entries of two CAs is a useful feature for some algorithms.
> ------------------
> Sharon Boeyen
> Entrust Technologies
> 
> mailto:[email-masked]  Tel: (613) 247-3181
> http://www.entrust.com            Fax: (613) 247-3690
> 
> 
> > ----------
> > From:         Bob Jueneman[SMTP:[email-masked]]
> > Sent:         September 1, 1998 7:20 PM
> > To:   [email-masked]; [email-masked]; [email-masked]
> > Subject:      Re: Straw Poll cACertificate &
> > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> >
> > I'm still on the fence, and trying to decide between the two options.
> >
> > But why is a binary decision necessary?
> >
> > If I understand Tim's points, option 2 is a superset of option 1,
> > and a significant number of clients only support option 2.
> >
> > Option 1, however, is at least arguably superior from a network and
> > directory performance standpoint, although I am still very confused
> > about exactly who defines a "domain" and how the relying party is
> > supposed to intuit what "local choice" some CA made.
> >
> > Would a viable compromise position be to support option 2 as the initial
> > direction, and to transition to option 1 at some later point in time, say
> > 36 months from now, assuming further work clearly establishes that
> > option 1 is completely workable?
> >
> > My directory guys assure me that the directory is effectively neutral in
> > this,
> > except for the possible performance issues.  So all that has to happen
> > is for CAs to stop populating the crossCertificate pair. Is that correct?
> >
> > On the other hand, does this give rise to a worst of both worlds case
> > from the perspective of the client software complexity?
> >
> > Bob
> >

From: Kenneth Eggers <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 14:55:08 -0400
Sender: [email-masked]

Kenneth W. Eggers  <[email-masked]> http://www.cygnacom.com
CygnaCom Solutions, Inc.  
7927 Jones Branch Drive, Suite 100 West
McLean, VA  22102
(703) 848-0883x228  fax: (703) 848-0960                    

From: Sharon Boeyen <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 19:40:43 +0100
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 2, 1998 2:17 PM
> To: 	'Sharon Boeyen'; [email-masked]; [email-masked]; 'Bob
> Jueneman'
> Cc: 	'Stefan Santesson'
> Subject: 	RE: Straw Poll cACertificate &
> crossCertificatePairattributes- PK IX LDAPv2 schema I-D
> 
> Hi Sharon and Stefan:
> 
> While option 1 does not mandate it, it does not prohibit a CA from
> populating all the certificates it has issued to other CAs (inter as
> well as intra domain) in the reverse attribute of the cross
> certificate
> pair.
Agreed

> The fundamental difference between the two options is that under
> option
> 1 certificates are not duplicated in a CA's entry.
There are other fundamental differences as well such as requiring CAs to
split the certs to populate 2 attributes in Option 1 and requiring
clients to know the meaning of domain ahead of time in order to be able
to take any advantage of the split storage, else to require retrieval
from 2 attributes.

> > -----Original Message-----
> > From:	Sharon Boeyen [SMTP:[email-masked]]
> > Sent:	Wednesday, September 02, 1998 8:46 AM
> > To:	[email-masked]; [email-masked]; 'Bob Jueneman'
> > Subject:	RE: Straw Poll cACertificate &
> > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > 
> > Hi Bob,
> > 
> > I don't think we'll every get to a point where people stop
> populating
> > the
> > crossCertificatePair attribute, regardless of the result of the
> straw
> > poll.
> > The forward/reverse elements in the syntax of this attribute are
> very
> > useful
> > since not all path discovery algorithms are identical. Path
> discovery
> > can be
> > done many ways including beginning from the subject and moving
> toward
> > a
> > trust anchor, beginning from a trust anchor and moving toward a
> > subject,
> > beginning at both ends etc etc.   Being able to retrieve both
> forward
> > and
> > reverse certificates from a single entry rather than checking the
> > directory
> > entries of two CAs is a useful feature for some algorithms. 
> > ------------------
> > Sharon Boeyen                  
> > Entrust Technologies
> > 
> > mailto:[email-masked]  Tel: (613) 247-3181 
> > http://www.entrust.com            Fax: (613) 247-3690 
> >        
> > 
> > 
> > > ----------
> > > From: 	Bob Jueneman[SMTP:[email-masked]]
> > > Sent: 	September 1, 1998 7:20 PM
> > > To: 	[email-masked]; [email-masked]; [email-masked]
> > > Subject: 	Re: Straw Poll cACertificate &
> > > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > > 
> > > I'm still on the fence, and trying to decide between the two
> > options.
> > > 
> > > But why is a binary decision necessary?
> > > 
> > > If I understand Tim's points, option 2 is a superset of option 1, 
> > > and a significant number of clients only support option 2.
> > > 
> > > Option 1, however, is at least arguably superior from a network
> and
> > > directory performance standpoint, although I am still very
> confused 
> > > about exactly who defines a "domain" and how the relying party is
> > > supposed to intuit what "local choice" some CA made.
> > > 
> > > Would a viable compromise position be to support option 2 as the
> > initial
> > > direction, and to transition to option 1 at some later point in
> > time, say 
> > > 36 months from now, assuming further work clearly establishes that
> 
> > > option 1 is completely workable?
> > > 
> > > My directory guys assure me that the directory is effectively
> > neutral in
> > > this,
> > > except for the possible performance issues.  So all that has to
> > happen 
> > > is for CAs to stop populating the crossCertificate pair. Is that
> > correct?
> > > 
> > > On the other hand, does this give rise to a worst of both worlds
> > case
> > > from the perspective of the client software complexity?
> > > 
> > > Bob
> > > 
> 

From: Eric Rosenquist <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 14:42:00 -0400 
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_01BDD6A1.5ED91770
Content-Type: text/plain

------ =_NextPart_001_01BDD6A1.5ED91770
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.1960.3">
<TITLE>For Option 2</TITLE>
</HEAD>
<BODY>
<BR>

</BODY>
</HTML>
------ =_NextPart_001_01BDD6A1.5ED91770--

From: Santosh Chokhani <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 14:17:18 -0400
Sender: [email-masked]

Hi Sharon and Stefan:

While option 1 does not mandate it, it does not prohibit a CA from
populating all the certificates it has issued to other CAs (inter as
well as intra domain) in the reverse attribute of the cross certificate
pair.

The fundamental difference between the two options is that under option
1 certificates are not duplicated in a CA's entry.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[email-masked]]
> Sent:	Wednesday, September 02, 1998 8:46 AM
> To:	[email-masked]; [email-masked]; 'Bob Jueneman'
> Subject:	RE: Straw Poll cACertificate &
> crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> 
> Hi Bob,
> 
> I don't think we'll every get to a point where people stop populating
> the
> crossCertificatePair attribute, regardless of the result of the straw
> poll.
> The forward/reverse elements in the syntax of this attribute are very
> useful
> since not all path discovery algorithms are identical. Path discovery
> can be
> done many ways including beginning from the subject and moving toward
> a
> trust anchor, beginning from a trust anchor and moving toward a
> subject,
> beginning at both ends etc etc.   Being able to retrieve both forward
> and
> reverse certificates from a single entry rather than checking the
> directory
> entries of two CAs is a useful feature for some algorithms. 
> ------------------
> Sharon Boeyen                  
> Entrust Technologies
> 
> mailto:[email-masked]  Tel: (613) 247-3181 
> http://www.entrust.com            Fax: (613) 247-3690 
>        
> 
> 
> > ----------
> > From: 	Bob Jueneman[SMTP:[email-masked]]
> > Sent: 	September 1, 1998 7:20 PM
> > To: 	[email-masked]; [email-masked]; [email-masked]
> > Subject: 	Re: Straw Poll cACertificate &
> > crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> > 
> > I'm still on the fence, and trying to decide between the two
> options.
> > 
> > But why is a binary decision necessary?
> > 
> > If I understand Tim's points, option 2 is a superset of option 1, 
> > and a significant number of clients only support option 2.
> > 
> > Option 1, however, is at least arguably superior from a network and
> > directory performance standpoint, although I am still very confused 
> > about exactly who defines a "domain" and how the relying party is
> > supposed to intuit what "local choice" some CA made.
> > 
> > Would a viable compromise position be to support option 2 as the
> initial
> > direction, and to transition to option 1 at some later point in
> time, say 
> > 36 months from now, assuming further work clearly establishes that 
> > option 1 is completely workable?
> > 
> > My directory guys assure me that the directory is effectively
> neutral in
> > this,
> > except for the possible performance issues.  So all that has to
> happen 
> > is for CAs to stop populating the crossCertificate pair. Is that
> correct?
> > 
> > On the other hand, does this give rise to a worst of both worlds
> case
> > from the perspective of the client software complexity?
> > 
> > Bob
> > 

From: Peter Brundrett <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 11:01:16 -0700 
Sender: [email-masked]

From: Peter Yeatrakas <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:34:55 -0700 
Sender: [email-masked]

Date: Wed, 2 Sep 1998 13:20:42 -0400 (EDT)
From: Karen Oostendorp <[email-masked]>
To: [email-masked]
cc: Chris Vance <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

From: Peter Hesse <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:11:54 -0400
Sender: [email-masked]

----------------------------------------------------------------
Peter M. Hesse           [email-masked]   
CygnaCom Solutions, Inc. (703)848-0883(voice) (703)848-0960(fax)
Visit the CygnaCom Solutions Web Site:  http://www.cygnacom.com
Page me instantly! http://wwp.mirabilis.com/1942828#pager

Date: Wed, 02 Sep 1998 10:08:25 -0700
To: [email-masked]
From: Joe Tardo <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

From: Bruce Greenblatt <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:07:04 -0700 
Sender: [email-masked]

Note new phone number below |
                            v
----------------------------------------------------
Bruce Greenblatt      
[email-masked]   Personal: [email-masked]
(650) 295-7569        http://www.innetix.com/~bruceg
----------------------------------------------------

From: [email-masked]
Date: Wed, 2 Sep 1998 12:52:48 EDT
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

I vote for Option 1.

EAL

Date: Wed, 02 Sep 1998 11:10:19 -0500
From: "Dale Gustafson" <[email-masked]>
Organization: Datakey, Inc.
To: PKIX Working Group <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 11:06:52 +0000
From: susanmaloney <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Extension of straw poll
Date: Wed, 2 Sep 1998 16:40:06 +0100
Sender: [email-masked]

I've just been speaking with one of the PKIX co-chairs and as a result
of that conversation, we're extending the deadline on the straw poll
regarding the use of cACertificate and crossCertificatePair attributes
to be more in line with the length of time usually afforded straw polls
in IETF.  My reason for pushing a short timeframe was in anticipation of
a PKIX resolution which could then be submitted to the X.509 group next
week for consideration in their discussion of the related defect report.
If the straw poll ends on Wednesday, and if a PKIX resolution is
finalized quickly, we can probably still meet that timeframe. 

Votes can now be submitted up until COB on Wednesday September 9th.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

From: Ivan Milman <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 11:36:41 -0400
Sender: [email-masked]

Thanks,
Ivan

Ivan M. Milman
IBM/Austin
Distributed System Services
Email:  [email-masked]        Phone:
1-512-838-8152                                       Fax:
1-512-838-8597                      T/L:  678-8152

Date: Wed, 02 Sep 1998 11:02:48 -0400
From: Tom Horvath <[email-masked]>
Organization: Smart Link Office
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

Date: Wed, 2 Sep 1998 11:05:12 -0400
To: [email-masked]
From: David Dalkowski <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

Date: Wed, 02 Sep 1998 11:00:48 -0400
From: "Hirsch Matthew" <[email-masked]>
Organization: BAH
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: "Bill Lenz" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 10:50:09 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0081_01BDD65F.74558200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0081_01BDD65F.74558200
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.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0081_01BDD65F.74558200--

From: "Pawluk, Jean" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 07:48:14 -0700 
Sender: [email-masked]

From: Bruce Bell <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: for option 1
Date: Wed, 2 Sep 1998 07:41:24 -0700 
Sender: [email-masked]

Bruce S. Bell
Compliance Officer
phone 510-568-0276 ext.361
fax      510-568-0195

From: "Nora Kraemer" <[email-masked]>
To: <[email-masked]>
Subject: Option 1
Date: Wed, 2 Sep 1998 09:48:46 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00BE_01BDD656.E0E3D100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Nora Kraemer=20
Chromatix
10451 Twin Rivers Road, #265
Columbia, MD  21044
Phone:  301-596-8466
Fax:       410-997-4306
[email-masked]
http://www.chromatix.com

------=_NextPart_000_00BE_01BDD656.E0E3D100
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.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Nora Kraemer </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Chromatix<BR>10451 Twin Rivers Road, =

#265<BR>Columbia, MD&nbsp; 21044<BR>Phone:&nbsp;=20
301-596-8466<BR>Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
410-997-4306<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A>=
<BR><A=20
href=3D"http://www.chromatix.com">http://www.chromatix.com</A></FONT></DI=
V></BODY></HTML>

------=_NextPart_000_00BE_01BDD656.E0E3D100--

Date: Wed, 2 Sep 1998 09:47:04 -0400 (EDT)
From: Serge Mister <[email-masked]>
Reply-To: Serge Mister <[email-masked]>
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 09:38:22 -0400
From: David Berstein <[email-masked]>
Organization: Chromatix
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

--
      _/_/_/         David M. Berstein
   _/      _/
  _/                 Chromatix, Inc.
 _/           _/  _/ 10451 Twin Rivers Road, Suite 265
_/            _/_/   Columbia, MD 21044
 _/     _/   _/_/    Phone:  (301) 596-8466 | http://www.chromatix.com
  _/_/_/   _/   _/   Fax:    (410) 997-4306 | [email-masked]

Date: Wed, 2 Sep 1998 09:36:05 -0400 (EDT)
From: Chris Vance <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 08:46:34 -0400 
Sender: [email-masked]

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

From: Sharon Boeyen <[email-masked]>
To: [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 08:45:32 -0400 
Sender: [email-masked]

Hi Bob,

I don't think we'll every get to a point where people stop populating the
crossCertificatePair attribute, regardless of the result of the straw poll.
The forward/reverse elements in the syntax of this attribute are very useful
since not all path discovery algorithms are identical. Path discovery can be
done many ways including beginning from the subject and moving toward a
trust anchor, beginning from a trust anchor and moving toward a subject,
beginning at both ends etc etc.   Being able to retrieve both forward and
reverse certificates from a single entry rather than checking the directory
entries of two CAs is a useful feature for some algorithms. 
------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	September 1, 1998 7:20 PM
> To: 	[email-masked]; [email-masked]; [email-masked]
> Subject: 	Re: Straw Poll cACertificate &
> crossCertificatePairattributes- PKIX LDAPv2 schema I-D
> 
> I'm still on the fence, and trying to decide between the two options.
> 
> But why is a binary decision necessary?
> 
> If I understand Tim's points, option 2 is a superset of option 1, 
> and a significant number of clients only support option 2.
> 
> Option 1, however, is at least arguably superior from a network and
> directory performance standpoint, although I am still very confused 
> about exactly who defines a "domain" and how the relying party is
> supposed to intuit what "local choice" some CA made.
> 
> Would a viable compromise position be to support option 2 as the initial
> direction, and to transition to option 1 at some later point in time, say 
> 36 months from now, assuming further work clearly establishes that 
> option 1 is completely workable?
> 
> My directory guys assure me that the directory is effectively neutral in
> this,
> except for the possible performance issues.  So all that has to happen 
> is for CAs to stop populating the crossCertificate pair. Is that correct?
> 
> On the other hand, does this give rise to a worst of both worlds case
> from the perspective of the client software complexity?
> 
> Bob
> 

Date: Wed, 02 Sep 1998 08:37:49 -0400
To: [email-masked]
From: [email-masked] (Ella P. Gardner)
Subject: For Option 1
Sender: [email-masked]

Ella P. Gardner	               phone: +1 703 883 5826
The MITRE Corporation	         fax    +1 703 883 7142
1820 Dolley Madison Boulevard	   email: [email-masked]
McLean, VA 22102-3481

Date: Wed, 02 Sep 1998 08:34:05 -0400
From: "Saylor, John" <[email-masked]>
Subject: For Option 2
To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

\js

Date: Wed, 02 Sep 1998 08:01:58 -0400
From: John Garner <[email-masked]>
To: "IETF X.509 PKI" <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

--------------06CB147F224BAAC5EA029C20
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--

======================================================================
      //_/_/               John R. Garner
   _/      _/
  _/       _/              Chromatix, Inc.
 _/           _/  _/       10451 Twin Rivers Road, Suite 265
_/            _/_/         Columbia, MD 21044
 _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  [email-masked]

--------------06CB147F224BAAC5EA029C20
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
&nbsp;
<PRE>--&nbsp;

======================================================================
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //_/_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; John R. Garner
&nbsp;&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chromatix, Inc.&nbsp;
&nbsp;_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp; _/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10451 Twin Rivers Road, Suite 265
_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _/_/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Columbia, MD 21044
&nbsp;_/&nbsp;&nbsp;&nbsp;&nbsp; _/&nbsp;&nbsp; _/_/&nbsp; Phone:&nbsp; (301) 596-8466&nbsp; |&nbsp; <A HREF="http://www.chromatix.com">http://www.chromatix.com</A>
&nbsp; _/_/_/&nbsp;&nbsp; _/&nbsp;&nbsp; _/ Fax:&nbsp;&nbsp;&nbsp; (410) 997-4306&nbsp; |&nbsp; [email-masked]</PRE>
&nbsp;</HTML>

--------------06CB147F224BAAC5EA029C20--

Date: Wed, 02 Sep 1998 07:36:15 -0400
To: [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: for option 1
Sender: [email-masked]

From: Mark C Davis <[email-masked]>
To: <[email-masked]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 07:29:13 -0400
Sender: [email-masked]

______________________________________________________________
Mark C Davis/Raleigh/IBM, DSS Network Security, [email-masked]
(919)254-7876, pager 1(800)946-4646 PIN 6066244,  FAX (919)254-5710

Date: Wed, 02 Sep 1998 13:10:19 +0200
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[email-masked]>
Sender: [email-masked]

At 11:35 AM 9/1/98 -0600, Bob Jueneman wrote:
<snip>
>>>Equally clearly, the use of both the DS and the NR bit _is_ allowed.
>>
>>YES!! If I could, I would require the DS bit to be set anytime the NR was
set.
>
>I'm not strongly opposed to that, and in fact that was my position prior
to realizing 
>that NR plus encryption could be used to indicate that no escrow was
taking place.
>If the DS bit would always be set, as opposed to using NR by itself, it
would be
>a few nanoseconds faster.

<snip>
>I'll grant that by suggesting that NR might apply to encryption, I am
stretching the 
>popular concept a bit, and effectively redefining the key usage to mean
"exclusive
>control of the private key by the names user".  But isn't that effectively
what we have 
>been saying?

I suggest that we stick to the standardized definitions of the key usage
bits and leave
policy issues out of a common certificate profile.

non-repudiation is according to standard selected by the NR bit, not NR in
combination with DS bit. Inclusion of the DS bit means that DS mechanisms
other than non-repudiation are allowed for the key.

Restrictions regarding combinations of key usages are policy issues.
Whether a particular key usage combination is good or bad has to be decided
through the perspective of a community with common security requirements.

Non-repudiation is defined to be (according to X.509):
  non-repudiation - This service provides proof of the integrity and 
  origin of data - both in an unforgeable relationship - which can be 
  verified by any third party at any time.

Key escrow is not defined by non-repudiation so I would not use the NR bit
as a "no-recovery" declaration.

/Stefan

From: [email-masked]
To: [email-masked]
Date: Wed, 2 Sep 1998 07:01:37 -0400
Subject: For Option 2
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [email-masked]
Precedence: bulk

Date: Wed, 02 Sep 1998 06:51:36 -0400
From: Jesse Walker <[email-masked]>
Organization: Shiva Corporation
To: [email-masked]
Subject: For option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 12:08:11 +0200
To: Santosh Chokhani <[email-masked]>, Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[email-masked]>
Sender: [email-masked]

I just feel uncomfortable with a situation where the CA is NOT allowed
to store some of it's issued CA certificates in its directory (OPTION 1).

If nothing less, storage of these certificates may be used for cashing
to enhance path construction (less directory look ups in new paths).

Since OPTION2 closes less doors and obviously supports a wider range
of local path algorithms, OPTION 2 seems to be the natural choice.

I agree with Carlislie and Tim that since OPTION 1 only is a subset of 
OPTION 2 and OPTION 2 offer full interoperability, that OPTION 2 should 
be selected even if only a minority declare a need for it. 

/Stefan

At 05:56 PM 9/1/98 -0400, Santosh Chokhani wrote:
>They are stored in caCertificate attribute of directory entry
>representing the subject (subscriber) CA.
>
>> -----Original Message-----
>> From:	Stefan Santesson [SMTP:[email-masked]]
>> Sent:	Tuesday, September 01, 1998 3:54 PM
>> To:	Sharon Boeyen; [email-masked]'
>> Cc:	'Santosh Chokhani'
>> Subject:	Re: Straw Poll cACertificate & crossCertificatePair
>> attributes - PKIX LDAPv2 schema I-D
>> 
>> I don't get this.
>> 
>> In OPTION 1, where do I store certificates issued by this CA to CA:s 
>> in the same domain????
>> 
>> It seems to be missing.
>> 
>> /Stefan
>> 
>> 

Date: Wed, 02 Sep 1998 12:08:12 +0200
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 10:39:52 +0200
To: [email-masked]
From: Martin =?iso-8859-1?Q?Lindström?= <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

 ______________________________________
|________ Entegrity Solutions _________|
|                                      |
| Martin Lindström, Systems Engineer   |
|                                      |                                    
| Finlandsgatan 60                     |
| S-164 74 Kista, Sweden               |
| Direct: +46-(0)8-477-7735            |
| Fax:    +46-(0)8-477-7731            |
| Cell:   +46-(0)70-483-0024           |
|______________________________________|

Date: Wed, 02 Sep 1998 10:19:46 +0200
To: [email-masked]
From: Thomas Caldenius <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

From: "Andrey Lopatenko" <[email-masked]>
To: <[email-masked]>
Subject: Option 2
Date: Wed, 2 Sep 1998 12:22:54 +0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0052_01BDD66C.68EE6D70
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0052_01BDD66C.68EE6D70
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Dkoi8-r http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0052_01BDD66C.68EE6D70--

Date: Wed, 02 Sep 1998 10:14:29 +0200
To: [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: For Option 2
Sender: [email-masked]

Date: Wed, 02 Sep 1998 09:38:55 +0400 (MSK DST)
From: Pavel Krylov <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: [email-masked]
Date: Tue, 1 Sep 1998 21:14:44 -0700
To: [email-masked]
Subject: option 2
Sender: [email-masked]

From: "Yuriy Dzambasow" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 22:44:42 -0400
Importance: Normal
Sender: [email-masked]

Date: Tue, 01 Sep 1998 17:20:10 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX LDAPv2 schema I-D
Sender: [email-masked]

I'm still on the fence, and trying to decide between the two options.

But why is a binary decision necessary?

If I understand Tim's points, option 2 is a superset of option 1, 
and a significant number of clients only support option 2.

Option 1, however, is at least arguably superior from a network and
directory performance standpoint, although I am still very confused 
about exactly who defines a "domain" and how the relying party is
supposed to intuit what "local choice" some CA made.

Would a viable compromise position be to support option 2 as the initial
direction, and to transition to option 1 at some later point in time, say 
36 months from now, assuming further work clearly establishes that 
option 1 is completely workable?

My directory guys assure me that the directory is effectively neutral in this,
except for the possible performance issues.  So all that has to happen 
is for CAs to stop populating the crossCertificate pair. Is that correct?

On the other hand, does this give rise to a worst of both worlds case
from the perspective of the client software complexity?

Bob

Date: Tue, 01 Sep 1998 09:01:49 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: For  Option 2
Sender: [email-masked]

--Paul Hoffman, Director
--Internet Mail Consortium

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:02:05 -0700 
Sender: [email-masked]

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 18:00:13 -0400
Sender: [email-masked]

For option 1

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
[email-masked]
http://www.cygnacom.com

From: [email-masked] (Mike Just)
Date: Tue, 1 Sep 1998 17:59:54 -0400
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

From: Santosh Chokhani <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Santosh Chokhani'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 17:56:27 -0400
Sender: [email-masked]

They are stored in caCertificate attribute of directory entry
representing the subject (subscriber) CA.

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[email-masked]]
> Sent:	Tuesday, September 01, 1998 3:54 PM
> To:	Sharon Boeyen; [email-masked]'
> Cc:	'Santosh Chokhani'
> Subject:	Re: Straw Poll cACertificate & crossCertificatePair
> attributes - PKIX LDAPv2 schema I-D
> 
> I don't get this.
> 
> In OPTION 1, where do I store certificates issued by this CA to CA:s 
> in the same domain????
> 
> It seems to be missing.
> 
> /Stefan
> 
> 
> At 11:10 AM 9/1/98 -0400, Sharon Boeyen wrote:
> >
> >Folks 
> >
> >This is a straw poll on the use of the cACertificate and
> >crossCertificatePair attributes in the PKIX LDAP schema draft. There
> are 2
> >options, each of which received sufficient support during the Chicago
> >meeting to require this straw poll to resolve the issue. Below is the
> >specific text proposed for each option, followed by a summary of the
> >rationale behind each of the proposals. The specific text for the
> proposals
> >and rationale summaries have been cooperatively drafted by Santosh
> Chokhani,
> >Dave Horvath and myself.
> >
> >Votes must be in by COB on Thursday Sept 3.  This is the only
> outstanding
> >issue on this I-D following the 2 week last call so we should be able
> to
> >progress both the PKIX LDAPv2 protocol profile and PKIX LDAPv2 schema
> >following this poll.
> >. 
> >To vote, send an email to [email-masked] with one of the following
> >subject lines: 
> >
> >To vote for option 1put "For Option 1" in the subject line. 
> >To vote for option 2 put "For Option 2" in the subject line.	 
> >
> >As with the earlier polls conducted by Tim Polk on Part 1, don't
> bother with
> >a message body, I am just going to count the messages.  Discussion of
> the
> >content of this message should reply to this message.
> >
> >
> >PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
> >OPTION 1:
> >----------------
> >The cACertificate attribute, held in a particular CA's directory
> entry,
> >shall be used to store certificates issued to this CA by CAs in the
> same
> >domain as this CA. In addition, the cACertificate attribute shall be
> used to
> >store self-issued certificates.
> >
> >The forward element of the crossCertificatePair attribute, held in a
> >particular CA's directory entry, shall be used to store certificates
> issued
> >to this CA by CAs in other domains.  Optionally, the reverse element
> of the
> >crossCertificatePair attribute, held in a particular CA's directory
> entry,
> >may contain certificates issued by this CA to CAs in other domains.
> >
> >In the case of V3 certificates, none of the above CA certificates may
> >include a basicConstraints extension with the cA value set to FALSE.
> >
> >The definition of domain is purely a matter of local policy.
> >
> >OPTION 2:
> >-------------
> >The crossCertificatePair attribute, held in a particular CA's
> directory
> >entry, shall be used to store all certificates issued by this CA to
> other
> >CAs, as well as certificates issued for this CA by other CAs. Values
> held in
> >the forward element are certificates issued for this CA by other CAs,
> while
> >values in the reverse element are certificates issued by this CA for
> other
> >CAs. 
> >
> >The cACertificate attribute, held in a particular CA's directory
> entry,
> >shall be used to store certificates issued to this CA by CAs in the
> same
> >domain as this CA. This set of certificates is a subset of the values
> of the
> >forward element of the crossCertificatePair attribute in the same CA
> entry.
> >In addition, the cACertificate attribute shall beused to store
> self-issued
> >certificates.  
> >
> >The definition of domain is purely a matter of local policy.
> >
> >In the case of version 3 certificates, none of the above CA
> certificates may
> >include a basicConstraints extension with the cA value set to FALSE.
> >
> >SUMMARY OF RATIONALE FOR EACH OF THE OPTIONS:
> >--------------------------------------------------------------------
> >
> >RATIONALE FOR PROPOSING OPTION 1:
> >--------------------------------------------------
> >The major advantage of this approach is that it minimizes the amount
> of data
> >retrieved from the directory.  The approach improves the relying
> party
> >response time and minimizes network utilization.
> >
> >Another advantage of this approach over the alternative is that it
> does not
> >require the relying parties to separate the certificates stored in
> >caCertificate attribute from those stored in the crossCertificatePair
> >attribute.  The clients may need to do this during path construction.
> >
> >Storing all the certificates in the crossCertificatePair attribute
> and also
> >storing some of the certificates in the caCertificate attribute, as
> >described in the alternative, unnecessarily increases the number of
> >certificates retrieved.  The alternative will result in poorer
> relying party
> >response time and use network bandwidth unnecessarily.  The
> alternative will
> >be particularly inefficient when a relying party is located remotely
> from
> >the repository/directory.
> >
> >A minor disadvantage of the alternative is that it requires the same
> >information object (certificate) to be stored twice in a repository,
> once in
> >the caCertificate attribute and once in the crossCertificatePair
> attribute.
> >This increases he storage requirement on the directory.
> >
> >
> >RATIONALE FOR PROPOSING OPTION 2:
> >------------------------------------------------------------
> >
> >Path development is a relying party process and the criteria for
> selection
> >of a 'preferred' set of certificates to enable efficiencies in that
> process
> >can vary according to the path discovery algorithm as well as from
> one
> >relying party to another, from one application to another, and on
> other
> >criteria as well. While a CA should optionally be able to provide
> helpful
> >hints to relying parties regarding the set of certificates the CA
> expects to
> >provide efficiencies, these may or may not match the requirements of
> a
> >relying party path discovery process. Relying parties will access CA
> >directory entries frequently to retrieve certificates as input to a
> >certification path development process and they should not be forced
> to know
> >whether or not a CA has published a set of  its 'preferred'
> certificates,
> >nor should relying parties be required to take on the extra burden of
> having
> >to request filtering of multiple directory attributes to retrieve the
> set of
> >certificates which is preferred in their particular environment,
> especially
> >given that relying parties will often need this information from CAs
> outside
> >their own local Intranet. 
> >
> >CAs should be given the option to publish a set of 'preferred'
> certificates
> >but should not be required to do so. Should a CA elect to publish
> such a
> >set, the criteria used by that CA to determine the bases of the
> preference
> >should be left to the discretion of each CA or each security domain.
> The
> >preference should not be necessarily tied to a predetermined
> universal
> >criterion such as a single PKI or 'internal domain', especially given
> that a
> >CA may be issued a certificate by any number of other CAs and may
> therefore
> >subscribe to many PKIs.
> >
> >
> >------------------
> >Sharon Boeyen                  
> >Entrust Technologies
> >
> >mailto:[email-masked]  Tel: (613) 247-3181 
> >http://www.entrust.com            Fax: (613) 247-3690 
> >       
> >
> >
> >

Date: Tue, 01 Sep 1998 14:50:18 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 01 Sep 1998 17:41:41 -0400
From: Sean Mullan <[email-masked]>
Organization: Sun Microsystems
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 01 Sep 1998 18:32:48 -0300
From: Eduardo Rosemberg de Moura <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 2
Sender: [email-masked]

-- 
Eduardo Rosemberg de Moura
mailto:[email-masked] ([email-masked])
Phone: +55 21 521-0120 (voice)
       +55 21 523-4499 (fax)
Mobile:+55 21 9985-7934
ICQ:   6365858

From: Brian LaMacchia <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:21:30 -0700 
Sender: [email-masked]

From: "Adkins, Sherrill" <[email-masked]>
To: [email-masked]
Subject: For Option 1
Date: Tue, 1 Sep 1998 20:55:47 -0000 
Importance: low
Sender: [email-masked]

From: Barb Fox <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: for Option 1
Date: Tue, 1 Sep 1998 13:54:51 -0700 
Sender: [email-masked]

Date: Tue, 01 Sep 1998 16:53:40 -0400
From: Greg Byrd <[email-masked]>
Organization: SECANT Network Technologies
To: [email-masked]
Subject: for option 2
Sender: [email-masked]

-- 
Greg Byrd                          [email-masked]
SECANT Network Technologies, Inc.  919-462-1900 x229
P.O. Box 14285                     919-462-1933 (fax)
Research Triangle Park, NC 27709

Date: Tue, 01 Sep 1998 14:31:19 -0600
From: "Russel F. Weiser" <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------C201775B051242826227D678
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------C201775B051242826227D678
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Russel Weiser
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Russel Weiser
n:              Weiser;Russel
org:            DST
email;internet: [email-masked]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------C201775B051242826227D678--

Date: Tue, 01 Sep 1998 21:53:35 +0200
To: Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[email-masked]>
Sender: [email-masked]

I don't get this.

In OPTION 1, where do I store certificates issued by this CA to CA:s 
in the same domain????

It seems to be missing.

/Stefan

At 11:10 AM 9/1/98 -0400, Sharon Boeyen wrote:
>
>Folks 
>
>This is a straw poll on the use of the cACertificate and
>crossCertificatePair attributes in the PKIX LDAP schema draft. There are 2
>options, each of which received sufficient support during the Chicago
>meeting to require this straw poll to resolve the issue. Below is the
>specific text proposed for each option, followed by a summary of the
>rationale behind each of the proposals. The specific text for the proposals
>and rationale summaries have been cooperatively drafted by Santosh Chokhani,
>Dave Horvath and myself.
>
>Votes must be in by COB on Thursday Sept 3.  This is the only outstanding
>issue on this I-D following the 2 week last call so we should be able to
>progress both the PKIX LDAPv2 protocol profile and PKIX LDAPv2 schema
>following this poll.
>. 
>To vote, send an email to [email-masked] with one of the following
>subject lines: 
>
>To vote for option 1put "For Option 1" in the subject line. 
>To vote for option 2 put "For Option 2" in the subject line.	 
>
>As with the earlier polls conducted by Tim Polk on Part 1, don't bother with
>a message body, I am just going to count the messages.  Discussion of the
>content of this message should reply to this message.
>
>
>PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
>OPTION 1:
>----------------
>The cACertificate attribute, held in a particular CA's directory entry,
>shall be used to store certificates issued to this CA by CAs in the same
>domain as this CA. In addition, the cACertificate attribute shall be used to
>store self-issued certificates.
>
>The forward element of the crossCertificatePair attribute, held in a
>particular CA's directory entry, shall be used to store certificates issued
>to this CA by CAs in other domains.  Optionally, the reverse element of the
>crossCertificatePair attribute, held in a particular CA's directory entry,
>may contain certificates issued by this CA to CAs in other domains.
>
>In the case of V3 certificates, none of the above CA certificates may
>include a basicConstraints extension with the cA value set to FALSE.
>
>The definition of domain is purely a matter of local policy.
>
>OPTION 2:
>-------------
>The crossCertificatePair attribute, held in a particular CA's directory
>entry, shall be used to store all certificates issued by this CA to other
>CAs, as well as certificates issued for this CA by other CAs. Values held in
>the forward element are certificates issued for this CA by other CAs, while
>values in the reverse element are certificates issued by this CA for other
>CAs. 
>
>The cACertificate attribute, held in a particular CA's directory entry,
>shall be used to store certificates issued to this CA by CAs in the same
>domain as this CA. This set of certificates is a subset of the values of the
>forward element of the crossCertificatePair attribute in the same CA entry.
>In addition, the cACertificate attribute shall beused to store self-issued
>certificates.  
>
>The definition of domain is purely a matter of local policy.
>
>In the case of version 3 certificates, none of the above CA certificates may
>include a basicConstraints extension with the cA value set to FALSE.
>
>SUMMARY OF RATIONALE FOR EACH OF THE OPTIONS:
>--------------------------------------------------------------------
>
>RATIONALE FOR PROPOSING OPTION 1:
>--------------------------------------------------
>The major advantage of this approach is that it minimizes the amount of data
>retrieved from the directory.  The approach improves the relying party
>response time and minimizes network utilization.
>
>Another advantage of this approach over the alternative is that it does not
>require the relying parties to separate the certificates stored in
>caCertificate attribute from those stored in the crossCertificatePair
>attribute.  The clients may need to do this during path construction.
>
>Storing all the certificates in the crossCertificatePair attribute and also
>storing some of the certificates in the caCertificate attribute, as
>described in the alternative, unnecessarily increases the number of
>certificates retrieved.  The alternative will result in poorer relying party
>response time and use network bandwidth unnecessarily.  The alternative will
>be particularly inefficient when a relying party is located remotely from
>the repository/directory.
>
>A minor disadvantage of the alternative is that it requires the same
>information object (certificate) to be stored twice in a repository, once in
>the caCertificate attribute and once in the crossCertificatePair attribute.
>This increases he storage requirement on the directory.
>
>
>RATIONALE FOR PROPOSING OPTION 2:
>------------------------------------------------------------
>
>Path development is a relying party process and the criteria for selection
>of a 'preferred' set of certificates to enable efficiencies in that process
>can vary according to the path discovery algorithm as well as from one
>relying party to another, from one application to another, and on other
>criteria as well. While a CA should optionally be able to provide helpful
>hints to relying parties regarding the set of certificates the CA expects to
>provide efficiencies, these may or may not match the requirements of a
>relying party path discovery process. Relying parties will access CA
>directory entries frequently to retrieve certificates as input to a
>certification path development process and they should not be forced to know
>whether or not a CA has published a set of  its 'preferred' certificates,
>nor should relying parties be required to take on the extra burden of having
>to request filtering of multiple directory attributes to retrieve the set of
>certificates which is preferred in their particular environment, especially
>given that relying parties will often need this information from CAs outside
>their own local Intranet. 
>
>CAs should be given the option to publish a set of 'preferred' certificates
>but should not be required to do so. Should a CA elect to publish such a
>set, the criteria used by that CA to determine the bases of the preference
>should be left to the discretion of each CA or each security domain. The
>preference should not be necessarily tied to a predetermined universal
>criterion such as a single PKI or 'internal domain', especially given that a
>CA may be issued a certificate by any number of other CAs and may therefore
>subscribe to many PKIs.
>
>
>------------------
>Sharon Boeyen                  
>Entrust Technologies
>
>mailto:[email-masked]  Tel: (613) 247-3181 
>http://www.entrust.com            Fax: (613) 247-3690 
>       
>
>
>

From: "Fabio Omenigrandi" <[email-masked]>
To: [email-masked]
Date: Tue, 1 Sep 1998 21:32:35 +0200
Subject: For Option 1
Sender: [email-masked]

From: Ron Chittaro <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:35:44 -0400 
Sender: [email-masked]

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Tim Polk'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 15:06:36 -0400 
Sender: [email-masked]

Hi,

Here's my two cents (which, at the current exchange rate, is worth
considerably less than Tim's two cents...).

> ----------
> From: 	Tim Polk[SMTP:[email-masked]]
> Sent: 	Tuesday, September 01, 1998 1:39 PM
> To: 	[email-masked]'
> Subject: 	Re: Straw Poll cACertificate & crossCertificatePair
> attributes - PKIX LDAPv2 schema I-D
> 
> In case anyone is interested, here's my two cents worth...
> 
...

> I prefer option #2, but for rather pragmatic reasons.  There are two large
> pools of PKI clients.  These two groups were designed independently, and
> the implementers made different assumptions.  If we choose option #1, we
> break one group of clients. HOWEVER, if we choose option #2, both sets of
> clients will work - and will be interoperable!
> 
> Since a technically viable solution exists that doesn't break any existing
> clients and actually makes them interoperable, that is my preference.
> 
This sort of reasoning (*especially* within the IETF community) seems
sufficiently strong that I wonder why in the world we need a straw poll at
all.  It meets every conceivable definition of "rough consensus and running
code" and "interoperability above non-interoperability", which are the two
golden rules of this community.  Within an *IETF* Working Group, is there
any defensible basis for choosing another option that does not have these
properties?

Carlisle.

P.S., Bob, I share your concern for the definition of a domain being left up
to "local policy".  What exactly is the definition of "local"?  Does this
mean local to the CA whose entry we're considering?  If so, then if I am
certified by another CA, how do I know whether or not I'm in that first CA's
"domain" (i.e., how do I know what it "locally" defined its domain to be)?
Therefore, how do I know whether or not to look in the caCertificate
attribute?

Again, it seems to me that option 2 nicely (and completely) solves this
problem:  if I somehow (magically) know that I'm in that CA's domain, then I
can retrieve certificates from the caCertificate attribute; otherwise, I can
retrieve certificates from the crossCertificatePair attribute.  Both methods
are guaranteed to work.  Option 1, on the other hand, works on the
underlying assumption that everybody knows (a priori) what domain they're
in.  Given that there is no universal definition for "domain" (i.e., that it
is only defined "locally"), it is not at all obvious how to ensure this.

From: Carlisle Adams <[email-masked]>
To: [email-masked]
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:07:25 -0400 
Sender: [email-masked]

Date: Tue, 01 Sep 1998 15:07:07 -0400
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Sender: [email-masked]

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 

From: MHenry <[email-masked]>
To: [email-masked]
Subject: for option 2
Date: Tue, 1 Sep 1998 15:05:25 -0400 
Sender: [email-masked]

From: "Fillingham,  David W." <[email-masked]>
To: "'IETF/PKIX'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:01:50 -0400
Sender: [email-masked]

Reply-To: [email-masked]
To: [email-masked]
Subject: For Option 2
From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Sep 1998 19:52:09 +0100
Sender: [email-masked]

Date: Tue, 01 Sep 1998 14:43:28 -0400
From: Michael Maloney <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------10B5479D1700C8A1FFAC998E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------10B5479D1700C8A1FFAC998E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Mike Maloney
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Mike Maloney
n:              Maloney;Mike
org:            Chromatix, Inc
adr:            10451 Twin Rivers Road;;Suite 265;Columbia;MD;21044;USA
email;internet: [email-masked]
title:          Senior Engineer
tel;work:       301 596-8466
tel;fax:        410 997-4306
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------10B5479D1700C8A1FFAC998E--

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 14:33:05 -0400 
Sender: [email-masked]

From: "Rogers III, Edward B." <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:26:56 -0400 
Importance: low
Sender: [email-masked]

R/ Ed
Technical Lead, DMS Security Evolution
Lockheed Martin Federal Systems

From: "Steven (Pete) Peterson" <[email-masked]>
To: <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:12:22 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_017F_01BDD5B2.89B86520
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_017F_01BDD5B2.89B86520
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.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_017F_01BDD5B2.89B86520--

Date: Tue, 01 Sep 1998 14:12:56 -0400
From: Thomas Llanso <[email-masked]>
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

--

      _/_/_/                   Thomas H. Llanso
   _/      _/
  _/       _/                  Chromatix, Inc.
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/      Phone:  (301) 596-8466  |
http://www.chromatix.com
 _/_/_/   _/   _/      Fax:    (410) 997-4306  |
[email-masked]

Date: Tue, 01 Sep 1998 14:06:38 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Larry Layten <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 12:58:05 -0500
Sender: [email-masked]

Date: Tue, 01 Sep 1998 11:51:01 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes- PKIX LDAPv2 schema I-D
Sender: [email-masked]

I am inclined to support option 1, because it seems simpler..

However, I am concerned that the definition of the domain is left up to local
policy.

If "domain " referred to the chain of certificates that could be validated by 
climbing the subject to issuer chain within the certificates, I think it would
be much cleaner.

As it stands, I'm not quite sure that I understand how to construct a path search
algorithm in either of the two proposals, so I guess I need to stare at it harder.

I understand Tim's pragmatic argument, but I'm not convinced that the number of 
applications actually using LDAP to retrieve certificates is so large that this is an
overwhelming reason to go one way or the other.  In absolute numbers, what 
are we talking about?

Bob

>>> Tim Polk <[email-masked]> 09/01 11:39 AM >>>

In case anyone is interested, here's my two cents worth...

The LDAP straw poll message concentrates on the technical rationale behind
each of the two options.  In fact, each is a technically sound proposal.
Option #1 is more elegant since there is no redundant data.  Option #2 is a
little more flexible, but clients may incur a performance hit when building
infrequently used paths.  IMHO, it's a wash.

I prefer option #2, but for rather pragmatic reasons.  There are two large
pools of PKI clients.  These two groups were designed independently, and
the implementers made different assumptions.  If we choose option #1, we
break one group of clients. HOWEVER, if we choose option #2, both sets of
clients will work - and will be interoperable!

Since a technically viable solution exists that doesn't break any existing
clients and actually makes them interoperable, that is my preference.

Date: Tue, 1 Sep 1998 13:51:23 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: For Option 1
Sender: [email-masked]

Date: Tue, 01 Sep 1998 11:35:15 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Digital signature and non-repudiation key usage bits
Sender: [email-masked]

Hi, Aram,

I'll try to respond to some of your points to clarify what I meant, 
although in some cases I suspect we may agree to disagree.

>>I believe that we can agree on at least two things:

Maybe not!
>>
>>1.  The Digital Signature key usage is an important indicator in those 
>>environments where key strength may be limited and/or key escrow
>>required, _except_ for keys whose usage can be proven to be restricted
>>to benign applications, e.g., digital signatures.  (Actually proving that
>>to the satisfaction of the export/import/use authorities isn't all that easy,
>>especially in a general-purpose API environment, but the PKIX group
>>doesn't need to concern themselves with those kinds of details.)
>
>I do not think that key usage should be tied to any key strength and/or key
>escrow requirements. There are many valid *security* reasons to limit how a key
>is used.

I certainly agree with your second sentence, and am not trying to tie key usage to
key strength and/or key escrow requirements.

But for those of us who are delivering software to international markets, notably 
including France, Russia, Singapore, and some other countries, key escrow is 
a fact of life that is quite independent of what you or I, or for that matter what the
US Government thinks of it.

It's true that the originator is primarily concerned with the _private_ key, not the 
public key or the certificate.  But I  disagree with whoever suggested that the 
application would have to parse the certificate to understand the key usage 
restriction.  It is much more likely that the key pair is typed once and for all at the 
time of its creation, and that the application or operating system therefore knows 
the kinds of operation that the key can be used for from the type that is bound to it,
and has to enforce those limitations on the key usage. Including the key usage 
in the certificate is therefore merely reflecting the already existing restrictions on 
the private key, so that someone won't try to use the public key in the certificate 
for encryption, since the recipient wouldn't be able to read it.

(Note that by saying this I don't mean to imply that there are other perfectly valid reasons
why the owner of the DS key doesn't want it used for encryption as well.  So I'm not
limiting the use of the DS bit to this purpose exclusively.)
>
>>
>>2.  There is a strong desire to have the Non-Repudiation bit serve as
>>an indication of a conscious, volitional act that may have significant 
>>legal consequences.
>
>Does this mean that unless there is *always* "a conscious, volitional act"
>Non-Repudiation can never occur?

Well, from a legal standpoint as I understand it, non-repudiation is an oxymoron, 
since a contract or other apparent agreement can always be repudiated by 
showing that compulsion or force was used, that the signer was not mentally
and legally competent (of sufficient age, etc.)  I'm not an attorney, and I'm not going
to try to summarize a year's worth of contract law in a sentence or two, but it is 
my understanding that the essential elements of a contract are a true meeting of the
minds of the two (or more) parties, plus "consideration," normally an exchange 
of money for goods.

I believe that there is some concern in legal circles that someone who was not 
necessarily skilled in the software arts might not recognize when a digital signature
was being applied, and hence could claims that they were uninformed or worse 
yet, duped or tricked into signing away Grandma's house.

So I'm not going to say "always," especially with a double negative like 
"non-repudiation can never occur".  A conscious, volitional act might still be 
overturned for some other reason, and the absence of a conscious, 
volitional act might still be upheld as legal binding, especially if it can be 
shown that the alleged signer knew, or ought to have known, the likely
consequences of their actions.  You or I, in other words, are probably going
to have a more difficult time trying to wriggle out of a contract than Grandma might.

(Since I'm married to a "Grandma," I guess I ought to make it clear that I am
using that term in an affectionate, rather than pejorative sense! :-)

Now it's true that there might be other implications associated with the NR usage.
Some have suggested that when it is asserted, the CA is assuming an obligation 
to maintain all of the records necessary to confirm the absence of any revocation,
more or less in perpetuity.  I doubt that makes much business sense -- in perpetuity
is a very long time, and I suspect that the amount charged for the certificate isn't
enough to pay for maintaining those records forever, but if some CA wants to 
commit to that for its NR certificates I won't object.

Personally, I would like to see the NR bit used to inform the relying party that this 
certificate is rather special, and that any document that is signed and verified 
with it is likely to be important, and hence the relying party would probably be 
well advised to collect all of the certificates, perhaps have them notarized or 
timestamped, and archive them along with the document.  That's what I would 
do for any important document that I received that was associated with a NR usage,
but I'm not going to lobby too hard for that interpretation either.

Again, just to make it clear, I am  addressing the key usage which is primarily
associated with the private key, and is _reflected_ in the public key usage.

>
>>
>>(Although there might be some benefit to having defining an "authentication 
>>service" that would be distinct from the nonrepudiation service, there wasn't 
>>much support for that, especially if it would mean trying to push a defect 
>>report through X.509.  So I've given up on that thrust.)
>
>I'd be glad to support pushing a defect report. They never should have
>overloaded the key usage extension. They have overloaded the extension with 1)
>usage of the key, 2) services the key may provide, and 3) limiting what the key
>may signed.

In the immortal words of Walt Kelley, the originator of the finest comic strip ever
created ("Pogo"), "We have met the enemy, and they is us."  I'm afraid we are
all somewhat guilty in this particular area -- it looked reasonable at the time.

I'm not sure how feasible it is to try to overturn the apple cart at this late date, but 
maybe better late than later still.  You lead, and I'll follow.
>
>>
>>So let's think about what the implications of the NR bit ought to be.
>>
>>For one thing, as some people on the legal side of the house have argued,
>>in order to forestall the "Grandma hits the wrong button and loses her house"
>>argument against PKI and digital signatures in general, we need to require
>>a "gravity charge" be provided in the software in this case.  It should say something 
>>like: "Warning. You are about to sign something using a Non-Repudiation 
>>key, which may give rise to legal consequences for which you may be 
>>held personally and uniquely liable or responsible. Do you want to continue?"
>
>As someone else already pointed out, this assumes that the application can parse
>the certificate. Also, it assumes the the underlying crypto API takes the
>certificate to do the sign operation and not the private key.

No, as I said earlier, I am assuming that the key is strongly typed at the time of 
its creation. If the usage by the originator depended only on the certificate, 
then the issue of having two certificates for the same key could arise.
>
>>
>>In addition to the gravity charge, it would certainly be desirable to have 
>>an additional level of password or even biometric controls that are applied in 
>>order to unlock the NR key.  This not only underscores the serious, ceremonial 
>>aspect of a legally binding signature, it helps to assure that that user and that user 
>>only has access to that key.
>>
>>(I'm using the term "NR key" to avoid the awkward phrase, "the private 
>>key that is logically associated with the public key which is included in a 
>>certificate which has a Non Repudiation keyUsage parameter specified."  
>>Besides, although some applications and/or APIs may not associate 
>>the corresponding public key attributes with the private key, I 
>>believe that most applications will in fact do so.)
>>
>>Since the absolute quintessence of non-repudiation in the technical sense is that
>>only the authorized holder of the corresponding private key could have possibly
>>signed the document which is validated by the NR certificate, it is essential that 
>>access to that key be uniquely restricted to that user.
>>
>>At the risk of being obvious, that means that:
>>
>>1.  It must be computationally infeasible in the strictest sense for any other person 
>>than the authorized user to computer or re-derive the private key. that includes the 
>>software vendor, the user's MIS department, the various export/import authorities,
>>etc.
>>
>>2.  Likewise, it means that all possible precautions must be taken against 
>>the possibility
>>that even the authorized user could, accidentally or deliberately, disclose 
>>or give away 
>>knowledge of or access to so much as a single bit of the private key, or of 
>>the entropy 
>>from which it was derived.
>>
>>3. And again, it must not be possible for even the user's supervisor or MIS department 
>>to replace the user's private key with another private key that matches a certificate 
>>containing the user's identity information or rights access.  (The CA may 
>>be able to issue
>>a certificate corresponding to a bogus private key, but the network 
>>administrator, directory
>>administrator, etc., must not be able to do so, or to cause it to happen.)
>
>Don't these 3 items apply to digital signatures when used for authentication?
>While digital signatures provide integrity, you usually want more than integrity
>(otherwise why use digital signatures?). Thus, if my supervisor can replace my
>private key, then he can impersonate me.

You of course have a point.  However, in most of the authentication examples I
am familiar with, the user is authenticating his access to resources that are controlled
by the company he works for (e.g., printer, a server, or a database), and those 
access rights are typically controlled by the much the same people that issue 
e-mail accounts, grant directory access, etc.  

I'm willing to think about this some more, but I view the use of digital signatures to 
control access to information and/or other resources as being primarily a usage 
issue, and secondarily a privacy issue.

For example, take an on-line personnel database.  The company might very well 
require the use of a digital signature, e.g., SSL client authentication, to control access 
to who can read my 401K earnings. I would certainly be upset if my supervisor 
could access that information, but it wouldn't be the end of the world, since he already 
knows and controls how much I make, etc.

What I do want to make very sure, however, is that he can't go into my file and for 
example cash me out, or change the beneficiary of my insurance policies -- such actions
have significant legal consequences that go far beyond privacy, and ought to require
non-repudiation.

So I don't think there would be any disagreement with point 1 -- digital signature keys
should never be escrowed.  Even the feds don't want that for it would make it too 
easy for someone to claim that they were set up.

Point 2 is particularly difficult to implement, but is intended to prevent the situation where
someone allows their spouse to have access to their private key (password) for home 
banking, but without that person' knowledge, or even after death, uses that key to
forge a codicil to their will, etc.  So I'd live to come right out and require the use
of biometrics for all non-repudiation, but as yet is isn't quite feasible.

Point 3 address the case we were talking about earlier, in particular where the user's key
may be stored in the directory or other central location where the system administrator
could conceivably change the user's password and access the key somehow.

Although I can imagine that a number of people who would say that this is just flat out 
a terrible idea and should never be done, the benefits of being able to access a single 
sign-on key from whatever terminal or workstation you are using are considerable.
Schools, for example, can usually not afford to dedicate a particular terminal to a single 
student, and the same is true for operational control centers that operate on a 7x24 
hour basis.  Storing keys in smart cards, is one approach, but if you forget or lose 
your card you may be locked out. Password encrypted floppy disks are another 
possibility, but still awkward.  So I'm not willing to rule out these kinds of systems in 
general. I just want to make sure that they don't compromise the NR aspects that
apply to a particular individual.

>>In a sense, the NR bit goes further than my definition of the DS bit, in 
>>that the DS bit 
>>implies that the private key is not subject to governmental escrow as a 
>>condition of its 
>>export, import, or use, while the NR bit implies that the private key is 
>>not subject to 
>>ANY form of externally imposed escrow, key recovery, or key sharing.
>
>I strongly disagree! Don't confuse the issue by bringing in key escrow, key
>strength, key recovery, etc. into the picture. If I can coin a new phrase (and
>I'm not trying to insult you, I highly respect your opinions): KISS - Keep It
>Secure Stupid!

Well, thanks, but unfortunately as a US citizen I don't get to vote in the French 
elections. so whether we like it or not, these issues have to be dealt with.

All I'm suggesting is that the prohibitions against key sharing, access to keys by
people within the company, etc., etc., are not quite as rigid in the case of DS as 
they are in the NR case.  In either case, DS or NR, government access to keys
(GAK!) would be prohibited by the key typing, or vice versa, and so indicated.
>
>>
>>So what does this imply about various combinations of key usage bits?
>>
>>Clearly, the use of the DS bit and either key exchange or data encryption is not 
>>valid, as they are diametrically opposed concepts.
>
>YES!!
>
>>
>>Equally clearly, the use of both the DS and the NR bit _is_ allowed.
>
>YES!! If I could, I would require the DS bit to be set anytime the NR was set.

I'm not strongly opposed to that, and in fact that was my position prior to realizing 
that NR plus encryption could be used to indicate that no escrow was taking place.
If the DS bit would always be set, as opposed to using NR by itself, it would be
a few nanoseconds faster.
>
>>
>>But surprisingly, as I just realized while driving in to work this morning, the use 
>>of the NR bit in combination with key encryption or data encryption is NOT prohibited,
>>and in fact can be used as a form of back-handed specification of a key that can be 
>>used for encryption and is not subject to escrow or sharing!
>
>NO!! Do not mix key usage. To provide Non-Repudiation, you have to sign
>something and hence that key should not be used for encryption.

Well, not so fast.  Even if NR _always_ equates to a signature operation, that shouldn't
necessarily _prohibit_ its use for encryption, should it?  You and I might prefer to use
two different keys, but does that have to be imposed as a mandatory standard?

For example, is it possible to conceive of an SSL v3 session which uses client 
authentication, and claims nonrepudiation for the _session_, as opposed to signing
a particular document?  Seems to me that some home banking and similar applications 
might conceivably want to make use of such a concept.

I'll grant that by suggesting that NR might apply to encryption, I am stretching the 
popular concept a bit, and effectively redefining the key usage to mean "exclusive
control of the private key by the names user".  But isn't that effectively what we have 
been saying?

I won't go to war if the consensus is that we should restrict NR to signature operations,
but even then I wonder about such constructs as hashed MAC operations, etc.
>
>>That is the assumed or default case, where none of the key usage bits are specified.
>>
>>Using a key that is marked for both NR and key or data encryption does NOT mean that 
>>it is being used for digital signature, however -- at least with the above 
>>definition. But it 
>>does mean that that key is uniquely and exclusively associated with that user, which
>>in many cases is a very desirable condition.

I unfortunately muddied the water by a typo repeated several times.

>>So KR by itself or KR plus data encryption is OK.

Let's take them one at a time:

NR by itself is OK.  

I suppose you agree, but would prefer that NR always means signature,
and hence should never be used alone, whereas I am willing to allow (but would
discourage) a single key labeled NR being used for both signature and encryption purposes.

NR in combination with key encryption or data encryption is OK.

(This makes it explicit. In particular, it means that the key is NOT subject to key escrow
or other forms of sharing, whether or not it is used for signature purposes. So I would think 
you would like this??)

>>KR plus DS is OK.

>I would prefer NOT OK.

I meant NR plus DS is OK, and I think you meant to agree, except for the 
confusion, especially if you interpreted "KR" to mean key recovery.  
Sorry about that.
>
>>
>>DS by itself is OK.
>>
>>DS plus data encryption is forbidden.
>
>YES!!

In this case (DS by itself), I am assuming the use of a signature for 
integrity purposes, but perhaps with a lesser standard of exclusivity
of the key control (no key escrow, however), and also the lack of 
the gravity charge and the conscious, volitional usage?

Whereas the absence of both DS and KR would imply that the key 
might possible have been escrowed, and/or that the signature
might be generated by an automaton that is not under the specific 
control and case by case review of the user?
>
>>
>>Does this make sense?
>
>In general yes, but where does this leave a question I previously posted: "What
>happens when there is more than one certificate for a key?" Who ensures that
>there are no conflicting key usage in the different certificates?

Typing the key, as opposed to relying on the contents of the certificate, solves 
this problem. The key usage in the certificate is primarily of an advisory 
nature to the recipient.
>Regards,
>Aram Perez
>Apple Computer, Inc.

This stuff is hard, and we have to get it right.  I appreciate the detailed comments 
and the dialog.

Regards,

Bob

Date: Tue, 01 Sep 1998 13:39:54 -0400
To: "[email-masked]'" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: For  Option 2
Sender: [email-masked]

Date: Tue, 01 Sep 1998 13:39:47 -0400
To: "[email-masked]'" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Sender: [email-masked]

In case anyone is interested, here's my two cents worth...

The LDAP straw poll message concentrates on the technical rationale behind
each of the two options.  In fact, each is a technically sound proposal.
Option #1 is more elegant since there is no redundant data.  Option #2 is a
little more flexible, but clients may incur a performance hit when building
infrequently used paths.  IMHO, it's a wash.

I prefer option #2, but for rather pragmatic reasons.  There are two large
pools of PKI clients.  These two groups were designed independently, and
the implementers made different assumptions.  If we choose option #1, we
break one group of clients. HOWEVER, if we choose option #2, both sets of
clients will work - and will be interoperable!

Since a technically viable solution exists that doesn't break any existing
clients and actually makes them interoperable, that is my preference.

From: Anne Anderson - Sun Microsystems <[email-masked]>
Date: Tue,  1 Sep 1998 12:38:44 -0400 (EDT)
To: [email-masked]
Subject: For Option 1
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Steve Kent'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 11:10:28 -0400 
Sender: [email-masked]

Folks 

This is a straw poll on the use of the cACertificate and
crossCertificatePair attributes in the PKIX LDAP schema draft. There are 2
options, each of which received sufficient support during the Chicago
meeting to require this straw poll to resolve the issue. Below is the
specific text proposed for each option, followed by a summary of the
rationale behind each of the proposals. The specific text for the proposals
and rationale summaries have been cooperatively drafted by Santosh Chokhani,
Dave Horvath and myself.

Votes must be in by COB on Thursday Sept 3.  This is the only outstanding
issue on this I-D following the 2 week last call so we should be able to
progress both the PKIX LDAPv2 protocol profile and PKIX LDAPv2 schema
following this poll.
. 
To vote, send an email to [email-masked] with one of the following
subject lines: 

To vote for option 1put "For Option 1" in the subject line. 
To vote for option 2 put "For Option 2" in the subject line.	 

As with the earlier polls conducted by Tim Polk on Part 1, don't bother with
a message body, I am just going to count the messages.  Discussion of the
content of this message should reply to this message.

PROPOSED TEXT FOR THE ATTRIBUTE DEFINITIONS:
OPTION 1:
----------------
The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA. In addition, the cACertificate attribute shall be used to
store self-issued certificates.

The forward element of the crossCertificatePair attribute, held in a
particular CA's directory entry, shall be used to store certificates issued
to this CA by CAs in other domains.  Optionally, the reverse element of the
crossCertificatePair attribute, held in a particular CA's directory entry,
may contain certificates issued by this CA to CAs in other domains.

In the case of V3 certificates, none of the above CA certificates may
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

OPTION 2:
-------------
The crossCertificatePair attribute, held in a particular CA's directory
entry, shall be used to store all certificates issued by this CA to other
CAs, as well as certificates issued for this CA by other CAs. Values held in
the forward element are certificates issued for this CA by other CAs, while
values in the reverse element are certificates issued by this CA for other
CAs. 

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA. This set of certificates is a subset of the values of the
forward element of the crossCertificatePair attribute in the same CA entry.
In addition, the cACertificate attribute shall beused to store self-issued
certificates.  

The definition of domain is purely a matter of local policy.

In the case of version 3 certificates, none of the above CA certificates may
include a basicConstraints extension with the cA value set to FALSE.

SUMMARY OF RATIONALE FOR EACH OF THE OPTIONS:
--------------------------------------------------------------------

RATIONALE FOR PROPOSING OPTION 1:
--------------------------------------------------
The major advantage of this approach is that it minimizes the amount of data
retrieved from the directory.  The approach improves the relying party
response time and minimizes network utilization.

Another advantage of this approach over the alternative is that it does not
require the relying parties to separate the certificates stored in
caCertificate attribute from those stored in the crossCertificatePair
attribute.  The clients may need to do this during path construction.

Storing all the certificates in the crossCertificatePair attribute and also
storing some of the certificates in the caCertificate attribute, as
described in the alternative, unnecessarily increases the number of
certificates retrieved.  The alternative will result in poorer relying party
response time and use network bandwidth unnecessarily.  The alternative will
be particularly inefficient when a relying party is located remotely from
the repository/directory.

A minor disadvantage of the alternative is that it requires the same
information object (certificate) to be stored twice in a repository, once in
the caCertificate attribute and once in the crossCertificatePair attribute.
This increases he storage requirement on the directory.

RATIONALE FOR PROPOSING OPTION 2:
------------------------------------------------------------

Path development is a relying party process and the criteria for selection
of a 'preferred' set of certificates to enable efficiencies in that process
can vary according to the path discovery algorithm as well as from one
relying party to another, from one application to another, and on other
criteria as well. While a CA should optionally be able to provide helpful
hints to relying parties regarding the set of certificates the CA expects to
provide efficiencies, these may or may not match the requirements of a
relying party path discovery process. Relying parties will access CA
directory entries frequently to retrieve certificates as input to a
certification path development process and they should not be forced to know
whether or not a CA has published a set of  its 'preferred' certificates,
nor should relying parties be required to take on the extra burden of having
to request filtering of multiple directory attributes to retrieve the set of
certificates which is preferred in their particular environment, especially
given that relying parties will often need this information from CAs outside
their own local Intranet. 

CAs should be given the option to publish a set of 'preferred' certificates
but should not be required to do so. Should a CA elect to publish such a
set, the criteria used by that CA to determine the bases of the preference
should be left to the discretion of each CA or each security domain. The
preference should not be necessarily tied to a predetermined universal
criterion such as a single PKI or 'internal domain', especially given that a
CA may be issued a certificate by any number of other CAs and may therefore
subscribe to many PKIs.

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 

Date: Tue, 1 Sep 98 11:09:56 -0400
To: <[email-masked]>
From: "Fred Gloade Hrdc-drhc" <[email-masked]>
Reply-To: <[email-masked]>
Subject: fwd: Re: ...no subject...
Sender: [email-masked]

Fred Gloade 
Senior Auditor/Vérificateur principal
Information Technology and Systems
Technologies et systèmes informatiques
(819) 953-0842
[email-masked]

-------------
Original Text
From: "Steve Coya" <[email-masked]>, on 9/1/98 8:37 AM:
To: [email-masked]@NHQ
Cc: INET[<[email-masked]>]

Fred,

Your question should be sent to the PKIX Working Group:
[email-masked]

On Mon, 24 Aug 1998, Fred Gloade Hrdc-drhc wrote:

>>OK help me out here. 
>>With PKI do we need to rewrite code to incorporate the encryption 
routines?
>>There will be a server maintained somewhere with the public keys?
>>Will there be a hardware component or just a PIN?
>>Do you have a simple diagram that shows the flow of information in a very 
>>simple way?
>>Anything else you can send to help me would be greatly appreciated.
>>
>>
>>Fred Gloade 
>>Senior Auditor/VÚrificateur principal
>>Information Technology and Systems
>>Technologies et systþmes informatiques
>>(819) 953-0842
>>[email-masked]
>>
>>
>>

o