RE: NEW Data type for certificate selection ?

[Alan Lloyd <[e-mail]>]

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; '[e-mail] '; '[e-mail] ';
'[e-mail] '
Sent: 10/1/98 8:53:52 AM
Subject: Re: NEW Data type for certificate selection ?

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,
>> 
>> 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 ([e-mail])
>> >
>> >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: [e-mail]
>> >> To: [e-mail]; [e-mail];
>> >> [e-mail]
>> >> Sent: 9/29/98 1:01:30 PM
>> >> Subject: Re: NEW Data type for certificate selection ?
>> >>
>> >> 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:
>> >> "
>> >>  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.
>> >>
>> >> "
>> >> Oh well - that counts me out. I cannot do solutions - without the
>> >> solution :-)))
>> >> regards alan
>> >>
>> >> Peter.
>> >>
>> >
>> >
>> >----------------- SEIS mailing list ([e-mail])
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: [e-mail]
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. [phone]
>> 216 42  Malmö                   Fax. [phone]
>> Sweden                        Mobile [phone]
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA06142 for ietf-pkix-bks; Wed, 30 Sep 1998 20:42:21 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA06133 for <[e-mail]>; Wed, 30 Sep 1998 20:42:19 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id AAA28197; Thu, 1 Oct 1998 00:48:37 -0300
Date: Thu, 1 Oct 1998 00:48:37 -0300 (EST)
From: Ed Gerck <[e-mail]>
To: Stefan Santesson <[e-mail]>
cc: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Thu, 1 Oct 1998, Stefan Santesson wrote:

>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"

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!

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

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?

>Regardless of this I fail to see how this can be used to pick the right
>"non-repudiation" certificate in the Java script application.

Please read above, I hope it is clearer now.

> I also fail
>to understand if you suggest that the current SSL/TLS functions solves all
>my problems or just a part of them.
>

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

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


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
>equal to suggest that the SSN should be encrypted with a secret key (where
>the "salt" is being that secret key).
>

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


>You and I can argue for centuries if certificates handled in browsers
>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
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [e-mail]
http://novaware.cps.softex.br



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03186 for ietf-pkix-bks; Wed, 30 Sep 1998 16:21:27 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03180 for <[e-mail]>; Wed, 30 Sep 1998 16:21:04 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX35284S>; Thu, 1 Oct 1998 09:25:21 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B9C9@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Dave Horvath '" <[e-mail]>, "'Stefan Santesson '" <[e-mail]>
Cc: Alan Lloyd <[e-mail]>, "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 09:25:18 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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; '[e-mail] '; '[e-mail] ';
'[e-mail] '
Sent: 10/1/98 8:53:52 AM
Subject: Re: NEW Data type for certificate selection ?

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,
>> 
>> 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 ([e-mail])
>> >
>> >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: [e-mail]
>> >> To: [e-mail]; [e-mail];
>> >> [e-mail]
>> >> Sent: 9/29/98 1:01:30 PM
>> >> Subject: Re: NEW Data type for certificate selection ?
>> >>
>> >> 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:
>> >> "
>> >>  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.
>> >>
>> >> "
>> >> Oh well - that counts me out. I cannot do solutions - without the
>> >> solution :-)))
>> >> regards alan
>> >>
>> >> Peter.
>> >>
>> >
>> >
>> >----------------- SEIS mailing list ([e-mail])
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: [e-mail]
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. [phone]
>> 216 42  Malmö                   Fax. [phone]
>> Sweden                        Mobile [phone]
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03019 for ietf-pkix-bks; Wed, 30 Sep 1998 15:50:00 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03010 for <[e-mail]>; Wed, 30 Sep 1998 15:49:51 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id AAA07763; Thu, 1 Oct 1998 00:56:48 +0200 (CEST)
Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA28412; Thu, 1 Oct 1998 00:56:46 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 00:53:52 +0200
To: Dave Horvath <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Cc: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA03011
Sender: [e-mail]
Precedence: bulk

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,
>> 
>> 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 ([e-mail])
>> >
>> >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: [e-mail]
>> >> To: [e-mail]; [e-mail];
>> >> [e-mail]
>> >> Sent: 9/29/98 1:01:30 PM
>> >> Subject: Re: NEW Data type for certificate selection ?
>> >>
>> >> 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:
>> >> "
>> >>  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.
>> >>
>> >> "
>> >> Oh well - that counts me out. I cannot do solutions - without the
>> >> solution :-)))
>> >> regards alan
>> >>
>> >> Peter.
>> >>
>> >
>> >
>> >----------------- SEIS mailing list ([e-mail])
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: [e-mail]
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. [phone]
>> 216 42  Malmö                   Fax. [phone]
>> Sweden                        Mobile [phone]
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02842 for ietf-pkix-bks; Wed, 30 Sep 1998 15:31:06 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02838 for <[e-mail]>; Wed, 30 Sep 1998 15:31:04 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id AAA18769; Thu, 1 Oct 1998 00:37:58 +0200 (CEST)
Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA23766; Thu, 1 Oct 1998 00:37:55 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 00:35:02 +0200
To: Ed Gerck <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Cc: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA02839
Sender: [e-mail]
Precedence: bulk

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:
>
>>
>>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.
>
>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.
>
>>
>>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.
>
>
>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
>______________________________________________________________________
>Dr.rer.nat. E. Gerck                     [e-mail]
>http://novaware.cps.softex.br
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00464 for ietf-pkix-bks; Wed, 30 Sep 1998 11:04:46 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00443 for <[e-mail]>; Wed, 30 Sep 1998 11:02:19 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id PAA27526; Wed, 30 Sep 1998 15:08:28 -0300
Date: Wed, 30 Sep 1998 15:08:26 -0300 (EST)
From: Ed Gerck <[e-mail]>
To: Stefan Santesson <[e-mail]>
cc: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 30 Sep 1998, Stefan Santesson wrote:

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

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.

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


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
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [e-mail]
http://novaware.cps.softex.br





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00258 for ietf-pkix-bks; Wed, 30 Sep 1998 10:37:53 -0700 (PDT)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00254 for <[e-mail]>; Wed, 30 Sep 1998 10:37:44 -0700 (PDT)
Received: from klerer.basit.com (shiva120 [128.209.144.120]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id NAA06626 for <[e-mail]>; Wed, 30 Sep 1998 13:44:11 -0400 (EDT)
Message-ID: <008101bdec99$e9fa7a60$[e-mail]>
From: "Robert Klerer" <[e-mail]>
To: <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Date: Wed, 30 Sep 1998 13:44:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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 ([e-mail])
>>
>>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: [e-mail]
>>> To: [e-mail]; [e-mail];
>>> [e-mail]
>>> Sent: 9/29/98 1:01:30 PM
>>> Subject: Re: NEW Data type for certificate selection ?
>>>
>>> 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:
>>> "
>>>  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.
>>>
>>> "
>>> Oh well - that counts me out. I cannot do solutions - without the
>>> solution :-)))
>>> regards alan
>>>
>>> Peter.
>>>
>>
>>
>>----------------- SEIS mailing list ([e-mail])
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: [e-mail]
>>
>>
>>
>-------------------------------------------------------------------
>Stefan Santesson                <[e-mail]>
>Accurata Systemsäkerhet AB
>Lotsgatan 27 D                  Tel. [phone]
>216 42  Malmö                   Fax. [phone]
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29980 for ietf-pkix-bks; Wed, 30 Sep 1998 10:14:37 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29976 for <[e-mail]>; Wed, 30 Sep 1998 10:14:34 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id NAA08397; Wed, 30 Sep 1998 13:21:48 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 30 Sep 1998 13:20:43 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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,
> 
> 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 ([e-mail])
> >
> >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: [e-mail]
> >> To: [e-mail]; [e-mail];
> >> [e-mail]
> >> Sent: 9/29/98 1:01:30 PM
> >> Subject: Re: NEW Data type for certificate selection ?
> >>
> >> 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:
> >> "
> >>  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.
> >>
> >> "
> >> Oh well - that counts me out. I cannot do solutions - without the
> >> solution :-)))
> >> regards alan
> >>
> >> Peter.
> >>
> >
> >
> >----------------- SEIS mailing list ([e-mail])
> >Info about this list: http://www.nc-forum.com/seis
> >SEIS Contact: [e-mail]
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. [phone]
> 216 42  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28790 for ietf-pkix-bks; Wed, 30 Sep 1998 07:39:59 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28786 for <[e-mail]>; Wed, 30 Sep 1998 07:39:57 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id QAA02188; Wed, 30 Sep 1998 16:46:36 +0200 (CEST)
Received: from stefans (t3o68p79.telia.com [62.20.139.79]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA25183; Wed, 30 Sep 1998 16:46:29 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 30 Sep 1998 16:43:41 +0200
To: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA28787
Sender: [e-mail]
Precedence: bulk

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 ([e-mail])
>
>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: [e-mail]
>> To: [e-mail]; [e-mail];
>> [e-mail]
>> Sent: 9/29/98 1:01:30 PM
>> Subject: Re: NEW Data type for certificate selection ?
>> 
>> 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:
>> "
>>  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.
>> 
>> "
>> Oh well - that counts me out. I cannot do solutions - without the
>> solution :-)))
>> regards alan
>> 
>> Peter.
>>
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [e-mail]
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA05527 for ietf-pkix-bks; Tue, 29 Sep 1998 20:00:40 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA05523 for <[e-mail]>; Tue, 29 Sep 1998 20:00:39 -0700 (PDT)
Received: from chromatix.com (cc1020663-a.hwrd1.md.home.com [24.3.62.220]) by chromatix.com (8.8.8/8.8.8) with ESMTP id XAA06421; Tue, 29 Sep 1998 23:07:34 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 30 Sep 1998 11:15:51 -0400
From: David Horvath <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.05 [en]C-AtHome0404  (Win95; U)
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
References: <D1A949D4508DD1119C8100400533BEDC07B96A@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
> To: [e-mail]; [e-mail];
> [e-mail]
> Sent: 9/29/98 1:01:30 PM
> Subject: Re: NEW Data type for certificate selection ?
> 
> 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:
> "
>  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.
> 
> "
> Oh well - that counts me out. I cannot do solutions - without the
> solution :-)))
> regards alan
> 
> Peter.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06015 for ietf-pkix-bks; Tue, 29 Sep 1998 10:32:40 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06011 for <[e-mail]>; Tue, 29 Sep 1998 10:32:39 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA18568; Tue, 29 Sep 1998 10:38:57 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.67 (Beta)
Date: Tue, 29 Sep 1998 13:30:03 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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, [e-mail] 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).
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA03135 for ietf-pkix-bks; Tue, 29 Sep 1998 05:01:19 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA03131 for <[e-mail]>; Tue, 29 Sep 1998 05:01:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA07388; Tue, 29 Sep 1998 08:06:01 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
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: [e-mail]
Precedence: bulk

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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25568 for ietf-pkix-bks; Tue, 29 Sep 1998 00:26:22 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA25564 for <[e-mail]>; Tue, 29 Sep 1998 00:26:14 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA18103; Tue, 29 Sep 1998 09:32:34 +0200
Received: by HYDRA with Microsoft Mail id <01BDEB8B.32948E60@HYDRA>; Tue, 29 Sep 1998 09:26:11 +0200
Message-ID: <01BDEB8B.32948E60@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 09:26:09 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Peter, see in-line comment below.

On Tue, 29 Sep 1998, Peter Gutmann wrote:

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

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA07285 for ietf-pkix-bks; Mon, 28 Sep 1998 15:25:34 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA07281 for <[e-mail]>; Mon, 28 Sep 1998 15:25:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Mon, 28 Sep 1998 15:31:45 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA07078 for ietf-pkix-bks; Mon, 28 Sep 1998 14:49:02 -0700 (PDT)
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07074 for <[e-mail]>; Mon, 28 Sep 1998 14:49:01 -0700 (PDT)
From: [e-mail]
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id OAA21156 for <[e-mail]>; Mon, 28 Sep 1998 14:55:57 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id OAA06803 for <[e-mail]>; Mon, 28 Sep 1998 14:55:56 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 8825668D.007878E7 ; Mon, 28 Sep 1998 14:55:52 -0700
X-Lotus-FromDomain: 3COM
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 28 Sep 1998 14:55:42 -0700
Subject: A question and comment about PKIX - Part 1, Version 11.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06782 for ietf-pkix-bks; Mon, 28 Sep 1998 14:07:46 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06778 for <[e-mail]>; Mon, 28 Sep 1998 14:07:43 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX3528L9>; Tue, 29 Sep 1998 07:11:57 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B96A@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 07:11:56 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

 
Snip

----------
From: [e-mail]
To: [e-mail]; [e-mail];
[e-mail]
Sent: 9/29/98 1:01:30 PM
Subject: Re: NEW Data type for certificate selection ?

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: 
"
 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.

" 
Oh well - that counts me out. I cannot do solutions - without the
solution :-)))
regards alan
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06221 for ietf-pkix-bks; Mon, 28 Sep 1998 12:40:54 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06217 for <[e-mail]>; Mon, 28 Sep 1998 12:40:51 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id QAA25781; Mon, 28 Sep 1998 16:47:26 -0300
Date: Mon, 28 Sep 1998 16:47:25 -0300 (EST)
From: Ed Gerck <[e-mail]>
To: Peter Gutmann <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 29 Sep 1998, Peter Gutmann wrote:

>Stefan Santesson <[e-mail]> 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".

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                     [e-mail]
http://novaware.cps.softex.br









Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05133 for ietf-pkix-bks; Mon, 28 Sep 1998 10:36:01 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA05129 for <[e-mail]>; Mon, 28 Sep 1998 10:36:00 -0700 (PDT)
Received: 	id NAA23349; Mon, 28 Sep 1998 13:40:24 -0400
Received: by gateway id <TTXVY461>; Mon, 28 Sep 1998 13:36:56 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Time Stamp and Notary Drafts
Date: Mon, 28 Sep 1998 13:36:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA03570 for ietf-pkix-bks; Mon, 28 Sep 1998 07:54:56 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03564 for <[e-mail]>; Mon, 28 Sep 1998 07:54:54 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA31163; Tue, 29 Sep 1998 03:01:30 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90699489017466>; Tue, 29 Sep 1998 03:01:30 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: NEW Data type for certificate selection ?
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 29 Sep 1998 03:01:30 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Stefan Santesson <[e-mail]> 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.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA03363 for ietf-pkix-bks; Mon, 28 Sep 1998 07:26:38 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA03359 for <[e-mail]>; Mon, 28 Sep 1998 07:26:37 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Mon, 28 Sep 1998 07:32:49 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Questions about PKIX
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02828 for ietf-pkix-bks; Mon, 28 Sep 1998 06:08:00 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA02824 for <[e-mail]>; Mon, 28 Sep 1998 06:07:58 -0700 (PDT)
Received: 	id JAA14392; Mon, 28 Sep 1998 09:12:56 -0400
Received: by gateway id <TTXVYTLB>; Mon, 28 Sep 1998 09:09:28 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Alan Lloyd'" <[e-mail]>
Cc: "'Warwick Ford'" <[e-mail]>, "'Steve Kent'" <[e-mail]>
Subject: RE: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 09:07:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 27, 1998 6:24 PM
> To: 	'[e-mail]'
> 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
>    
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02819 for ietf-pkix-bks; Mon, 28 Sep 1998 06:07:45 -0700 (PDT)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02815 for <[e-mail]>; Mon, 28 Sep 1998 06:07:43 -0700 (PDT)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id WAA08964; Mon, 28 Sep 1998 22:03:40 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA04781; Mon, 28 Sep 98 22:08:15 JST
Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id WAA15195; Mon, 28 Sep 1998 22:20:13 +0900 (JST)
Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA27264; Mon, 28 Sep 98 22:14:03 JST
Received: from zaku by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA23057; Mon, 28 Sep 1998 22:14:02 +0900
Message-Id: <[e-mail]>
Date: Mon, 28 Sep 1998 22:11:42 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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 ?

> 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 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
Mitsubishi Electric Corp.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02371 for ietf-pkix-bks; Mon, 28 Sep 1998 05:12:10 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA02367 for <[e-mail]>; Mon, 28 Sep 1998 05:12:08 -0700 (PDT)
Received: 	id IAA05607; Mon, 28 Sep 1998 08:16:44 -0400
Received: by gateway id <TTXVYT12>; Mon, 28 Sep 1998 08:13:15 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Mon, 28 Sep 1998 08:13:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 27, 1998 12:32 PM
> To: 	'[e-mail]'
> Cc: 	[e-mail]
> 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:	[e-mail] [SMTP:[e-mail]]
> > Sent:	Thursday, September 24, 1998 10:27 AM
> > Cc:	[e-mail]
> > 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 [e-mail]
> > 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:	[e-mail].  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 >> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA29636 for ietf-pkix-bks; Mon, 28 Sep 1998 02:14:15 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA29632 for <[e-mail]>; Mon, 28 Sep 1998 02:14:11 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id LAA01066; Mon, 28 Sep 1998 11:20:25 +0200 (MET DST)
Received: from stefans (t4o68p93.telia.com [62.20.139.213]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id LAA29513; Mon, 28 Sep 1998 11:20:09 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Sep 1998 11:17:31 +0200
To: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA29633
Sender: [e-mail]
Precedence: bulk

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






At 09:30 AM 9/27/98 +1000, Alan Lloyd wrote:
>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: [e-mail]; [e-mail]; [e-mail];
>[e-mail]
>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.
>
>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                <[e-mail]>
>Accurata Systemsäkerhet AB     
>Lotsgatan 27 D                  Tel. [phone]              
>216 42  Malmö                   Fax. [phone]              
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA29311 for ietf-pkix-bks; Mon, 28 Sep 1998 01:12:47 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA29307 for <[e-mail]>; Mon, 28 Sep 1998 01:12:40 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX3528J0>; Mon, 28 Sep 1998 18:16:46 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B94C@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'tyone '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 28 Sep 1998 18:16:45 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
Sent: 9/28/98 12:19:19 PM
Subject: Re: NEW Data type for certificate selection ?

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.


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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA28865 for ietf-pkix-bks; Mon, 28 Sep 1998 00:48:15 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA28861 for <[e-mail]>; Mon, 28 Sep 1998 00:48:14 -0700 (PDT)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id DAA10830 for <[e-mail]>; Mon, 28 Sep 1998 03:59:14 -0400 (EDT)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id DAA28532 for <[e-mail]>; Mon, 28 Sep 1998 03:53:32 -0400 (EDT)
Received: by mta2.lotus.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525668D.002BF5DA ; Mon, 28 Sep 1998 04:00:09 -0400
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
cc: Helmut_Speichermann/FRA/[e-mail], Boris_Baltzer/MUC1/[e-mail], Georg_Zyprian/FRA/[e-mail]
Message-ID: <[e-mail]>
Date: Mon, 28 Sep 1998 09:51:59 +0200
Subject: Questions about PKIX
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10325 for ietf-pkix-bks; Sun, 27 Sep 1998 19:17:09 -0700 (PDT)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10321 for <[e-mail]>; Sun, 27 Sep 1998 19:17:07 -0700 (PDT)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id LAA05603 for <[e-mail]>; Mon, 28 Sep 1998 11:13:31 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA27021; Mon, 28 Sep 98 11:18:05 JST
Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id LAA04167 for <[e-mail]>; Mon, 28 Sep 1998 11:30:03 +0900 (JST)
Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA15585; Mon, 28 Sep 98 11:23:54 JST
Received: from edberg by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA09263; Mon, 28 Sep 1998 11:23:53 +0900
Message-Id: <[e-mail]>
Date: Mon, 28 Sep 1998 11:19:19 +0900
From: tyone <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (WinNT; I)
Mime-Version: 1.0
To: [e-mail]
Subject: Re: NEW Data type for certificate selection ?
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09408 for ietf-pkix-bks; Sun, 27 Sep 1998 15:20:57 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09403 for <[e-mail]>; Sun, 27 Sep 1998 15:20:53 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX352825>; Mon, 28 Sep 1998 08:24:58 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B944@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 08:24:56 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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
   


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA08414 for ietf-pkix-bks; Sun, 27 Sep 1998 09:26:54 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA08410 for <[e-mail]>; Sun, 27 Sep 1998 09:26:53 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDQFB>; Sun, 27 Sep 1998 12:32:13 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1ADC@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Sun, 27 Sep 1998 12:32:11 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:	[e-mail] [SMTP:[e-mail]]
> Sent:	Thursday, September 24, 1998 10:27 AM
> Cc:	[e-mail]
> 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 [e-mail]
> 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:	[e-mail].  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 >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21031 for ietf-pkix-bks; Sat, 26 Sep 1998 16:25:58 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21027 for <[e-mail]>; Sat, 26 Sep 1998 16:25:50 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TS1VBY1B>; Sun, 27 Sep 1998 09:30:03 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B92F@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'Stefan Santesson '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Sun, 27 Sep 1998 09:30:02 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA21028
Sender: [e-mail]
Precedence: bulk

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: [e-mail]; [e-mail]; [e-mail];
[e-mail]
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.

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                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23104 for ietf-pkix-bks; Fri, 25 Sep 1998 09:18:29 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23100 for <[e-mail]>; Fri, 25 Sep 1998 09:18:29 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA27992; Fri, 25 Sep 1998 09:22:39 -0700 (PDT)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA00996; Fri, 25 Sep 1998 09:24:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Sep 1998 09:24:36 -0700
To: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
From: Michael Myers <[e-mail]>
Subject: Re: Archive cutoff & Retention period
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA23101
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22174 for ietf-pkix-bks; Fri, 25 Sep 1998 07:21:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22170 for <[e-mail]>; Fri, 25 Sep 1998 07:21:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06021; Fri, 25 Sep 1998 10:27:54 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-08.txt
Date: Fri, 25 Sep 1998 10:27:54 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail] 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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21217 for ietf-pkix-bks; Fri, 25 Sep 1998 04:31:00 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21213 for <[e-mail]>; Fri, 25 Sep 1998 04:30:59 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id NAA16726; Fri, 25 Sep 1998 13:37:15 +0200 (CEST)
Received: from stefans (t3o68p4.telia.com [62.20.139.4]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA10344; Fri, 25 Sep 1998 13:37:14 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Sep 1998 13:34:29 +0200
To: "Miklos, Sue A." <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA21214
Sender: [e-mail]
Precedence: bulk

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:
> 
>
>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:[e-mail]]
>>Sent: 	Thursday, September 24, 1998 8:41 AM
>>To: 	[e-mail]; [e-mail]; [e-mail];
>>[e-mail]
>>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                <[e-mail]>
>>Accurata Systemsäkerhet AB     
>>Lotsgatan 27 D                  Tel. [phone]              
>>216 42  Malmö                   Fax. [phone]              
>>Sweden                        Mobile [phone]
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>>
>
>Attachment Converted: "c:\internet\eudora\attach\MATCH2.DOC"
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18649 for ietf-pkix-bks; Fri, 25 Sep 1998 02:25:59 -0700 (PDT)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18645 for <[e-mail]>; Fri, 25 Sep 1998 02:25:52 -0700 (PDT)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id SAA24749; Fri, 25 Sep 1998 18:21:35 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA00363; Fri, 25 Sep 98 18:26:06 JST
Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id SAA08497; Fri, 25 Sep 1998 18:37:55 +0900 (JST)
Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA29300; Fri, 25 Sep 98 18:31:52 JST
Received: from zaku by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA19581; Fri, 25 Sep 1998 18:31:52 +0900
Message-Id: <[e-mail]>
Date: Fri, 25 Sep 1998 18:29:35 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: NEW Data type for certificate selection ?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
X-Mime-Autoconverted: from 8bit to quoted-printable by inetgw.melco.co.jp id SAA08497
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA18646
Sender: [e-mail]
Precedence: bulk

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
Mitsubishi Electric Corp.


Stefan Santesson wrote:

> 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                <[e-mail]>
> Accurata Systems$BgL(Berhet AB
> Lotsgatan 27 D                  Tel. [phone]
> 216 42  Malm$Bö (B                  Fax. [phone]
> Sweden                        Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22412 for ietf-pkix-bks; Thu, 24 Sep 1998 08:55:58 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22408 for <[e-mail]>; Thu, 24 Sep 1998 08:55:56 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA24293 for <[e-mail]>; Thu, 24 Sep 1998 12:02:10 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA24288 for <[e-mail]>; Thu, 24 Sep 1998 12:02:09 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA15598 for <[e-mail]>; Thu, 24 Sep 1998 12:01:26 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 24 Sep 1998 12:02:06 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Thu, 24 Sep 1998 12:02:06 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 24 Sep 1998 12:02:05 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDE7B3.26345CD0"
Sender: [e-mail]
Precedence: bulk

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

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:[e-mail]]
>Sent: 	Thursday, September 24, 1998 8:41 AM
>To: 	[e-mail]; [e-mail]; [e-mail];
>[e-mail]
>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                <[e-mail]>
>Accurata Systems=E4kerhet AB    =20
>Lotsgatan 27 D                  Tel. [phone]             =20
>216 42  Malm=F6                   Fax. [phone]             =20
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>

------ =_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/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////1IA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAWAAUA//////////8DAAAAAAkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAIZMlDsA6rwB
AwAAAIADAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAYgAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf////8EAAAA/////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAdTQAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv
AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEBAQAAAAIA
AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAACGTJQ7AOq8AYZMlDsA6rwBAAAAANQNNBRABNQNAQAA
AP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAP7/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////8BAP7/
AwoAAP////8ACQIAAAAAAMAAAAAAAABGHAAAAE1pY3Jvc29mdCBXb3JkIDYuMCBEb2N1bWVudAAK
AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYAAAAAADsAAwD+/wkABgAAAAAAAAAAAAAA
AQAAAAEAAAAAAP7/AAADCgAAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA
ALACAAAOAAAABwAAAJgAAAACAAAA3AAAAAQAAAAAAQAACAAAACQBAAAMAAAASAEAAAsAAABsAQAA
DQAAAJABAAAPAAAAtAEAABAAAADYAQAACgAAAPwBAAASAAAAIAIAAA4AAABEAgAACQAAAGgCAAAT
AAAAjAIAAP//////////////////////////////////////////HgAAACgAAABDOlxNU09GRklD
RVxXSU5XT1JEXFRFTVBMQVRFXE5PUk1BTC5ET1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAFAAA
ADEyLjcJTWF0Y2hpbmcgcnVsZXMAAAAAAAAAAAAeAAAADgAAAFN1ZSBBLiBNaWtsb3MAAAAAAAAA
AAAAAAAAAAAeAAAADgAAAFN1ZSBBLiBNaWtsb3MAAAAAAAAAAAAAAAAAAABAAAAAhn3TndylZQA9
wAkEAAAAAGUAAAAAAAAAAAAAAAADAAAHMwAAHU0AAAAAAAAAAAAAAAAAAAAAAAAHMAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAKAMAAABEAAAoAwAAKEcAAAAAAAAoRwAAAAAA
AChHAAAAAAAAKEcAAAAAAAAoRwAAFAAAAKJHAAA8AAAAokcAAAAAAADeRwAAAAAAAN5HAAAAAAAA
3kcAAAAAAADeRwAAFgAAAPRHAAAiAAAAokcAAAAAAAAjTAAAZQAAABZIAAAAAAAAFkgAAAAAAAAW
SAAAAAAAABZIAAAAAAAAFkgAAAAAAAAWSAAAAAAAABZIAAAAAAAAFkgAAAAAAAA4SAAAAgAAADpI
AAAAAAAAOkgAAAAAAAA6SAAAIwAAAF1IAADUAQAAMUoAANQBAAAFTAAAHgAAAIhMAABUAAAA3EwA
AEEAAAAjTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoRwAAAAAAABZIAAAAAAAAAAAaAB0AAwAFABZI
AAAAAAAAFkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkgAAAAAAAAWSAAAAAAAACNMAAAAAAAAFkgA
AAAAAAAoRwAAAAAAAChHAAAAAAAAFkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkgAAAAAAAAWSAAA
AAAAABZIAAAAAAAAFkgAAAAAAAAWSAAAAAAAAChHAAAAAAAAFkgAAAAAAAAoRwAAAAAAABZIAAAA
AAAAOEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPEcAACYAAABiRwAAQAAAAChHAAAAAAAAKEcAAAAA
AAAoRwAAAAAAAChHAAAAAAAAFkgAAAAAAAA4SAAAAAAAABZIAAAiAAAAFkgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEVYQ0VSUFRTIEZST00gVEhFIDE5OTcgWC41MDAgU2VyaWVz
IG9mIFJlY29tbWVuZGF0aW9ucyBmb3IgSW5mb3JtYXRpb25hbCBQdXJwb3NlcyBPbmx5Lg0NMTIu
NwlNYXRjaGluZyBydWxlcw1UaGlzIERpcmVjdG9yeSBTcGVjaWZpY2F0aW9uIGRlZmluZXMgbWF0
Y2hpbmcgcnVsZXMgZm9yIHVzZSB3aXRoIGF0dHJpYnV0ZXMgb2YgdHlwZSBDZXJ0aWZpY2F0ZSwg
Q2VydGlmaWNhdGVQYWlyLCBDZXJ0aWZpY2F0ZUxpc3QsIGFuZCBTdXBwb3J0ZWRBbGdvcml0aG0s
IHJlc3BlY3RpdmVseS4NMTIuNy4xCUNlcnRpZmljYXRlIGV4YWN0IG1hdGNoDVRoZSBjZXJ0aWZp
Y2F0ZSBleGFjdCBtYXRjaCBydWxlIGNvbXBhcmVzIGZvciBlcXVhbGl0eSBhIHByZXNlbnRlZCB2
YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1ZSBvZiB0eXBlIENlcnRpZmljYXRlLiBJdCB1bmlx
dWVseSBzZWxlY3RzIGEgc2luZ2xlIGNlcnRpZmljYXRlLg1jZXJ0aWZpY2F0ZUV4YWN0TWF0Y2gg
TUFUQ0hJTkctUlVMRSA6Oj0gewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZUV4YWN0QXNzZXJ0aW9uCwlJ
RAkJCWlkLW1yLWNlcnRpZmljYXRlRXhhY3RNYXRjaCB9DUNlcnRpZmljYXRlRXhhY3RBc3NlcnRp
b24gOjo9IFNFUVVFTkNFIHsLCXNlcmlhbE51bWJlcgkJQ2VydGlmaWNhdGVTZXJpYWxOdW1iZXIs
Cwlpc3N1ZXIJCQlOYW1lIH0NVGhpcyBtYXRjaGluZyBydWxlIHJldHVybnMgVFJVRSBpZiB0aGUg
Y29tcG9uZW50cyBpbiB0aGUgYXR0cmlidXRlIHZhbHVlIG1hdGNoIHRob3NlIGluIHRoZSBwcmVz
ZW50ZWQgdmFsdWUuDTEyLjcuMglDZXJ0aWZpY2F0ZSBtYXRjaA1UaGUgY2VydGlmaWNhdGUgbWF0
Y2ggcnVsZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1
ZSBvZiB0eXBlIENlcnRpZmljYXRlLiBJdCBzZWxlY3RzIG9uZSBvciBtb3JlIGNlcnRpZmljYXRl
cyBvbiB0aGUgYmFzaXMgb2YgdmFyaW91cyBjaGFyYWN0ZXJpc3RpY3MuDWNlcnRpZmljYXRlTWF0
Y2ggTUFUQ0hJTkctUlVMRSA6Oj0gewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZUFzc2VydGlvbgsJSUQJ
CQlpZC1tci1jZXJ0aWZpY2F0ZU1hdGNoIH0NQ2VydGlmaWNhdGVBc3NlcnRpb24gOjo9IFNFUVVF
TkNFIHsLCXNlcmlhbE51bWJlcgkJWzBdIENlcnRpZmljYXRlU2VyaWFsTnVtYmVyCQlPUFRJT05B
TCwLCWlzc3VlcgkJCQlbMV0gTmFtZSAJCQlPUFRJT05BTCwLCXN1YmplY3RLZXlJZGVudGlmaWVy
CVsyXSBTdWJqZWN0S2V5SWRlbnRpZmllcgkJT1BUSU9OQUwsCwlhdXRob3JpdHlLZXlJZGVudGlm
aWVyCVszXSBBdXRob3JpdHlLZXlJZGVudGlmaWVyIAkJT1BUSU9OQUwsCwljZXJ0aWZpY2F0ZVZh
bGlkCQlbNF0gVVRDVGltZQkJCU9QVElPTkFMLAsJcHJpdmF0ZUtleVZhbGlkCQlbNV0gR2VuZXJh
bGl6ZWRUaW1lCQlPUFRJT05BTCwLCXN1YmplY3RQdWJsaWNLZXlBbGdJRAlbNl0gT0JKRUNUIElE
RU5USUZJRVIJCU9QVElPTkFMLAsJa2V5VXNhZ2UJCQlbN10gS2V5VXNhZ2UJCQlPUFRJT05BTCwL
CXN1YmplY3RBbHROYW1lCQlbOF0gQWx0TmFtZVR5cGUJCU9QVElPTkFMLAsJcG9saWN5CQkJCVs5
XSBDZXJ0UG9saWN5U2V0CQlPUFRJT05BTCwLCXBhdGhUb05hbWUJCVsxMF0gTmFtZQkJCU9QVElP
TkFMIH0NQWx0TmFtZVR5cGUgOjo9IENIT0lDRSB7IAsJYnVpbHRpbk5hbWVGb3JtCUVOVU1FUkFU
RUQgewsJCQkJCXJmYzgyMk5hbWUJCSgxKSwLCQkJCQlkTlNOYW1lCQkoMiksCwkJCQkJeDQwMEFk
ZHJlc3MJCSgzKSwLCQkJCQlkaXJlY3RvcnlOYW1lCSg0KSwLCQkJCQllZGlQYXJ0eU5hbWUJCSg1
KSwLCQkJCQl1bmlmb3JtUmVzb3VyY2VJZGVudGlmaWVyICg2KSwLCQkJCQlpUEFkZHJlc3MJCSg3
KSwLCQkJCQlyZWdpc3RlcmVkSWQJCSg4KSB9LAsJb3RoZXJOYW1lRm9ybQlPQkpFQ1QgSURFTlRJ
RklFUiB9DVRoaXMgbWF0Y2hpbmcgcnVsZSByZXR1cm5zIFRSVUUgaWYgYWxsIG9mIHRoZSBjb21w
b25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZSBtYXRjaCB0aGUg
Y29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBhdHRyaWJ1dGUgdmFsdWUsIGFzIGZvbGxv
d3M6DWEpCXNlcmlhbE51bWJlciBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVu
dCBpbiB0aGUgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50ZWQgdmFs
dWU7DWIpCWlzc3VlciBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVudCBpbiB0
aGUgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50ZWQgdmFsdWU7DWMp
CXN1YmplY3RLZXlJZGVudGlmaWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVlIG9mIHRoaXMgY29tcG9u
ZW50IGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVz
ZW50ZWQgdmFsdWU7IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZh
bHVlIGNvbnRhaW5zIG5vIHN1YmplY3Qga2V5IGlkZW50aWZpZXIgZXh0ZW5zaW9uOw1kKQlhdXRo
b3JpdHlLZXlJZGVudGlmaWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVlIG9mIHRoaXMgY29tcG9uZW50
IGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50
ZWQgdmFsdWU7IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVl
IGNvbnRhaW5zIG5vIGF1dGhvcml0eSBrZXkgaWRlbnRpZmllciBleHRlbnNpb24gb3IgaWYgbm90
IGFsbCBjb21wb25lbnRzIGluIHRoZSBwcmVzZW50ZWQgdmFsdWUgYXJlIHByZXNlbnQgaW4gdGhl
IHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWU7DWUpCWNlcnRpZmljYXRlVmFsaWQgbWF0Y2hlcyBpZiB0
aGUgcHJlc2VudGVkIHZhbHVlIGZhbGxzIHdpdGhpbiB0aGUgdmFsaWRpdHkgcGVyaW9kIG9mIHRo
ZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOw1mKQlwcml2YXRlS2V5VmFsaWQgbWF0Y2hlcyBpZiB0
aGUgcHJlc2VudGVkIHZhbHVlIGZhbGxzIHdpdGhpbiB0aGUgcGVyaW9kIGluZGljYXRlZCBieSB0
aGUgcHJpdmF0ZSBrZXkgdXNhZ2UgcGVyaW9kIGV4dGVuc2lvbiBvZiB0aGUgc3RvcmVkIGF0dHJp
YnV0ZSB2YWx1ZSBvciBpZiB0aGVyZSBpcyBubyBwcml2YXRlIGtleSB1c2FnZSBwZXJpb2QgZXh0
ZW5zaW9uIGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOw1nKQlzdWJqZWN0UHVibGljS2V5
QWxnSUQgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUgYWxnb3JpdGhtIGNvbXBvbmVudCBv
ZiB0aGUgYWxnb3JpdGhtSWRlbnRpZmllciBvZiB0aGUgc3ViamVjdFB1YmxpY0tleUluZm9ybWF0
aW9uIGNvbXBvbmVudCBvZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNaCkJa2V5VXNhZ2Ug
bWF0Y2hlcyBpZiBhbGwgb2YgdGhlIGJpdHMgc2V0IGluIHRoZSBwcmVzZW50ZWQgdmFsdWUgYXJl
IGFsc28gc2V0IGluIHRoZSBrZXkgdXNhZ2UgZXh0ZW5zaW9uIGluIHRoZSBzdG9yZWQgYXR0cmli
dXRlIHZhbHVlLCBvciBpZiB0aGVyZSBpcyBubyBrZXkgdXNhZ2UgZXh0ZW5zaW9uIGluIHRoZSBz
dG9yZWQgYXR0cmlidXRlIHZhbHVlOw1pKQlzdWJqZWN0QWx0TmFtZSBtYXRjaGVzIGlmIHRoZSBz
dG9yZWQgYXR0cmlidXRlIHZhbHVlIGNvbnRhaW5zIHRoZSBzdWJqZWN0IGFsdGVybmF0aXZlIG5h
bWUgZXh0ZW5zaW9uIHdpdGggYW4gQWx0TmFtZXMgY29tcG9uZW50IG9mIHRoZSBzYW1lIG5hbWUg
dHlwZSBhcyBpbmRpY2F0ZWQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZTsNaikJcG9saWN5IG1hdGNo
ZXMgaWYgYWxsIG9mIHRoZSBwb2xpY3kgZWxlbWVudHMgaWRlbnRpZmllZCBpbiBvbmUgb2YgdGhl
IHByZXNlbnRlZCB2YWx1ZXMgYXJlIGNvbnRhaW5lZCBpbiB0aGUgc2V0IG9mIHBvbGljeUVsZW1l
bnRJZHMgaW4gYW55IG9mIHRoZSBwb2xpY3lJbmZvcm1hdGlvbiB2YWx1ZXMgaW4gdGhlIGNlcnRp
ZmljYXRlIHBvbGljaWVzIGV4dGVuc2lvbiBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsg
IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZXJlIGlzIG5vIGNlcnRpZmljYXRlIHBvbGljaWVzIGV4
dGVuc2lvbiBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNaykJcGF0aFRvTmFtZSBtYXRj
aGVzIHVubGVzcyB0aGUgY2VydGlmaWNhdGUgaGFzIGEgbmFtZSBjb25zdHJhaW50cyBleHRlbnNp
b24gd2hpY2ggaW5oaWJpdHMgdGhlIGNvbnN0cnVjdGlvbiBvZiBhIGNlcnRpZmljYXRpb24gcGF0
aCB0byB0aGUgcHJlc2VudGVkIG5hbWUgdmFsdWUuDTEyLjcuMwlDZXJ0aWZpY2F0ZSBwYWlyIGV4
YWN0IG1hdGNoDVRoZSBjZXJ0aWZpY2F0ZSBwYWlyIGV4YWN0IG1hdGNoIHJ1bGUgY29tcGFyZXMg
Zm9yIGVxdWFsaXR5IGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmlidXRlIHZhbHVlIG9m
IHR5cGUgQ2VydGlmaWNhdGVQYWlyLiBJdCB1bmlxdWVseSBzZWxlY3RzIGEgc2luZ2xlIGNyb3Nz
LWNlcnRpZmljYXRlIHBhaXIuDWNlcnRpZmljYXRlUGFpckV4YWN0TWF0Y2ggTUFUQ0hJTkctUlVM
RQk6Oj0JewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZVBhaXJFeGFjdEFzc2VydGlvbgsJSUQJCQlpZC1t
ci1jZXJ0aWZpY2F0ZVBhaXJFeGFjdE1hdGNoIH0NQ2VydGlmaWNhdGVQYWlyRXhhY3RBc3NlcnRp
b24gOjo9IFNFUVVFTkNFIHsNCWZvcndhcmRBc3NlcnRpb24gCVswXSBDZXJ0aWZpY2F0ZUV4YWN0
QXNzZXJ0aW9uIE9QVElPTkFMLA0JcmV2ZXJzZUFzc2VydGlvbiAJWzFdIENlcnRpZmljYXRlRXhh
Y3RBc3NlcnRpb24gT1BUSU9OQUwgfQ0JKCBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIGZvcndhcmRB
c3NlcnRpb24gUFJFU0VOVH0gfA0JICBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIHJldmVyc2VBc3Nl
cnRpb24gUFJFU0VOVH0gKQ1UaGlzIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlmIHRoZSBj
b21wb25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIGZvcndhcmRBc3NlcnRpb24gYW5kIHJl
dmVyc2VBc3NlcnRpb24gY29tcG9uZW50cyBvZiB0aGUgcHJlc2VudGVkIHZhbHVlIG1hdGNoIHRo
ZSBjb3JyZXNwb25kaW5nIGNvbXBvbmVudHMgb2YgdGhlIGZvcndhcmQgYW5kIHJldmVyc2UgY29t
cG9uZW50cywgcmVzcGVjdGl2ZWx5LCBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZS4NMTIu
Ny40CUNlcnRpZmljYXRlIHBhaXIgbWF0Y2gNVGhlIGNlcnRpZmljYXRlIHBhaXIgbWF0Y2ggcnVs
ZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1ZSBvZiB0
eXBlIENlcnRpZmljYXRlUGFpci4gSXQgc2VsZWN0cyBvbmUgb3IgbW9yZSBjcm9zcy1jZXJ0aWZp
Y2F0ZSBwYWlycyBvbiB0aGUgYmFzaXMgb2YgdmFyaW91cyBjaGFyYWN0ZXJpc3RpY3Mgb2YgZWl0
aGVyIHRoZSBmb3J3YXJkIG9yIHJldmVyc2UgY2VydGlmaWNhdGUgb2YgdGhlIHBhaXIuDWNlcnRp
ZmljYXRlUGFpck1hdGNoIE1BVENISU5HLVJVTEUgOjo9CXsLCVNZTlRBWAkJQ2VydGlmaWNhdGVQ
YWlyQXNzZXJ0aW9uCwlJRAkJCWlkLW1yLWNlcnRpZmljYXRlUGFpck1hdGNoIH0NQ2VydGlmaWNh
dGVQYWlyQXNzZXJ0aW9uIDo6PSBTRVFVRU5DRSB7DQlmb3J3YXJkQXNzZXJ0aW9uIAlbMF0gQ2Vy
dGlmaWNhdGVBc3NlcnRpb24gT1BUSU9OQUwsDQlyZXZlcnNlQXNzZXJ0aW9uIAlbMV0gQ2VydGlm
aWNhdGVBc3NlcnRpb24gT1BUSU9OQUwgfQ0JKCBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIGZvcndh
cmRBc3NlcnRpb24gUFJFU0VOVH0gfA0JICBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIHJldmVyc2VB
c3NlcnRpb24gUFJFU0VOVH0gKQ1UaGlzIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlmIGFs
bCBvZiB0aGUgY29tcG9uZW50cyB0aGF0IGFyZSBwcmVzZW50IGluIHRoZSBmb3J3YXJkQXNzZXJ0
aW9uIGFuZCByZXZlcnNlQXNzZXJ0aW9uIGNvbXBvbmVudHMgb2YgdGhlIHByZXNlbnRlZCB2YWx1
ZSBtYXRjaCB0aGUgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBmb3J3YXJkIGFuZCBy
ZXZlcnNlIGNvbXBvbmVudHMsIHJlc3BlY3RpdmVseSwgaW4gdGhlIHN0b3JlZCBhdHRyaWJ1dGUg
dmFsdWUsIHVzaW5nIHRoZSBydWxlcyBnaXZlbiBpbiAxMi43LjIuDTEyLjcuNQlDZXJ0aWZpY2F0
ZSBsaXN0IGV4YWN0IG1hdGNoDVRoZSBjZXJ0aWZpY2F0ZSBsaXN0IGV4YWN0IG1hdGNoIHJ1bGUg
Y29tcGFyZXMgZm9yIGVxdWFsaXR5IGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmlidXRl
IHZhbHVlIG9mIHR5cGUgQ2VydGlmaWNhdGVMaXN0LiBJdCB1bmlxdWVseSBzZWxlY3RzIGEgc2lu
Z2xlIENSTC4NY2VydGlmaWNhdGVMaXN0RXhhY3RNYXRjaCBNQVRDSElORy1SVUxFCTo6PQl7CwlT
WU5UQVgJCUNlcnRpZmljYXRlTGlzdEV4YWN0QXNzZXJ0aW9uCwlJRAkJCWlkLW1yLWNlcnRpZmlj
YXRlTGlzdEV4YWN0TWF0Y2ggfQ1DZXJ0aWZpY2F0ZUxpc3RFeGFjdEFzc2VydGlvbiA6Oj0gU0VR
VUVOQ0Ugew0JaXNzdWVyCQkJTmFtZSwNCXRoaXNVcGRhdGUJCVVUQ1RpbWUsDQlkaXN0cmlidXRp
b25Qb2ludAlEaXN0cmlidXRpb25Qb2ludE5hbWUgT1BUSU9OQUwgfQ1UaGUgcnVsZSByZXR1cm5z
IFRSVUUgaWYgdGhlIGNvbXBvbmVudHMgaW4gdGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUgbWF0
Y2ggdGhvc2UgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZS4gSWYgdGhlIGRpc3RyaWJ1dGlvblBvaW50
IGNvbXBvbmVudCBpcyBwcmVzZW50IHRoZW4gaXQgbXVzdCBtYXRjaCBpbiBhdCBsZWFzdCBvbmUg
bmFtZSBmb3JtLg0xMi43LjYJQ2VydGlmaWNhdGUgbGlzdCBtYXRjaA1UaGUgY2VydGlmaWNhdGUg
bGlzdCBtYXRjaCBydWxlIGNvbXBhcmVzIGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmli
dXRlIHZhbHVlIG9mIHR5cGUgQ2VydGlmaWNhdGVMaXN0LiBJdCBzZWxlY3RzIG9uZSBvciBtb3Jl
IENSTHMgb24gdGhlIGJhc2lzIG9mIHZhcmlvdXMgY2hhcmFjdGVyaXN0aWNzLg1jZXJ0aWZpY2F0
ZUxpc3RNYXRjaCBNQVRDSElORy1SVUxFIDo6PSB7DQlTWU5UQVgJQ2VydGlmaWNhdGVMaXN0QXNz
ZXJ0aW9uCwlJRAkJaWQtbXItY2VydGlmaWNhdGVMaXN0TWF0Y2ggfQ1DZXJ0aWZpY2F0ZUxpc3RB
c3NlcnRpb24gOjo9IFNFUVVFTkNFIHsNCWlzc3VlcgkJCU5hbWUJT1BUSU9OQUwsDQltaW5DUkxO
dW1iZXIJCVswXQlDUkxOdW1iZXIJT1BUSU9OQUwsCwltYXhDUkxOdW1iZXIJCVsxXQlDUkxOdW1i
ZXIJT1BUSU9OQUwsCwlyZWFzb25GbGFncwkJUmVhc29uRmxhZ3MJT1BUSU9OQUwsCwlkYXRlQW5k
VGltZQkJVVRDVGltZQlPUFRJT05BTCwNCWRpc3RyaWJ1dGlvblBvaW50CQlbMl0JRGlzdHJpYnV0
aW9uUG9pbnROYW1lIE9QVElPTkFMIH0NVGhlIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlm
IGFsbCBvZiB0aGUgY29tcG9uZW50cyB0aGF0IGFyZSBwcmVzZW50IGluIHRoZSBwcmVzZW50ZWQg
dmFsdWUgbWF0Y2ggdGhlIGNvcnJlc3BvbmRpbmcgY29tcG9uZW50cyBvZiB0aGUgc3RvcmVkIGF0
dHJpYnV0ZSB2YWx1ZSwgYXMgZm9sbG93czoNYSkJaXNzdWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVl
IG9mIHRoaXMgY29tcG9uZW50IGluIHRoZSBhdHRyaWJ1dGUgdmFsdWUgZXF1YWxzIHRoYXQgaW4g
dGhlIHByZXNlbnRlZCB2YWx1ZTsNYikJbWluQ1JMTnVtYmVyIG1hdGNoZXMgaWYgaXRzIHZhbHVl
IGlzIGxlc3MgdGhhbiBvciBlcXVhbCB0byB0aGUgdmFsdWUgaW4gdGhlIENSTCBudW1iZXIgZXh0
ZW5zaW9uIG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOyB0aGVyZSBpcyBubyBtYXRjaCBp
ZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBubyBDUkwgbnVtYmVyIGV4dGVu
c2lvbjsNYykJbWF4Q1JMTnVtYmVyIG1hdGNoZXMgaWYgaXRzIHZhbHVlIGlzIGdyZWF0ZXIgdGhh
biBvciBlcXVhbCB0byB0aGUgdmFsdWUgaW4gdGhlIENSTCBudW1iZXIgZXh0ZW5zaW9uIG9mIHRo
ZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOyB0aGVyZSBpcyBubyBtYXRjaCBpZiB0aGUgc3RvcmVk
IGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBubyBDUkwgbnVtYmVyIGV4dGVuc2lvbjsNZCkJcmVh
c29uRmxhZ3MgbWF0Y2hlcyBpZiBhbnkgb2YgdGhlIGJpdHMgdGhhdCBhcmUgYXJlIHNldCBpbiB0
aGUgcHJlc2VudGVkIHZhbHVlIGFyZSBhbHNvIHNldCBpbiB0aGUgb25seVNvbWVSZWFzb25zIGNv
bXBvbmVudHMgb2YgdGhlIGlzc3VpbmcgZGlzdHJpYnV0aW9uIHBvaW50IGV4dGVuc2lvbiBvZiB0
aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsgdGhlcmUgaXMgbm8gbWF0Y2ggaWYgdGhlIHN0b3Jl
ZCBhdHRyaWJ1dGUgdmFsdWUgY29udGFpbnMgbm8gaXNzdWluZyBkaXN0cmlidXRpb24gcG9pbnQg
ZXh0ZW5zaW9uOw1lKQlkYXRlQW5kVGltZSBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBpcyBlcXVhbCB0
byBvciBsYXRlciB0aGFuIHRoZSB2YWx1ZSBpbiB0aGUgdGhpc1VwZGF0ZSBjb21wb25lbnQgb2Yg
dGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUgYW5kIGlzIGVhcmxpZXIgdGhhbiB0aGUgdmFsdWUg
aW4gdGhlIG5leHRVcGRhdGUgY29tcG9uZW50IG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVl
OyB0aGVyZSBpcyBubyBtYXRjaCBpZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlu
cyBubyBuZXh0VXBkYXRlIGNvbXBvbmVudDsNZikJZGlzdHJpYnV0aW9uUG9pbnQgbWF0Y2hlcyBp
ZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBhbiBpc3N1aW5nIGRpc3RyaWJ1
dGlvbiBwb2ludCBleHRlbnNpb24gYW5kIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVudCBpbiB0
aGUgcHJlc2VudGVkIHZhbHVlIGVxdWFscyB0aGUgY29ycmVzcG9uZGluZyB2YWx1ZSwgaW4gYXQg
bGVhc3Qgb25lIG5hbWUgZm9ybSwgaW4gdGhhdCBleHRlbnNpb24uDTEyLjcuNwlBbGdvcml0aG0g
aWRlbnRpZmllciBtYXRjaA1UaGUgYWxnb3JpdGhtIGlkZW50aWZpZXIgbWF0Y2ggcnVsZSBjb21w
YXJlcyBmb3IgZXF1YWxpdHkgYSBwcmVzZW50ZWQgdmFsdWUgd2l0aCBhbiBhdHRyaWJ1dGUgdmFs
dWUgb2YgdHlwZSBTdXBwb3J0ZWRBbGdvcml0aG0uIA1hbGdvcml0aG1JZGVudGlmaWVyTWF0Y2gg
TUFUQ0hJTkctUlVMRQk6Oj0gICB7CwlTWU5UQVgJCUFsZ29yaXRobUlkZW50aWZpZXILCUlECQkJ
aWQtbXItYWxnb3JpdGhtSWRlbnRpZmllck1hdGNoIH0NVGhlIHJ1bGUgcmV0dXJucyBUUlVFIGlm
IHRoZSBwcmVzZW50ZWQgdmFsdWUgaXMgZXF1YWwgdG8gdGhlIGFsZ29yaXRobUlkZW50aWZpZXIg
Y29tcG9uZW50IG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlLg0xMy4zCUF0dHJpYnV0ZSBD
ZXJ0aWZpY2F0ZSBNYXRjaGluZyBSdWxlDVRoZSBhdHRyaWJ1dGUgY2VydGlmaWNhdGUgbWF0Y2hp
bmcgcnVsZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1
ZSBvZiB0eXBlIEF0dHJpYnV0ZUNlcnRpZmljYXRlLiBUaGlzIG1hdGNoaW5nIHJ1bGVzIGFsbG93
cyBtb3JlIGNvbXBsZXggbWF0Y2hpbmcgdGhhbiB0aGUgY2VydGlmaWNhdGVFeGFjdE1hdGNoLg1h
dHRyaWJ1dGVDZXJ0aWZpY2F0ZU1hdGNoICBNQVRDSElORy1SVUxFICA6Oj0gIHsLCVNZTlRBWAlB
dHRyaWJ1dGVDZXJ0aWZpY2F0ZUFzc2VydGlvbgsJSUQJCWlkLW1yLWF0dHJpYnV0ZUNlcnRpZmlj
YXRlTWF0Y2ggIH0NQXR0cmlidXRlQ2VydGlmaWNhdGVBc3NlcnRpb24gIDo6PSAgU0VRVUVOQ0Ug
IHsLCXN1YmplY3QJWzBdCUNIT0lDRSB7CwkJYmFzZUNlcnRpZmljYXRlSUQJWzBdICBJc3N1ZXJT
ZXJpYWwsCwkJc3ViamVjdE5hbWUJCVsxXSAgR2VuZXJhbE5hbWVzfSBPUFRJT05BTCwLCWlzc3Vl
cgkJWzFdCUdlbmVyYWxOYW1lcyBPUFRJT05BTCwLCWF0dENlcnRWYWxpZAlbMl0JR2VuZXJhbGl6
ZWRUaW1lIE9QVElPTkFMLA0JYXR0VHlwZQlbM10JU0VUIE9GIEF0dHJpYnV0ZVR5cGUgT1BUSU9O
QUx9DZUJQXQgbGVhc3Qgb25lIGNvbXBvbmVudCBvZiB0aGUgc2VxdWVuY2UgbXVzdCBiZSBwcmVz
ZW50DVRoZSBtYXRjaGluZyBydWxlIHJldHVybnMgVFJVRSBpZiBhbGwgb2YgdGhlIGNvbXBvbmVu
dHMgdGhhdCBhcmUgcHJlc2VudCBpbiB0aGUgcHJlc2VudGVkIHZhbHVlIG1hdGNoIHRoZSBjb3Jy
ZXNwb25kaW5nIGNvbXBvbmVudHMgb2YgdGhlIGF0dHJpYnV0ZSB2YWx1ZSwgYXMgZm9sbG93czoN
YSkJYmFzZUNlcnRpZmljYXRlSUQgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUgSXNzdWVy
U2VyaWFsIGNvbXBvbmVudCBvZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNYikJc3ViamVj
dE5hbWUgbWF0Y2hlcyBpZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyB0aGUg
bmFtZSBleHRlbnNpb24gd2l0aCB0aGUgc2FtZSBuYW1lIHR5cGUgYXMgaW5kaWNhdGVkIGluIHRo
ZSBwcmVzZW50ZWQgdmFsdWU7DWMpCWlzc3VlciBtYXRjaGVzIGlmIHRoZSBzdG9yZWQgYXR0cmli
dXRlIHZhbHVlIGNvbnRhaW5zIHRoZSBuYW1lIGNvbXBvbmVudCBvZiB0aGUgc2FtZSBuYW1lIHR5
cGUgYXMgaW5kaWNhdGVkIGluIHRoZSBwcmVzZW50ZWQgdmFsdWU7DWQpCWF0dENlcnRWYWxpZGQg
bWF0Y2hlcyBpZiBpdCBmYWxscyB3aXRoaW4gdGhlIHNwZWNpZmllZCB2YWxpZGl0eSBwZXJpb2Qg
b2YgdGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUuDWUpIAlmb3IgZWFjaCBhdHRUeXBlIGluIHRo
ZSBwcmVzZW50ZWQgdmFsdWUsIHRoZXJlIGlzIGFuIGF0dHJpYnV0ZSBvZiB0aGF0IHR5cGUgcHJl
c2VudCBpbiB0aGUgYXR0cmlidXRlcyBjb21wb25lbnQgb2YgdGhlIHN0b3JlZCB2YWx1ZS4NMTgu
Mi40CVJlYWRlciBhbmQgS2V5IElkZW50aWZpZXIgTWF0Y2hpbmcgUnVsZQ1BIG1hdGNoaW5nIHJ1
bGUgZm9yIGEgbGlzdCBvZiBhdXRob3JpemVkIHJlYWRlcnMgYW5kIHRoZWlyIGFzc29jaWF0ZWQg
a2V5cyBpcyBhcyBmb2xsb3dzOg1yZWFkZXJBbmRLZXlJRE1hdGNoIE1BVENISU5HLVJVTEUgIDo6
PSAgewsJU1lOVEFYCVJlYWRlckFuZEtleUlEQXNzZXJ0aW9uCwlJRAkJaWQtbXItcmVhZGVyQW5k
S2V5SURNYXRjaCAgfQ1SZWFkZXJBbmRLZXlJREFzc2VydGlvbiAgOjo9ICBTRVFVRU5DRSB7DQsJ
a2V5SWRlbnRpZmllcglLZXlJZGVudGlmaWVyLAsJYXV0aFJlYWRlcnMJQXV0aFJlYWRlcnMgT1BU
SU9OQUwgIH0NVGhlIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBhIFRSVUUgaWYgYWxsIG9mIHRoZSBj
b21wb25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZSBtYXRjaCB0
aGUgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBhdHRyaWJ1dGUgdmFsdWUsIGFzIGZv
bGxvd3M6DWEpCWtleUlkZW50aWZpZXIgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUga2V5
SWRlbnRpZmllciBjb21wb25lbnQgb2YgdGhlIFByb3RlY3RlZEtleSBpbiB0aGUgc3RvcmVkIGF0
dHJpYnV0ZSB2YWx1ZTsNYikJaWYgcHJlc2VudCB0aGUgYXV0aFJlYWRlcnMgbWF0Y2hlcyBpZiBp
dCBpcyBlcXVhbCB0byBvbmUgb2YgdGhlIG5hbWVzIGluIHRoZSBhdXRoUmVhZGVycyBjb21wb25l
bnQgb2YgdGhlIFByb3RlY3RlZEtleSBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZS4NDQ0N
DQ0NDQ0NDQ0NUmVmLg1uby4HTWF0Y2hpbmcgUnVsZQdEB0FDUCAxMzMHTm90ZXMNKG15IHJlY29t
bWVuZGVkIG9yZGVyIGZvciBzdXBwb3J0ICNuKQcHMS4HYWxnb3JpdGhtSWRlbnRpZmllck1hdGNo
B28HbQcjMQcHMi4HYXR0cmlidXRlQ2VydGlmaWNhdGVNYXRjaAdvB20HIzYHBzMuB2F0dHJpYnV0
ZUludGVncml0eU1hdGNoB28HbwcHBzQuB2NlcnRpZmljYXRlRXhhY3RNYXRjaAdvB28HBwc1Lgdj
ZXJ0aWZpY2F0ZUxpc3RFeGFjdE1hdGNoB28HbQcjNQcHNi4HY2VydGlmaWNhdGVMaXN0TWF0Y2gH
bwdtByM0Bwc3LgdjZXJ0aWZpY2F0ZU1hdGNoB28HbQcjMgcHOC4HY2VydGlmaWNhdGVQYWlyRXhh
Y3RNYXRjaAdvB28HBwc5LgdjZXJ0aWZpY2F0ZVBhaXJNYXRjaAdvB20HIzMHBzEwLgdyZWFkZXJB
bmRLZXlJRE1hdGNoB28HbQdDb25kaXRpb25hbCBvbiBzdXBwb3J0IG9mIHRoZSBlbmNyeXB0ZWQg
dmFyaWFudCBvZiBhdHRyaWJ1dGVzIGFzIGRlc2NyaWJlZCBpbiBQYXJhIDQwOCBvZiBBQ1AgMTMz
DSM3BwcNDQ0NVGFibGUgZnJvbSBBQ1AgMTMzLCBBbm5leCBEIC0gVGFibGUgRC0xNS4NDVBsZWFz
ZSBub3RlIHRoYXQgaXQgaXNuknQgdmFsaWQgZm9yIGEgRFNBIHRvIGJlIGFibGUgdG8gbWF0Y2gg
YXNzZXJ0aW9ucywgdW5sZXNzIHRoZSBjbGllbnRzIGNhbiBhc3NlcnQgdGhlIG1hdGNoIGNyaXRl
cmlhLg3QzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA7AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAABAAAA
AAAAAAAQAAACAAAAAQAAAP7///8AAAAAAAAAAP//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////8FAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0
AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAP///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADgAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPtsvAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAhjMCGQDqvAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAGKYxQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDYuMAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAAgAAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQzxHgobEa4QAAAAAAAAAAAAAAAAAA
AAA7AAMA/v8JAP//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////AAMAAFkDAADBAwAAzAMAAM4DAADdAwAA3wMAAO4DAAD0
AwAABgQAABUEAAAWBAAAngQAAKkEAADUBAAA1QQAABQGAAAVBgAAhAYAAI8GAADdBgAA3gYAAC4L
AAA6CwAAoAsAAKYLAAAMDAAAIAwAAOsMAAABDQAAKA4AADgOAACbDgAAqg4AAIsPAACgDwAAvw8A
AMgPAADaDwAA7g8AAPUPAAAQEAAAPRAAAEUQAAALEQAAGREAAHgRAACAEQAAyREAAM8RAAA8EgAA
TBIAAFsSAABsEgAAHBMAACYTAABOFAAAXRQAAJMUAACUFAAAaxYAAHsWAACAFgAAkBYAAN0WAADk
FgAA6RYAAPAWAAApFwAAKhcAAKMXAACyFwAARBgAAEUYAAAFGgAAFRoAABoaAAAqGgAAdxoAAH4a
AACDGgAAihoAAOQaAADlGgAAdxsAAIYbAACpGwAAqhsAAB8dAAAwHQAAcx0AAHQdAADtHQAA/B0A
AGggAABpIAAAAP328Pb99v32/QD99v0A/QD99v0A/fb99v32/fb99v32/fb99v32/fb99v32/fb9
9v32/fb99v32/QD99v32/fb99v0A/fb9AP32/fb99v32/QD99v0A/fb9AP32/QAACl0DAGMSAEkB
AAEADFWBXQMAYxIASQEAAQAESQEAAV9pIAAAbCAAAHIgAADYIAAA5CAAAK0hAAC5IQAAhSIAAJAi
AADoIgAA9yIAALMjAAC+IwAA/yMAAAkkAABXJAAAYSQAAMckAADRJAAA4CQAAPEkAABcJgAAbiYA
AHAmAABxJgAAIScAADQnAABdJwAAhycAAAAoAAA6KAAATygAAFEoAAABKQAACCkAAAkpAAANKQAA
LikAAC8pAABPKQAAUCkAAFEpAABYKQAAXCkAAF0pAABeKQAAZykAAHEpAAB9KQAAgSkAAIIpAACO
KQAA4ykAAOQpAADlKQAAHSoAAB4qAADEKgAAxSoAAMgqAADZKgAA+CoAAAQrAAAxKwAAPCsAAL8r
AADFKwAARiwAAFMsAABzLAAAfSwAAKssAAC5LAAAwCwAAAstAAAWLQAAvi0AAJcuAABDLwAAUC8A
AG8vAAB8LwAAji8AAJovAADMLwAA1i8AANcvAAAKMAAAFTAAACcwAAAzMAAA/fb99v32/fb99v32
/fb99v32/fb99v0A/fb9AP0A9AD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A8ez9AP32/fb99v32/ef9
AP0A9AD0AOUA5wDnAPQA9ucA5wD0AAAAAANQFgAIVYFdAwBjEgAACFWBVoFJAQABAARVgVaBAAJV
gQAMVYFdAwBjEgBJAQABAARJAQABWjMwAABfMAAAsDAAAMgwAADUMAAA7TAAADkxAABSMQAAXjEA
AHIxAACaMQAAszEAAL0xAADRMQAA2TEAANoxAABcMgAABzMAAAD9+v36/fr9+v36/fr99/0AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAABVAWAFWBBEkBAAEAA1AWAAARAAMAAFgDAABZAwAAbQMAABYEAAA1BAAA1QQAAEYFAACoBQAA
FQYAAC4GAADeBgAAQAcAAGUJAACDCgAAKwsAAJ0LAAAJDAAA6AwAACUOAACYDgAAiA8AADoQAAAI
EQAAxhEAABkTAAC8EwAA4BMAAJQUAAARFQAAPhUAAHkVAAC1FQAA6xUAACEWAAAqFwAASBcAAEUY
AACzGAAA2xgAABEZAABIGQAAfhkAAP0AAsAhCAH7AAHAIQgB+wABwCEIAfkAAsAh8AD3AAHAIfAA
+QACwCHwAPMAA8Ah2ADzAAPAIdgA+QACwCHwAPcAAcAh8AD5AALAIfAA8wADwCHYAPMADMAh2ADz
AAvAIdgA8QACwCHwAO8AAsAh8ADvAALAIfAA7wADwCHwAO8ABMAh8ADvAALAIfAA7wADwCHwAO8A
A8Ah8ADvAAPAIfAA7wADwCHwAO8ABMAh8ADvAALAIfAA9wABwCHwAPkAAsAh8ADzAAPAIdgA8wAB
wCHYAO0AAcAh2ADtAAHAIdgA7QABwCHYAO0AAcAh2AD5AAPAIfAA9wABwCHwAPkAA8Ah8ADzAAPA
IdgA8wABwCHYAO0AAcAh2ADtAAHAIdgA7QABwCHYAAAAAAAAAAAAAREAAAEPAAABAAAAAxAAEAoA
AAABBAAAARMAAAECAAACAgAFACp+GQAAtBkAAOUaAAAJGwAAqhsAACccAABUHAAAZBwAAHocAACu
HAAAdB0AAJIdAABDHgAAbB4AAK8eAADXHgAA8B4AAIIfAAC7HwAAaSAAANUgAACqIQAAgiIAALAj
AADdJAAAziUAAPAlAABxJgAA5CYAAF4nAACHJwAAUSgAANAoAAC5KQAA5SkAAB4qAADFKgAALisA
ALwrAABDLAAArCwAADUtAABkLQAA/gABwCHYAPwAA8Ah8AD6AAHAIfAA/AACwCHwAPYAA8Ah2AD2
AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/AACwCHwAPoAAcAh8AD0AALAIfAA9gABwCHYAP4A
AsAh2AD2AAHAIdgA/gABwCHYAP4ABMAh2AD+AAHAIdgA/AACwCHwAPIAAsAh8ADyAAPAIfAA8gAD
wCHwAPIABMAh8ADyAATAIfAA8gADwCHwAPoAAcAh8AD8AALAIfAA9gADwCHYAPwAAsAh8ADwAAHA
IQgB/AACwCHwAO4AA8Ah2ADuAAbAIdgA/gABwCHYAOwAAcAh3QD8AALAIfAA8gACwCHwAPIAAsAh
8ADyAALAIfAA8gACwCHwAPIAAsAh8ADpAAHAISABAgkABQAAARQAAAEQAAABAgAAAQ8AAAESAAAD
EAAQCgAAAAEEAAABEwAAAREAKmQtAAC+LQAAKi4AAFMuAACXLgAAQC8AALovAABTMAAAVDAAAFUw
AABWMAAAVzAAAFgwAABZMAAAWjAAAFswAABcMAAAXTAAAF4wAABfMAAAZDAAAGgwAAB2MAAAeDAA
AIAwAACGMAAArDAAAK0wAACwMAAAyTAAAMswAADNMAAA0DAAANEwAADUMAAA7jAAAPAwAADyMAAA
9TAAAPYwAAD5MAAA/gABwCHwAPwAA8Ah3QD8AAHAId0A/AADwCHdAP4AAsAh8AD6AALAIfAA+gAC
wCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPoAAcAh8AD6AAHA
IfAA+gABwCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPQAAYoB3QD0AAGKAd0A9AABSw3dAPQAAUQB
3QD0AAKsAt0A9AAByxHdAPQAAcsR3QDgAAHLEd0A9AABigHdAPQAAUsN3QD0AAFEAd0A9AABrALd
APQAAcsR3QDgAAHLEd0A9AABigHdAPQAAUsN3QD0AAFEAd0A9AABrALdAPQAAcsR3QDgAAHLEd0A
9AABigHdAAAAAAATAAAYARkBuGwAuwoACgAKAAoACQAJAL4OAAUU+3b9mgu2DToR3CMABRQAEAAA
EQAAGAEAARUAAAEUAAABEwAo+TAAABExAAATMQAAFTEAABYxAAAXMQAAGjEAADAxAAAyMQAANDEA
ADUxAAA2MQAAOTEAAFMxAABVMQAAVzEAAFoxAABbMQAAXjEAAHMxAAB1MQAAdzEAAHoxAAB7MQAA
fjEAAI8xAACRMQAAkzEAAJYxAACXMQAAmjEAALQxAAC2MQAAuDEAALkxAAC6MQAAvTEAANIxAADU
MQAA1jEAANkxAADaMQAA+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A
+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6
AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYA
AcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gAB
Sw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGs
At0A+gAByxHdAOYAAcsR3QAAAAAAABMAABgBGQG4bAC7CgAKAAoACgAJAAkAvg4ABRT7dv2aC7YN
OhHcIwAFFAAQAAARAAAYASnaMQAA3jEAAPIxAAD0MQAA9jEAAFgyAABbMgAAXDIAAF0yAABeMgAA
XzIAAGAyAACKMgAAizIAAAczAAD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gACyxHdAPoA
AcsR3QDmAAHLEd0A5AABwCHwAOQAAcAh8ADkAAHAIfAA5AABwCHwAOQAAcAh8ADkAAHAIfAA5AAC
wCHwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAAEwAAGAEZAbhsALsKAAoACgAKAAkACQC+DgAFFPt2/ZoLtg06
EdwjAAUUABAAABEAABgBDg4AFwAIAAEASwAPAAAAAAAaAABA8f8CABoABk5vcm1hbAACAAAAAwBh
CQQALgABQAEAAgAuAAlIZWFkaW5nIDEAAAoAAQAIARXwABY8AAsAVYFdAgBjHABrHAAASgACQAEA
AgBKAA5IZWFkaW5nIDIsMixsMQAhAAIABQMHAQgBERoDE+b8FTkBDw4ABBoDpwQ0BsEHAAAAAAAL
AFWBXQQAYQkIYxYAACgAA0ABAAIAKAAJSGVhZGluZyAzAAAKAAMACAEV8AAWPAAFAFWBYxgAAEgA
BEAxAAIASAAOSGVhZGluZyA0LDQsbDMAIgAEAAUDBwERGgMT5vwVtQAWAAAPDgAEGgOnBDQGwQcA
AAAACQBdBABhCQhjFAAAAAAAAAAAAAAwAAlAEQACADAACUhlYWRpbmcgOQAADAAJAAUBBwEV4AEW
AAAMAF0EAGEJCGMYAGsAACIAQUDy/6EAIgAWRGVmYXVsdCBQYXJhZ3JhcGggRm9udAAAAAAAAAAA
AAAAOgD+TwEA8gA6AAhlbnVtbGV2MQAdAA8ABQMRpwQTc/4VVgAPDgAEGgOnBDQGwQcAAAAAAAYA
XQQAYQkIRAD+TwEAEgFEAAVBU04uMQAAJAAQABWIAA8dAAn+Af0DpwQ0BmsIEwtKDQ8QYBQAAAAA
AAAAAAALAFWBXQMAYQkIYxIAACAA/k8BARIBIAALQVNOLjEgQ29udC4AAAUAEQAVAAAAAAAkAP5P
AQACACQAAmxiAA8AEgAFAwgBEA4AFYgAFngAAAMAXQQAADgAQkABADIBOAAJQm9keSBUZXh0AAAa
ABMABQMViAAWeAAPDgAEGgOnBDQGwQcAAAAABgBdBABhCQheAP5PAQBCAV4AA2FzbgAAQwAUAAcB
ECsAEWwCFCT/AAAWeAAPLwAPawKOBLIGHQmIC/MNXhDKEjUVoBcLGnYc4h5NIbgjQEBAQEBAQEBA
QEBAQEBAAAgAVYFdAwBjEgAkAP5PAQBSASQAAmxpAA0AFQAFAxHQAhOY/hZ4AAAFAF0EAGIBABoA
/k+iAGEBGgAKQVNOLjEgV29yZAADAGEABAAAAAAABzAAAAUA/////wAA/////wYABCH//wEAACH/
/wIABCH//wMAACH//wQABCH//wUAACD//wYAAAAAAEYHAAAhEwAAuxwAAB4nAABfLQAABzAAAAAA
PQAAAAEACQEAAAIArgAAAAMApwAAAAQABQAAAAUAAAAAAAAAAADQJQAAHicAAC4oAAC8KAAAQykA
AJcrAAAHMAAAmgAUAJoAFACaABMAmgATAJoAEwCaABQABgAAAAADAABpIAAAMzAAAAczAAAaABsA
HAAAAwAAfhkAAGQtAAD5MAAA2jEAAAczAAAdAB4AHwAgACEAIgANU3VlIEEuIE1pa2xvcxFDOlxY
NTAwXE1BVENILkRPQ/9ASFAgTGFzZXJKZXQgNVNpLzVTaSBNWABMUFQyOgBIUDVTSQBIUCBMYXNl
ckpldCA1U2kvNVNpIE1YAAAAAAAAAAAAAAoDNwJEAJABA/cAAAEAAQDAGMASZAABAAcAWAIBAAEA
WAICAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwIBAAAACAAAAAEAA1BYAlgCBgACAAAAAQAAEFdJ
TldPUkQAAAAAAAEAAAAAgAEAAQABAAAAAAAAAAAAAAAAAAABQ291cmllciBOZXcAAAAAAAAAAAAA
AAAAAAAAAAAAAACwBJABAAADACAABwAAACgAAAAIAAEAAgABAAYAAwABAFgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwlMUFQyAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQNVNJ
AAAAAABIUCBMYXNlckpldCA1U2kvNVNpIE1YAAAAAAAAAAAAAAoDNwJEAJABA/cAAAEAAQDAGMAS
ZAABAAcAWAIBAAEAWAICAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwIBAAAACAAAAAEAA1BYAlgC
BgACAAAAAQAAEFdJTldPUkQAAAAAAAEAAAAAgAEAAQABAAAAAAAAAAAAAAAAAAABQ291cmllciBO
ZXcAAAAAAAAAAAAAAAAAAAAAAAAAAACwBJABAAADACAABwAAACgAAAAIAAEAAgABAAYAAwABAFgC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwlMUFQyAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAEhQNVNJAAAAAAABgAEABjAAAAYwAAAJAACAAIAGMAAABQAAAFwvAABlABUWkAEAAFRp
bWVzIE5ldyBSb21hbgAMFpABAgBTeW1ib2wACyaQAQAAQXJpYWwAFiKQAQAKSGVsdmV0aWNhAEFy
aWFsAPIcEpABAAZUaW1lcwBUaW1lcyBOZXcgUm9tYW4AACIABAABCIgYAADQAgAAaAEAAAAAUPMV
puErG2YAAAAABAAbAAAAAAAAAAAAAAAAAAAAAAAEAIMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABZAkEAAAATMTIuNwlNYXRjaGluZyBydWxlcwAAAA1TdWUgQS4gTWlrbG9zDVN1ZSBBLiBNaWts
b3MAAAAAAAAAAAAA0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAAB
AAAAAQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8=

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21795 for ietf-pkix-bks; Thu, 24 Sep 1998 07:59:51 -0700 (PDT)
Received: from always.got.net ([e-mail] [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21791 for <[e-mail]>; Thu, 24 Sep 1998 07:59:50 -0700 (PDT)
Received: from got.net (SantaCruz-x2-3-133.got.net [209.66.100.133]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id IAA22427; Thu, 24 Sep 1998 08:05:37 -0700
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 08:05:20 -0700
From: Michael McNeil <[e-mail]>
Organization: GMT
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Stephen Kent <[e-mail]>, Warwick Ford <[e-mail]>, [e-mail], Jeffrey Schiller <[e-mail]>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
1-831-438-7811


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21579 for ietf-pkix-bks; Thu, 24 Sep 1998 07:25:27 -0700 (PDT)
Received: from bilbo.thawte.com (bilbo.thawte.com [196.25.207.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21575 for <[e-mail]>; Thu, 24 Sep 1998 07:25:14 -0700 (PDT)
Received: from thawte.com (really [196.25.207.2]) by thawte.com via in.smtpd with esmtp id <[e-mail]> (Debian Smail3.2.0.101) for <[e-mail]>; Thu, 24 Sep 1998 16:31:02 +0200 (SAST) 
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 16:26:50 +0200
From: Mark Shuttleworth <[e-mail]>
Reply-To: [e-mail]
Organization: Thawte Consulting
X-Mailer: Mozilla 4.5b2 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: NEW Data type for certificate selection ?
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms78C9DE34404C8A045EF33A31"
Sender: [e-mail]
Precedence: bulk

This is a cryptographically signed message in MIME format.

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

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

MIIH8AYJKoZIhvcNAQcCoIIH4TCCB90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BhMwggLSMIICO6ADAgECAgItQzANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx
Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2MB4XDTk4MDkxNjE4MzQ1NFoXDTk5MDkxNjE4MzQ1NFowczEVMBMGA1UEBBMMU2h1
dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy
ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq
hkiG9w0BAQEFAANLADBIAkEAw8CXH/zhGBuu9boNBAXbPp+77G8rFuuuzboLsKl5DkqfgmXf
/JOadF3bwNG1QetRQKuEQek4jTNQPqjxdiQo/QIDAQABo3IwcDARBglghkgBhvhCAQEEBAMC
BaAwDgYDVR0PAQH/BAQDAgWgMBwGBStlAQQBBBMwEQIBADAMMAoCAQEEBW1hcmtzMAwGA1Ud
EwEB/wQCMAAwHwYDVR0jBBgwFoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEE
BQADgYEATUOQ3uxrewGzaUVHZZgsul+T2PrBsQMe/Tw2CZO7jjj0EM4ajBLo334y5xJNBtjo
n9SoxhnEhfKo5GQsXgy+Ugb0FxFlrP3d1gMNHzDmg80gxw5JCPuzgN6IQGBXewnxdb2W2tse
Gbo5uJjquMwIggkVMd8Hz2O8uQvIBm1LdZowggM5MIICoqADAgECAgEKMA0GCSqGSIb3DQEB
BAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20w
HhcNOTgwOTE2MTc1NTM0WhcNMDAwOTE1MTc1NTM0WjCBuTELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0
ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1
NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45
LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpeXU1NBfCALuByF9JL+ra44e6yAH
AhWEa4/QkyQfG53uaLK5LE/pk2cXEBceoflDQSO5MKp2l7vz5/2BwLUxi/amUCZU8pUo6xmk
HpcesOK4m8EEmjLQPAlsT+Q1T/B2vwATA09FCGDz/LTQkAGKEsmcun9S6iqTNTY8POQ1LwID
AQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX53
9IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBACzHgh8BQz4Hj+5pXKlkgvjAlq2TK8ubUNdAmoHC
uqZ2nTyVQNxVweFVgnmrCimm1QzhVyg+j/m71d8Nk1iqWy2LjzPk3VgVNXZyFSm9QvRakgt3
X50n25otThuCBo7SjVa7ld7bDGUF3pWeAt1TF76+/GvDGiJ6FCthvcKfXnpaMYIBpTCCAaEC
AQEwgcAwgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcT
C0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhh
d3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNgICLUMwCQYFKw4DAhoFAKB9MBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDkyNDE0MjY1MFowHgYJ
KoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUdte0yJez9q3I
TJRb4V+uB9bopawwDQYJKoZIhvcNAQEBBQAEQDhgTnn8/oGeVEanel2njqWPQsFdd4BaZzO6
6aRt8q/LvBwyO+baEiC25qSgyfF6iOA8AV4l7WDZu5Y/2B6r6Eg=
--------------ms78C9DE34404C8A045EF33A31--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21513 for ietf-pkix-bks; Thu, 24 Sep 1998 07:21:25 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21509 for <[e-mail]>; Thu, 24 Sep 1998 07:21:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02163; Thu, 24 Sep 1998 10:27:24 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Thu, 24 Sep 1998 10:27:24 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail] 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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21495 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:40 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21491 for <[e-mail]>; Thu, 24 Sep 1998 07:20:39 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02093; Thu, 24 Sep 1998 10:26:39 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dcs-00.txt
Date: Thu, 24 Sep 1998 10:26:39 -0400
Sender: [e-mail]
Precedence: bulk

--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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21490 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:35 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21486 for <[e-mail]>; Thu, 24 Sep 1998 07:20:34 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02081; Thu, 24 Sep 1998 10:26:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-00.txt
Date: Thu, 24 Sep 1998 10:26:34 -0400
Sender: [e-mail]
Precedence: bulk

--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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21482 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:10 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21477 for <[e-mail]>; Thu, 24 Sep 1998 07:20:08 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02063; Thu, 24 Sep 1998 10:26:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-11.txt
Date: Thu, 24 Sep 1998 10:26:08 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail] 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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21425 for ietf-pkix-bks; Thu, 24 Sep 1998 07:06:55 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21421 for <[e-mail]>; Thu, 24 Sep 1998 07:06:54 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA09631; Thu, 24 Sep 1998 07:12:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Thu, 24 Sep 1998 09:56:50 -0400
To: "Todd S. Glassey" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Amending the PKIX-WG Charter to reflect the addition of timestamping
Cc: [e-mail]
In-Reply-To: <001c01bde698$615e7640$200ba8c0@tsg-laptop>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
>Warwick Ford <[e-mail]>
>
>Security Area Director(s):
>Jeffrey Schiller <[e-mail]>
>Marcus Leech <[e-mail]>
>
>Security Area Advisor:
>Jeffrey Schiller <[e-mail]>
>
>Mailing Lists:
>General Discussion:[e-mail]
>To Subscribe: [e-mail]
>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 ----
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20975 for ietf-pkix-bks; Thu, 24 Sep 1998 05:50:11 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20971 for <[e-mail]>; Thu, 24 Sep 1998 05:50:10 -0700 (PDT)
Received: 	id IAA22113; Thu, 24 Sep 1998 08:54:41 -0400
Received: by gateway id <S2S6ZMGZ>; Thu, 24 Sep 1998 08:51:16 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: X.509 Documentation
Date: Thu, 24 Sep 1998 08:51:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA20972
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 24, 1998 2:59 PM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	Re: X.509 Documentation
> 
> [e-mail] 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
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20857 for ietf-pkix-bks; Thu, 24 Sep 1998 05:38:06 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20853 for <[e-mail]>; Thu, 24 Sep 1998 05:38:04 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id OAA03085; Thu, 24 Sep 1998 14:44:08 +0200 (CEST)
Received: from stefans (t4o68p1.telia.com [62.20.139.121]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA25911; Thu, 24 Sep 1998 14:44:02 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 24 Sep 1998 14:41:23 +0200
To: [e-mail], [e-mail], [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA20854
Sender: [e-mail]
Precedence: bulk

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                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20658 for ietf-pkix-bks; Thu, 24 Sep 1998 04:54:03 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20654 for <[e-mail]>; Thu, 24 Sep 1998 04:54:02 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id XAA13067; Thu, 24 Sep 1998 23:59:34 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90663837419831>; Thu, 24 Sep 1998 23:59:34 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: basic constraint extension
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 24 Sep 1998 23:59:34 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18001 for ietf-pkix-bks; Thu, 24 Sep 1998 02:51:43 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17997 for <[e-mail]>; Thu, 24 Sep 1998 02:51:41 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA09608; Thu, 24 Sep 1998 11:59:00 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA15648; Thu, 24 Sep 1998 11:59:08 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 11:59:24 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: X.509 Documentation
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

[e-mail] 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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17852 for ietf-pkix-bks; Thu, 24 Sep 1998 02:21:50 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17848 for <[e-mail]>; Thu, 24 Sep 1998 02:21:47 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA12895; Thu, 24 Sep 1998 11:28:09 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA16688; Thu, 24 Sep 1998 11:27:58 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 11:28:15 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Michael McNeil <[e-mail]>
CC: Stephen Kent <[e-mail]>, Warwick Ford <[e-mail]>, [e-mail], Jeffrey Schiller <[e-mail]>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
> [e-mail]
> 1-831-438-7811





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17767 for ietf-pkix-bks; Thu, 24 Sep 1998 02:05:52 -0700 (PDT)
Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17763 for <[e-mail]>; Thu, 24 Sep 1998 02:05:50 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo26.mx.aol.com (IMOv16.10) id 7HBDa02301 for <[e-mail]>; Thu, 24 Sep 1998 05:11:36 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 05:11:36 EDT
To: [e-mail]
Mime-Version: 1.0
Subject: X.509 Documentation
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 224
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29806 for ietf-pkix-bks; Wed, 23 Sep 1998 20:33:18 -0700 (PDT)
Received: from always.got.net ([e-mail] [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29799 for <[e-mail]>; Wed, 23 Sep 1998 20:33:17 -0700 (PDT)
Received: from got.net (SantaCruz-x2-3-133.got.net [209.66.100.133]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id UAA17148; Wed, 23 Sep 1998 20:39:22 -0700
Message-ID: <[e-mail]>
Date: Wed, 23 Sep 1998 20:39:10 -0700
From: Michael McNeil <[e-mail]>
Organization: GMT
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, Warwick Ford <[e-mail]>
CC: [e-mail], Jeffrey Schiller <[e-mail]>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
1-831-438-7811


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24408 for ietf-pkix-bks; Wed, 23 Sep 1998 11:00:10 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA24404 for <[e-mail]>; Wed, 23 Sep 1998 11:00:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Wed, 23 Sep 1998 11:05:32 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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

--Paul Hoffman, Director
--Internet Mail Consortium

>To: IETF-Announce: ;
>Cc: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
>Date: Wed, 23 Sep 1998 10:43:01 -0400
>Sender: [e-mail]
>
>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:	[e-mail].  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:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-tls-ac509prof-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22037 for ietf-pkix-bks; Wed, 23 Sep 1998 06:57:39 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22033 for <[e-mail]>; Wed, 23 Sep 1998 06:57:37 -0700 (PDT)
Received: 	id KAA28894; Wed, 23 Sep 1998 10:01:06 -0400
Received: by gateway id <S2S6Z20Q>; Wed, 23 Sep 1998 09:57:44 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Steve Kent'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>
Subject: Revised LDAPv2 specs have been submitted
Date: Wed, 23 Sep 1998 09:57:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21064 for ietf-pkix-bks; Wed, 23 Sep 1998 04:29:19 -0700 (PDT)
Received: from maila.telia.com ([e-mail] [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21060 for <[e-mail]>; Wed, 23 Sep 1998 04:29:00 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id NAA12330; Wed, 23 Sep 1998 13:35:13 +0200 (CEST)
Received: from stefans (t4o68p71.telia.com [62.20.139.191]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA26921; Wed, 23 Sep 1998 13:35:09 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 23 Sep 1998 13:32:27 +0200
To: Al Arsenault <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PKIX Roadmap
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA21061
Sender: [e-mail]
Precedence: bulk

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.
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17883 for ietf-pkix-bks; Wed, 23 Sep 1998 00:56:18 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17879 for <[e-mail]>; Wed, 23 Sep 1998 00:56:16 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA15024 for <[e-mail]>; Wed, 23 Sep 1998 10:03:30 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA17156 for <[e-mail]>; Wed, 23 Sep 1998 10:03:37 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 23 Sep 1998 10:03:55 -0700
From: Denis Pinkas <[e-mail]>
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Archive cutoff & Retention period
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17850 for ietf-pkix-bks; Wed, 23 Sep 1998 00:52:30 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17846 for <[e-mail]>; Wed, 23 Sep 1998 00:52:25 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA04146 for <[e-mail]>; Wed, 23 Sep 1998 09:59:15 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA12434 for <[e-mail]>; Wed, 23 Sep 1998 09:59:22 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 23 Sep 1998 09:59:40 -0700
From: Denis Pinkas <[e-mail]>
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Minor comments on OCSP-06
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02987 for ietf-pkix-bks; Tue, 22 Sep 1998 19:13:48 -0700 (PDT)
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.120.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02983 for <[e-mail]>; Tue, 22 Sep 1998 19:13:47 -0700 (PDT)
Received: from tsg-laptop (1Cust96.tnt4.sfo1.da.uu.net [208.250.191.96]) by avocet.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id TAA10448 for <[e-mail]>; Tue, 22 Sep 1998 19:20:08 -0700 (PDT)
From: "Todd S. Glassey" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: Amending the PKIX-WG Charter to reflect the addition of timestamping
Date: Tue, 22 Sep 1998 19:17:57 -0700
Message-ID: <001c01bde698$615e7640$200ba8c0@tsg-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
Warwick Ford <[e-mail]>

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

Security Area Advisor:
Jeffrey Schiller <[e-mail]>

Mailing Lists:
General Discussion:[e-mail]
To Subscribe: [e-mail]
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 ----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25907 for ietf-pkix-bks; Tue, 22 Sep 1998 05:29:18 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA25903 for <[e-mail]>; Tue, 22 Sep 1998 05:29:16 -0700 (PDT)
Received: 	id IAA16369; Tue, 22 Sep 1998 08:31:45 -0400
Received: by gateway id <S2S6Z1VK>; Tue, 22 Sep 1998 08:28:25 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Steve Kent'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Subject: text for attributes
Date: Tue, 22 Sep 1998 08:28:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25745 for ietf-pkix-bks; Tue, 22 Sep 1998 05:13:14 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA25741 for <[e-mail]>; Tue, 22 Sep 1998 05:13:13 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA15055; Tue, 22 Sep 1998 05:17:57 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 22 Sep 1998 08:15:43 -0400
To: Stefan Santesson <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: PKIX Roadmap
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA25513 for ietf-pkix-bks; Tue, 22 Sep 1998 04:31:33 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA25509 for <[e-mail]>; Tue, 22 Sep 1998 04:31:31 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA78840; Tue, 22 Sep 1998 13:36:57 +0200
Received: by HYDRA with Microsoft Mail id <01BDE62D.342F16E0@HYDRA>; Tue, 22 Sep 1998 13:30:45 +0200
Message-ID: <01BDE62D.342F16E0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: OCSP - Public Key Dstribution
Date: Tue, 22 Sep 1998 13:30:44 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA25221 for ietf-pkix-bks; Tue, 22 Sep 1998 03:35:04 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA25217 for <[e-mail]>; Tue, 22 Sep 1998 03:35:01 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA28659; Tue, 22 Sep 1998 11:28:34 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Tue, 22 Sep 1998 11:26:49 +0200
From: "Petra Glöckner" <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: basic constraint extension
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6C21A3596B2679A5F64C275F"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
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

MIIO7wYJKoZIhvcNAQcCoIIO4DCCDtwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DVcwggMFMIICbqADAgECAgIC8zANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJERTEMMAoG
A1UEChMDR01EMR8wHQYDVQQLExZDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTMTgwNgYDVQQLEy9U
cnVzdEZhY3RvcnkgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENlcnRpZmljYXRlczAeFw05ODA3
MTMxNzQ2NDlaFw0wMDAxMDEwMDAwMDBaMGYxCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNHTUQx
LzAtBgkqhkiG9w0BCQEWIFBldHJhLkdsb2Vja25lckBkYXJtc3RhZHQuZ21kLmRlMRgwFgYD
VQQDEw9QZXRyYSBHbG9lY2tuZXIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwgqVtX54BPIm
LAu+u8i7lnOV6lf+79amGCL9Ao5UOStKuLHC2dwH7MP5A8gPVeeiP1kk2tr9hXJmIVDYP7kS
cQIDAQABo4H1MIHyMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgCwMIHRBglghkgBhvhC
AQ0EgcMWgcBDQVVUSU9OOiBUaGUgRGlnaXRhbCBJRCBzdWJqZWN0cyBvZiBJQ0UtVEVMCkNs
YXNzIDAgVHJpYWwgU2VydmljZXMgYXJlIG5vdCBhdXRoZW50aWNhdGVkLgpJdCBtYXkgYmUg
dGhlIGhvbGRlcidzIHJlYWwgbmFtZSBvciBhbiBhbGlhcy4KVXNlIHRoaXMgRGlnaXRhbCBJ
RCBmb3IgdGVzdCBwdXJwb3NlZCBvbmx5LgooYykgR01EIDE5OTcwDQYJKoZIhvcNAQEEBQAD
gYEASgeR+7xR+g2YPSXpdAojcDD1jeo2sMa1hyspawERPfLgagUDcaX5MS/TjYZ8K3lz3Tve
G6U0pWPwRBtAnns/A8hoNApONSQEXupnhNgaRwljFEXm+shdanA33iZKfs6NVCnb1Mbs96pK
xUgpXw4TRe//afL0nNiaRCmSfXohytgwggOhMIIDCqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MGcxCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNHTUQxHzAdBgNVBAsTFkNMQVNTIDAgVFJJQUwg
U0VSVklDRVMxKTAnBgNVBAsTIFRydXN0RmFjdG9yeSBEaWdpdGFsIElEIFNlcnZpY2VzMB4X
DTk3MTIxNzA4MDMyNloXDTAwMDEwMTAwMDAwMFowdjELMAkGA1UEBhMCREUxDDAKBgNVBAoT
A0dNRDEfMB0GA1UECxMWQ0xBU1MgMCBUUklBTCBTRVJWSUNFUzE4MDYGA1UECxMvVHJ1c3RG
YWN0b3J5IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDZXJ0aWZpY2F0ZXMwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBANQJUsDpSSmA85HJLPHj4jDUTWXPUwYaqNvA3r3AdhFqIacLQwtn
FOoMR4CZqaewurOWI23kw2NK4/2I+GdTwkk5aEYAo4eA9FFwHBxq+b80xbO4ymTKxkah8DTv
acv+JkLwFnjc7DEzuJoK61ywR8UJP/FQjD53o8ATXhoGNIIDAgMBAAGjggFMMIIBSDAfBgNV
HSMEGDAWgBR43QkpxguDM6Uc3wFLHlNH8iD1SzAdBgNVHQ4EFgQUM47EbBv7+7Tjj2OaluUR
VEIj7fwwDgYDVR0PAQH/BAQDAgH2MA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQD
AgAHMIHRBglghkgBhvhCAQ0EgcMWgcBDQVVUSU9OOiBUaGUgRGlnaXRhbCBJRCBzdWJqZWN0
cyBvZiBJQ0UtVEVMCkNsYXNzIDAgVHJpYWwgU2VydmljZXMgYXJlIG5vdCBhdXRoZW50aWNh
dGVkLgpJdCBtYXkgYmUgdGhlIGhvbGRlcidzIHJlYWwgbmFtZSBvciBhbiBhbGlhcy4KVXNl
IHRoaXMgRGlnaXRhbCBJRCBmb3IgdGVzdCBwdXJwb3NlZCBvbmx5LgooYykgR01EIDE5OTcw
DQYJKoZIhvcNAQEEBQADgYEAXWnV7vH1s9e0opHh/Hk1nOgpxEbx7XaSAbnVzdUoOxxKvbkl
o0QaB79OV4oLkrFAscMU8iKWN9RkBmWuartRnq45DRsAWMur8DlgbrShlMBEC71OsE2I1FMP
xGe/rJwp2x5Or1M1mchKI808S7WblPyJxCBOMt3Q1in7F1Boz1wwggNgMIICyaADAgECAgEB
MA0GCSqGSIb3DQEBBAUAMEgxDzANBgNVBAcTBkV1cm9wZTEQMA4GA1UEChMHSUNFLVRFTDEj
MCEGA1UECxMaQ0xBU1MgMCBUUklBTCBTRVJWSUNFUyBQS0kwHhcNOTcxMjE3MDgwMzI0WhcN
MDAwMTAxMDAwMDAwWjBnMQswCQYDVQQGEwJERTEMMAoGA1UEChMDR01EMR8wHQYDVQQLExZD
TEFTUyAwIFRSSUFMIFNFUlZJQ0VTMSkwJwYDVQQLEyBUcnVzdEZhY3RvcnkgRGlnaXRhbCBJ
RCBTZXJ2aWNlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA7gWKqAf0MfIp/QL9wMe3
mzEt/+DYSUs6VqkgXehMSbLblwPV7v+QhzhH/JSUoQKVi85qQom7+tnXBJxylB4mfl4AsqyG
SE4IGZPnVcxI4rzW5vhrNVCSzeAkqe2PnoPpZrlh8IYYYKINeGzmZ5QMWEmnDp8+M13zzAUD
A/11ZFMCAwEAAaOCATkwggE1MB8GA1UdIwQYMBaAFLNK4JQgbBz8WKb6QycGs8Hxz6SyMB0G
A1UdDgQWBBR43QkpxguDM6Uc3wFLHlNH8iD1SzAOBgNVHQ8BAf8EBAMCAfYwDwYDVR0TAQH/
BAUwAwEB/zCB0QYJYIZIAYb4QgENBIHDFoHAQ0FVVElPTjogVGhlIERpZ2l0YWwgSUQgc3Vi
amVjdHMgb2YgSUNFLVRFTApDbGFzcyAwIFRyaWFsIFNlcnZpY2VzIGFyZSBub3QgYXV0aGVu
dGljYXRlZC4KSXQgbWF5IGJlIHRoZSBob2xkZXIncyByZWFsIG5hbWUgb3IgYW4gYWxpYXMu
ClVzZSB0aGlzIERpZ2l0YWwgSUQgZm9yIHRlc3QgcHVycG9zZWQgb25seS4KKGMpIEdNRCAx
OTk3MA0GCSqGSIb3DQEBBAUAA4GBAK+hyS6CuuCt2kH7FlvTgpYf39q4sji5JytL3KCExfLe
b4H+YPNbO7cy08KTGa9qSQyodh5+KwXFH9lUct5//bFkm4WfKHH7O2u4+rjWGfGZV6VB1ZCD
dX5CdvVu8O3qNPoQThw60WowKJIS8FkW5BKLP7SB4VJetNrKMz9zwWnJMIIDQTCCAqqgAwIB
AgIBADANBgkqhkiG9w0BAQQFADBIMQ8wDQYDVQQHEwZFdXJvcGUxEDAOBgNVBAoTB0lDRS1U
RUwxIzAhBgNVBAsTGkNMQVNTIDAgVFJJQUwgU0VSVklDRVMgUEtJMB4XDTk3MTIxNzA3NTg0
NVoXDTAwMDEwMTAwMDAwMFowSDEPMA0GA1UEBxMGRXVyb3BlMRAwDgYDVQQKEwdJQ0UtVEVM
MSMwIQYDVQQLExpDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTIFBLSTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEA9jNYTNZLLl7MxMhg1dSc0wq+PiSq4LkPwDL9J+dQk1EJdLWaopkd/NNR
uM37r03RVbSHeI0FPQoylnJpu0Kj6KNWxVwIeGeWGrIdhRShUSh3n2bFSD/0T5uHWvsN1U9f
d6uxDaYHcnfLLCtTi76Piu2GCJK4eH3W76Oo3Ei4VoMCAwEAAaOCATkwggE1MB8GA1UdIwQY
MBaAFLNK4JQgbBz8WKb6QycGs8Hxz6SyMB0GA1UdDgQWBBSzSuCUIGwc/Fim+kMnBrPB8c+k
sjAOBgNVHQ8BAf8EBAMCAfYwDwYDVR0TAQH/BAUwAwEB/zCB0QYJYIZIAYb4QgENBIHDFoHA
Q0FVVElPTjogVGhlIERpZ2l0YWwgSUQgc3ViamVjdHMgb2YgSUNFLVRFTApDbGFzcyAwIFRy
aWFsIFNlcnZpY2VzIGFyZSBub3QgYXV0aGVudGljYXRlZC4KSXQgbWF5IGJlIHRoZSBob2xk
ZXIncyByZWFsIG5hbWUgb3IgYW4gYWxpYXMuClVzZSB0aGlzIERpZ2l0YWwgSUQgZm9yIHRl
c3QgcHVycG9zZWQgb25seS4KKGMpIEdNRCAxOTk3MA0GCSqGSIb3DQEBBAUAA4GBALkKsGZG
E5ckTCE0F7hTF2eZgnDZYgm709UJeozPRB/3KjuyjdxlbVj2eiCWVB9HpH0KK2kEqnhgiHWL
xwQGuycFD7Px7SDIwjEC/7c9YERIw1GmGWe2g6EatOP3oS/4tCy72TODDhD5WeYAMFcpKihR
Skp0N+zOhEuDvxyXGauuMYIBYDCCAVwCAQEwfDB2MQswCQYDVQQGEwJERTEMMAoGA1UEChMD
R01EMR8wHQYDVQQLExZDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTMTgwNgYDVQQLEy9UcnVzdEZh
Y3RvcnkgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENlcnRpZmljYXRlcwICAvMwCQYFKw4DAhoF
AKB9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDkyMjA5
MjY0OVowHgYJKoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQU
Ypl1kQvQEkbLfHbDhyuczu2HatYwDQYJKoZIhvcNAQEBBQAEQCWTOZQScCOMbV6jt7j/IN+M
XcHMcvD2wgOSKEb1Sqr48Aof6oFV3oeBQseB8SJqpl93ZiCRYZBl+1T3SVMCdZc=
--------------ms6C21A3596B2679A5F64C275F--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA03834 for ietf-pkix-bks; Mon, 21 Sep 1998 21:22:03 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03830 for <[e-mail]>; Mon, 21 Sep 1998 21:22:01 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id GAA05716; Tue, 22 Sep 1998 06:28:20 +0200 (CEST)
Received: from stefans (t2o68p111.telia.com [62.20.138.231]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id GAA27141; Tue, 22 Sep 1998 06:28:18 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 22 Sep 1998 06:25:35 +0200
To: Al Arsenault <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PKIX Roadmap
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id VAA03831
Sender: [e-mail]
Precedence: bulk

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.
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29811 for ietf-pkix-bks; Mon, 21 Sep 1998 10:30:40 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29807 for <[e-mail]>; Mon, 21 Sep 1998 10:30:39 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA06046; Mon, 21 Sep 1998 10:35:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Mon, 21 Sep 1998 13:32:57 -0400
To: Stefan Santesson <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: PKIX Roadmap
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29336 for ietf-pkix-bks; Mon, 21 Sep 1998 09:17:24 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29332 for <[e-mail]>; Mon, 21 Sep 1998 09:17:22 -0700 (PDT)
Received: from [128.33.238.151] (TC151.BBN.COM [128.33.238.151]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA05250 for <[e-mail]>; Mon, 21 Sep 1998 12:23:14 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1305727475==_ma============"
X-Sender: [e-mail]
Message-Id: <v04011701b22c2cbc4e8e@[128.33.238.151]>
Date: Mon, 21 Sep 1998 12:20:00 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: meeting minutes
Sender: [e-mail]
Precedence: bulk

--============_-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:
[e-mail].



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:
[e-mail].




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============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28710 for ietf-pkix-bks; Mon, 21 Sep 1998 07:34:25 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28706 for <[e-mail]>; Mon, 21 Sep 1998 07:34:21 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id QAA11344; Mon, 21 Sep 1998 16:40:31 +0200 (CEST)
Received: from stefans (t4o68p96.telia.com [62.20.139.216]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA06265; Mon, 21 Sep 1998 16:22:11 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 21 Sep 1998 16:19:49 +0200
To: Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PKIX Roadmap
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA28707
Sender: [e-mail]
Precedence: bulk

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
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22403 for ietf-pkix-bks; Mon, 21 Sep 1998 00:38:25 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22390 for <[e-mail]>; Mon, 21 Sep 1998 00:36:58 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA17478; Mon, 21 Sep 1998 09:18:26 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA16740; Mon, 21 Sep 1998 09:18:25 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Mon, 21 Sep 1998 09:18:44 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: OCSP - Public Key Dstribution
References: <01BDE484.F1DA1820@HYDRA>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:  Saturday, September 19, 1998 02:15
> To:  Andreas Berger
> Cc:  Peter Sylvester; [e-mail]; [e-mail]
> 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:[e-mail]
>  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:[e-mail]
 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22389 for ietf-pkix-bks; Mon, 21 Sep 1998 00:36:51 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22383 for <[e-mail]>; Mon, 21 Sep 1998 00:36:11 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA09835; Mon, 21 Sep 1998 09:29:18 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA15096; Mon, 21 Sep 1998 09:29:22 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Mon, 21 Sep 1998 09:29:41 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04797 for ietf-pkix-bks; Sun, 20 Sep 1998 17:02:12 -0700 (PDT)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04793 for <[e-mail]>; Sun, 20 Sep 1998 17:02:06 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id KAA06232 for <[e-mail]>; Mon, 21 Sep 1998 10:08:18 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: Testing the ASN.1 in Part 1
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 Sep 1998 10:08:16 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


-- 
Dean Povey,         | e-m: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02905 for ietf-pkix-bks; Sun, 20 Sep 1998 10:35:53 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02901 for <[e-mail]>; Sun, 20 Sep 1998 10:35:51 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id TAA10451; Sun, 20 Sep 1998 19:41:59 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA02115; Sun, 20 Sep 1998 19:41:58 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA18646; Sun, 20 Sep 1998 19:41:58 +0200
Date: Sun, 20 Sep 1998 19:41:58 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: OCSP - Public Key Dstribution
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

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.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02899 for ietf-pkix-bks; Sun, 20 Sep 1998 10:35:23 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02895 for <[e-mail]>; Sun, 20 Sep 1998 10:35:21 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id TAA10447; Sun, 20 Sep 1998 19:41:29 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA02111; Sun, 20 Sep 1998 19:41:28 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA18643; Sun, 20 Sep 1998 19:41:28 +0200
Date: Sun, 20 Sep 1998 19:41:28 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [e-mail]
Precedence: bulk

> 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 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA29413 for ietf-pkix-bks; Sun, 20 Sep 1998 01:54:00 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA29409 for <[e-mail]>; Sun, 20 Sep 1998 01:53:57 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA59705; Sun, 20 Sep 1998 10:59:56 +0200
Received: by HYDRA with Microsoft Mail id <01BDE484.F1DA1820@HYDRA>; Sun, 20 Sep 1998 10:53:48 +0200
Message-ID: <01BDE484.F1DA1820@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: OCSP - Public Key Dstribution
Date: Sun, 20 Sep 1998 10:53:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA29410
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent:  Saturday, September 19, 1998 02:15
To:  Andreas Berger
Cc:  Peter Sylvester; [e-mail]; [e-mail]
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:[e-mail]
 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21235 for ietf-pkix-bks; Sat, 19 Sep 1998 13:51:03 -0700 (PDT)
Received: from cylink.com ([204.160.108.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21231 for <[e-mail]>; Sat, 19 Sep 1998 13:51:02 -0700 (PDT)
Received: by  cylink.com (8.8.8/SMI-SVR4) id OAA07962; Sat, 19 Sep 1998 14:01:17 -0700 (PDT)
Received: from cylink252.cylink.com(205.226.82.252) by enforcer.cylink.com via smap (V2.0) id xma007960; Sat, 19 Sep 98 14:00:57 -0700
Reply-To: <[e-mail]>
From: "Amit Kapoor" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: Testing the ASN.1 in Part 1
Date: Sat, 19 Sep 1998 13:58:24 -0700
Message-ID: <001a01bde410$3dbd7cc0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

	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


 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26882 for ietf-pkix-bks; Fri, 18 Sep 1998 17:54:41 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26878 for <[e-mail]>; Fri, 18 Sep 1998 17:54:40 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id RAA13604; Fri, 18 Sep 1998 17:58:14 -0700 (PDT)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA11253; Fri, 18 Sep 1998 18:00:07 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 18 Sep 1998 18:00:08 -0700
To: [e-mail]
From: Michael Myers <[e-mail]>
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25592 for ietf-pkix-bks; Fri, 18 Sep 1998 14:33:09 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25586 for <[e-mail]>; Fri, 18 Sep 1998 14:33:07 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id OAA19912; Fri, 18 Sep 1998 14:39:10 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 18 Sep 1998 14:38:11 -0700
To: "Flanigan, Bill" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: proposed text for attributes
In-Reply-To: <5F21F6A15446D211B0730020484016A34A8DED@RBMAIL103>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25057 for ietf-pkix-bks; Fri, 18 Sep 1998 13:29:40 -0700 (PDT)
Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25053 for <[e-mail]>; Fri, 18 Sep 1998 13:29:39 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <TDQTCBB7>; Fri, 18 Sep 1998 16:34:34 -0400
Message-ID: <5F21F6A15446D211B0730020484016A34A8DED@RBMAIL103>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: proposed text for attributes
Date: Fri, 18 Sep 1998 16:39:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Engineering       DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[e-mail]]
> Sent:	Friday, September 18, 1998 12:39 PM
> To:	[e-mail]
> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23955 for ietf-pkix-bks; Fri, 18 Sep 1998 11:09:14 -0700 (PDT)
Received: from romulus.cs.ut.ee ([e-mail] [193.40.5.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23951 for <[e-mail]>; Fri, 18 Sep 1998 11:09:12 -0700 (PDT)
Received: from localhost (jan@localhost) by romulus.cs.ut.ee (8.9.1/8.9.1/romulus-1.4) with SMTP id VAA13259 for <[e-mail]>; Fri, 18 Sep 1998 21:15:08 +0300 (EET DST)
Date: Fri, 18 Sep 1998 21:15:06 +0300 (   )
From: Jan Willemson <[e-mail]>
To: [e-mail]
Subject: Who uses what?
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23493 for ietf-pkix-bks; Fri, 18 Sep 1998 10:23:23 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23488; Fri, 18 Sep 1998 10:23:22 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA15812; Fri, 18 Sep 1998 10:28:13 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Fri, 18 Sep 1998 13:29:49 -0400
To: Dean Povey <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Testing the ASN.1 in Part 1 
Cc: Paul Hoffman / IMC <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 15 Sep 1998 14:29:01 +1000."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<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:
[e-mail]&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: [phone]
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>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23017 for ietf-pkix-bks; Fri, 18 Sep 1998 09:33:46 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23013 for <[e-mail]>; Fri, 18 Sep 1998 09:33:45 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Fri, 18 Sep 1998 09:39:16 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: proposed text for attributes
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22573 for ietf-pkix-bks; Fri, 18 Sep 1998 08:40:12 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22569 for <[e-mail]>; Fri, 18 Sep 1998 08:40:10 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id RAA21236; Fri, 18 Sep 1998 17:41:08 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id RAA21071; Fri, 18 Sep 1998 17:41:07 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id RAA17885; Fri, 18 Sep 1998 17:41:07 +0200
Date: Fri, 18 Sep 1998 17:41:07 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

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.

   }



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22288 for ietf-pkix-bks; Fri, 18 Sep 1998 08:08:01 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22284 for <[e-mail]>; Fri, 18 Sep 1998 08:07:56 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id RAA16372; Fri, 18 Sep 1998 17:14:34 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA17286; Fri, 18 Sep 1998 17:14:27 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 17:14:48 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Andreas Berger <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21046 for ietf-pkix-bks; Fri, 18 Sep 1998 05:00:00 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA21042 for <[e-mail]>; Fri, 18 Sep 1998 04:59:58 -0700 (PDT)
Received: 	id IAA04558; Fri, 18 Sep 1998 08:03:06 -0400
Received: by gateway id <S2S6Y5Z8>; Fri, 18 Sep 1998 07:59:50 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: proposed text for attributes
Date: Fri, 18 Sep 1998 07:59:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA18545 for ietf-pkix-bks; Fri, 18 Sep 1998 03:02:10 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA18541 for <[e-mail]>; Fri, 18 Sep 1998 03:02:07 -0700 (PDT)
Received: from darmstadt.gmd.de (aberger@pc-turin [141.12.33.71]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA27586; Fri, 18 Sep 1998 12:06:18 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 12:06:44 +0200
From: Andreas Berger <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18216 for ietf-pkix-bks; Fri, 18 Sep 1998 01:56:54 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18212 for <[e-mail]>; Fri, 18 Sep 1998 01:56:53 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id LAA08690; Fri, 18 Sep 1998 11:02:54 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA17532; Fri, 18 Sep 1998 11:02:54 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA17802; Fri, 18 Sep 1998 11:02:53 +0200
Date: Fri, 18 Sep 1998 11:02:53 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [e-mail]
Precedence: bulk

> 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18176 for ietf-pkix-bks; Fri, 18 Sep 1998 01:50:30 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18171 for <[e-mail]>; Fri, 18 Sep 1998 01:50:27 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id KAA08440; Fri, 18 Sep 1998 10:56:25 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id KAA17394; Fri, 18 Sep 1998 10:56:24 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id KAA17797; Fri, 18 Sep 1998 10:56:24 +0200
Date: Fri, 18 Sep 1998 10:56:24 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18121 for ietf-pkix-bks; Fri, 18 Sep 1998 01:43:45 -0700 (PDT)
Received: from mail-gw.pacbell.net (mail-gw.pacbell.net [206.13.28.25]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18117 for <[e-mail]>; Fri, 18 Sep 1998 01:43:44 -0700 (PDT)
Received: from pacbell.net (ppp-206-170-3-162.okld03.pacbell.net [206.170.3.162]) by mail-gw.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id BAA19674; Fri, 18 Sep 1998 01:49:45 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 01:41:01 -0700
From: Dan Weinstein <[e-mail]>
X-Mailer: Mozilla 4.5b2 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

>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
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07834 for ietf-pkix-bks; Thu, 17 Sep 1998 22:42:05 -0700 (PDT)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07821; Thu, 17 Sep 1998 22:42:01 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id PAA24765; Fri, 18 Sep 1998 15:48:00 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
cc: Paul Hoffman / IMC <[e-mail]>, [e-mail]
Subject: Re: Testing the ASN.1 in Part 1 
In-reply-to: Your message of "Tue, 15 Sep 1998 14:29:01 +1000." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Sep 1998 15:47:57 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>
>
>>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: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26263 for ietf-pkix-bks; Thu, 17 Sep 1998 14:47:40 -0700 (PDT)
Received: from atlantic.valicert.com ([e-mail] [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26259 for <[e-mail]>; Thu, 17 Sep 1998 14:47:39 -0700 (PDT)
Received: (qmail 2737 invoked from network); 17 Sep 1998 21:53:34 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by 209.185.6.162 with SMTP; 17 Sep 1998 21:53:34 -0000
Message-ID: <[e-mail]>
Date: Thu, 17 Sep 1998 14:53:31 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b2 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23625 for ietf-pkix-bks; Thu, 17 Sep 1998 09:30:23 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23621 for <[e-mail]>; Thu, 17 Sep 1998 09:30:22 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id SAA27290 for <[e-mail]>; Thu, 17 Sep 1998 18:36:02 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA11058 for <[e-mail]>; Thu, 17 Sep 1998 18:36:02 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA17487 for [e-mail]; Thu, 17 Sep 1998 18:36:01 +0200
Date: Thu, 17 Sep 1998 18:36:01 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [e-mail]
Precedence: bulk

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.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23589 for ietf-pkix-bks; Thu, 17 Sep 1998 09:22:26 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23585 for <[e-mail]>; Thu, 17 Sep 1998 09:22:25 -0700 (PDT)
Received: 	id MAA26121; Thu, 17 Sep 1998 12:26:32 -0400
Received: by gateway id <S2S6YV9W>; Thu, 17 Sep 1998 12:23:18 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 12:23:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 16, 1998 10:26 PM
> To: 	[e-mail]
> 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"?
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23104 for ietf-pkix-bks; Thu, 17 Sep 1998 08:38:23 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23100 for <[e-mail]>; Thu, 17 Sep 1998 08:38:22 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA17795; Thu, 17 Sep 1998 08:44:19 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <SW42KV8H>; Thu, 17 Sep 1998 08:43:56 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 08:43:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Wednesday, September 16, 1998 7:27 PM
To: [e-mail]
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"?


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22458 for ietf-pkix-bks; Thu, 17 Sep 1998 07:04:25 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22454 for <[e-mail]>; Thu, 17 Sep 1998 07:04:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA14218; Thu, 17 Sep 1998 10:09:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-06.txt
Date: Thu, 17 Sep 1998 10:09:49 -0400
Sender: [e-mail]
Precedence: bulk

--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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA29190 for ietf-pkix-bks; Wed, 16 Sep 1998 19:24:20 -0700 (PDT)
Received: from dc.jones.com (dc.jones.com [206.156.0.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA29186 for <[e-mail]>; Wed, 16 Sep 1998 19:24:18 -0700 (PDT)
Received: from dc.jones.com (cm0714h.jones.com [208.159.209.173]) by dc.jones.com (8.8.8/8.8.8) with ESMTP id WAA19170 for <[e-mail]>; Wed, 16 Sep 1998 22:27:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 16 Sep 1998 22:26:37 -0400
From: bgmiller <[e-mail]>
Reply-To: [e-mail]
Organization: Jones Internet Channel
X-Mailer: Mozilla 4.05 [en]C-JIC-DC  (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory Attributes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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"?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27832 for ietf-pkix-bks; Wed, 16 Sep 1998 15:43:37 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27828 for <[e-mail]>; Wed, 16 Sep 1998 15:43:36 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 16 Sep 1998 15:49:01 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attributes
In-Reply-To: <[e-mail] ndem.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27652 for ietf-pkix-bks; Wed, 16 Sep 1998 15:16:39 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27648 for <[e-mail]>; Wed, 16 Sep 1998 15:16:38 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA23758; Wed, 16 Sep 1998 15:22:29 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <SW42KM98>; Wed, 16 Sep 1998 15:22:04 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Wed, 16 Sep 1998 15:22:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, September 16, 1998 2:23 PM
To: [e-mail]
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
[phone] (voice)
[phone] (fax)
[e-mail]
http://www.cygnacom.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27294 for ietf-pkix-bks; Wed, 16 Sep 1998 14:18:03 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27290 for <[e-mail]>; Wed, 16 Sep 1998 14:18:00 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7T51TK>; Wed, 16 Sep 1998 17:22:56 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1AAE@WUHER>
From: Santosh Chokhani <[e-mail]>
To: [e-mail]
Subject: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Date: Wed, 16 Sep 1998 17:22:55 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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
[phone] (voice)
[phone] (fax)
[e-mail]
http://www.cygnacom.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12601 for ietf-pkix-bks; Tue, 15 Sep 1998 10:46:56 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12597 for <[e-mail]>; Tue, 15 Sep 1998 10:46:55 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA01587; Tue, 15 Sep 1998 10:50:19 -0700 (PDT)
Received: from wford-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA14084; Tue, 15 Sep 1998 10:52:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 15 Sep 1998 13:52:32 -0700
To: [e-mail]
From: Warwick Ford <[e-mail]>
Subject: Schema Straw Poll Closure
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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 [phone] x225; Fax [phone]
[e-mail];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11380 for ietf-pkix-bks; Tue, 15 Sep 1998 08:56:25 -0700 (PDT)
Received: from firewall.globeset.com ([e-mail] [207.239.133.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11376 for <[e-mail]>; Tue, 15 Sep 1998 08:56:24 -0700 (PDT)
Received: from drought.globeset.com ([e-mail] [10.1.192.39]) by firewall.globeset.com (8.9.0/8.9.0) with ESMTP id LAA26296 for <[e-mail]>; Tue, 15 Sep 1998 11:02:08 -0500 (CDT)
Received: (from trevor@localhost) by drought.globeset.com (8.7.6/8.7.3) id LAA27450; Tue, 15 Sep 1998 11:02:03 -0500
From: Trevor Sosebee <[e-mail]>
Date: Tue, 15 Sep 1998 11:02:01 -0500 (CDT)
To: [e-mail]
Subject: UTF8String definition in PKIX-3
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13822.36613.678919.467432@drought>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA14487 for ietf-pkix-bks; Mon, 14 Sep 1998 21:23:34 -0700 (PDT)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA14482; Mon, 14 Sep 1998 21:23:30 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id OAA08287; Tue, 15 Sep 1998 14:29:04 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: Paul Hoffman / IMC <[e-mail]>
cc: [e-mail]
Subject: Re: Testing the ASN.1 in Part 1 
In-reply-to: Your message of "Mon, 14 Sep 1998 08:36:12 MST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 15 Sep 1998 14:29:01 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>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: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09835 for ietf-pkix-bks; Mon, 14 Sep 1998 10:17:45 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09830; Mon, 14 Sep 1998 10:17:43 -0700 (PDT)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA43924; Mon, 14 Sep 1998 10:19:03 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 14 Sep 1998 10:18:56 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA10684; Mon, 14 Sep 1998 10:18:55 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) 
Date: Mon, 14 Sep 1998 10:18:54 -0700
Subject: Re: Testing the ASN.1 in Part 1
From: "Aram Perez" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09714 for ietf-pkix-bks; Mon, 14 Sep 1998 10:03:42 -0700 (PDT)
Received: from atlantic.valicert.com ([e-mail] [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA09709 for <[e-mail]>; Mon, 14 Sep 1998 10:03:41 -0700 (PDT)
Received: (qmail 6298 invoked from network); 14 Sep 1998 17:09:19 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 14 Sep 1998 17:09:19 -0000
Message-ID: <[e-mail]>
Date: Mon, 14 Sep 1998 10:09:39 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Andreas Berger <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: OCSP ASN.1 comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08894 for ietf-pkix-bks; Mon, 14 Sep 1998 08:30:53 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA08890 for <[e-mail]>; Mon, 14 Sep 1998 08:30:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 14 Sep 1998 08:36:12 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Testing the ASN.1 in Part 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA07863 for ietf-pkix-bks; Mon, 14 Sep 1998 05:56:23 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA07859 for <[e-mail]>; Mon, 14 Sep 1998 05:56:15 -0700 (PDT)
Received: from darmstadt.gmd.de (aberger@pc-turin [141.12.33.71]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA27331 for <[e-mail]>; Mon, 14 Sep 1998 15:01:21 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 14 Sep 1998 15:01:43 +0200
From: Andreas Berger <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: OCSP ASN.1 comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA06297 for ietf-pkix-bks; Sat, 12 Sep 1998 15:22:49 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06293 for <[e-mail]>; Sat, 12 Sep 1998 15:22:48 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id AAA01228; Sun, 13 Sep 1998 00:28:21 +0200 (CEST)
Received: from stefans (t1o68p15.telia.com [62.20.138.15]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA03222; Sun, 13 Sep 1998 00:28:10 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 13 Sep 1998 00:25:48 +0200
To: Mike Smith <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA06294
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 8:44 AM >>>
>******************  InterScan Message (on zbc2)
>
>noname is scanned and no virus found
>*********************************************************
>












    !
>!
>


                                                           
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06115 for ietf-pkix-bks; Sat, 12 Sep 1998 14:23:54 -0700 (PDT)
Received: from mail.spyrus.com.au (fwuser@[203.37.128.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06111 for <[e-mail]>; Sat, 12 Sep 1998 14:23:47 -0700 (PDT)
Message-ID: <A1019E9C2D34D211A501006008C2045001BF66@MAIL>
From: Charles Moore <[e-mail]>
To: "'Peter Lipp'" <[e-mail]>, Paul Koning <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Sun, 13 Sep 1998 07:31:56 +1000
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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: [phone], Extension 101




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA23955 for ietf-pkix-bks; Fri, 11 Sep 1998 12:52:46 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (archimedes.iaik.tu-graz.ac.at [129.27.234.31]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA23951 for <[e-mail]>; Fri, 11 Sep 1998 12:52:44 -0700 (PDT)
Received: from plipp [129.27.239.102] by iaik.tu-graz.ac.at (SMTPD32-4.06) id A0D22800C6; Fri, 11 Sep 1998 21:58:10 +03d00
From: "Peter Lipp" <[e-mail]>
To: "Paul Koning" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Fri, 11 Sep 1998 21:59:08 +0200
Message-ID: <000001bdddbe$a311f630$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23179 for ietf-pkix-bks; Fri, 11 Sep 1998 11:32:59 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA23175 for <[e-mail]>; Fri, 11 Sep 1998 11:32:58 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 12:33:29 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 12:33:22 -0600
From: Mike Smith <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 12:07 PM >>>
>>>>> "Mike" == Mike Smith <[e-mail]> 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
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22902 for ietf-pkix-bks; Fri, 11 Sep 1998 11:03:49 -0700 (PDT)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22898 for <[e-mail]>; Fri, 11 Sep 1998 11:03:48 -0700 (PDT)
Received: from xedia.com by relay3.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgke24932; Fri, 11 Sep 1998 14:07:44 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26501; Fri, 11 Sep 98 14:06:53 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA28256; Fri, 11 Sep 1998 14:07:42 -0400
Date: Fri, 11 Sep 1998 14:07:42 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Mike" == Mike Smith <[e-mail]> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22010 for ietf-pkix-bks; Fri, 11 Sep 1998 09:16:19 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22006 for <[e-mail]>; Fri, 11 Sep 1998 09:16:18 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 10:16:48 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 10:16:37 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21953 for ietf-pkix-bks; Fri, 11 Sep 1998 09:10:26 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA21948 for <[e-mail]>; Fri, 11 Sep 1998 09:10:25 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 10:11:17 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 10:11:04 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21226 for ietf-pkix-bks; Fri, 11 Sep 1998 08:01:51 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21222 for <[e-mail]>; Fri, 11 Sep 1998 08:01:49 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id LAA27778; Fri, 11 Sep 1998 11:05:58 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 11 Sep 1998 11:06:33 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: [e-mail]
CC: Santosh Chokhani <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > > Sent: Wednesday, September 09, 1998 8:44 PM
> > > To:   Santosh Chokhani
> > > Cc:   'Sharon Boeyen'; '[e-mail]'
> > > 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:[e-mail]]
> > > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > > To:   '[e-mail]'; 'Santosh Chokhani'
> > > > > Subject:      RE: forward & reverse elements - population
> > > > >
> > > > >
> > > > >
> > > > > > ----------
> > > > > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > > > > Sent:       September 8, 1998 10:05 AM
> > > > > > To:         'Sharon Boeyen'; '[e-mail]'
> > > > > > 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:[e-mail]
> > >       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:[e-mail]
>       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. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21102 for ietf-pkix-bks; Fri, 11 Sep 1998 07:41:23 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21098 for <[e-mail]>; Fri, 11 Sep 1998 07:41:22 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id QAA00126 for <[e-mail]>; Fri, 11 Sep 1998 16:46:47 +0200 (MET DST)
Received: from stefans (t2o68p33.telia.com [62.20.138.153]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA11065 for <[e-mail]>; Fri, 11 Sep 1998 16:46:46 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 11 Sep 1998 16:44:21 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA21099
Sender: [e-mail]
Precedence: bulk

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
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16901 for ietf-pkix-bks; Fri, 11 Sep 1998 02:16:50 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16896 for <[e-mail]>; Fri, 11 Sep 1998 02:16:46 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA13435; Fri, 11 Sep 1998 11:23:50 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id LAA15724; Fri, 11 Sep 1998 11:23:51 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 11 Sep 1998 11:23:10 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > Sent: Wednesday, September 09, 1998 8:44 PM
> > To:   Santosh Chokhani
> > Cc:   'Sharon Boeyen'; '[e-mail]'
> > 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:[e-mail]]
> > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > To:   '[e-mail]'; 'Santosh Chokhani'
> > > > Subject:      RE: forward & reverse elements - population
> > > >
> > > >
> > > >
> > > > > ----------
> > > > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > > > Sent:       September 8, 1998 10:05 AM
> > > > > To:         'Sharon Boeyen'; '[e-mail]'
> > > > > 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:[e-mail]
> >       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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA15497 for ietf-pkix-bks; Fri, 11 Sep 1998 00:54:12 -0700 (PDT)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA15489 for <[e-mail]>; Fri, 11 Sep 1998 00:54:09 -0700 (PDT)
Message-Id: <[e-mail]>
Received: forwarded by SMTP 3.0.6.
From: Graham Bland <[e-mail]>
Date: Fri, 11 Sep 1998 8:49:49 +0000
To: [e-mail]
Subject: RE: RE: New Extension Proposed: Method O
MIME-version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA15493
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
> Sent: 10 September 1998 18:06
> To: Ian Roberts; Graham Bland; Chris Wright; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> 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 <[e-mail]> 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:[e-mail]]
> > Sent: Wednesday, September 09, 1998 3:12 PM
> > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> > [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > >> Sent: Wednesday, September 09, 1998 1:16 PM
> > >> To: Mike Smith; [e-mail]; [e-mail]
> > >> Cc: [e-mail]
> > >> 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: [e-mail]   phone: [phone]             LLLLLLLL
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: [phone]
Website:  http://www.zergo.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA24782 for ietf-pkix-bks; Thu, 10 Sep 1998 12:16:00 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA24777 for <[e-mail]>; Thu, 10 Sep 1998 12:15:55 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA27185 for <[e-mail]>; Thu, 10 Sep 1998 15:21:19 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA27171 for <[e-mail]>; Thu, 10 Sep 1998 15:21:17 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA00818 for <[e-mail]>; Thu, 10 Sep 1998 15:20:38 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 10 Sep 1998 15:21:10 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Thu, 10 Sep 1998 15:21:09 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Mike Smith'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 15:21:09 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Thursday, September 10, 1998 1:48 PM
>To: 	Mike Smith; [e-mail]; [e-mail]; [e-mail];
>[e-mail]
>Cc: 	[e-mail]
>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
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24098 for ietf-pkix-bks; Thu, 10 Sep 1998 10:43:18 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24094 for <[e-mail]>; Thu, 10 Sep 1998 10:43:17 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA16666; Thu, 10 Sep 1998 10:46:17 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA12380; Thu, 10 Sep 1998 10:48:02 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 13:48:20 -0400
Message-ID: <002001bddce3$3318eb80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23067 for ietf-pkix-bks; Thu, 10 Sep 1998 08:58:52 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23063 for <[e-mail]>; Thu, 10 Sep 1998 08:58:51 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Thu, 10 Sep 1998 09:59:31 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 10 Sep 1998 09:59:21 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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:[e-mail]] 
> Sent: Wednesday, September 09, 1998 3:12 PM
> To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [e-mail]; [e-mail] 
> Cc: [e-mail] 
> 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:[e-mail]] 
> >> Sent: Wednesday, September 09, 1998 1:16 PM
> >> To: Mike Smith; [e-mail]; [e-mail] 
> >> Cc: [e-mail] 
> >> 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: [e-mail]   phone: [phone]             LLLLLLLL
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22915 for ietf-pkix-bks; Thu, 10 Sep 1998 08:43:51 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22911 for <[e-mail]>; Thu, 10 Sep 1998 08:43:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 10 Sep 1998 08:49:00 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
>Date: Thu, 10 Sep 1998 10:34:19 -0400
>Sender: [e-mail]
>
>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 [e-mail]
>          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:	[e-mail].  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:	<[e-mail]>
>
>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>
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22538 for ietf-pkix-bks; Thu, 10 Sep 1998 08:14:28 -0700 (PDT)
Received: from slack.lne.com ([e-mail] [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22534 for <[e-mail]>; Thu, 10 Sep 1998 08:14:26 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id IAA12666; Thu, 10 Sep 1998 08:19:50 -0700
From: Eric Murray <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [e-mail] (Paul Koning)
Date: Thu, 10 Sep 1998 08:19:49 -0700 (PDT)
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]> from "Paul Koning" at Sep 10, 98 09:21:30 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21461 for ietf-pkix-bks; Thu, 10 Sep 1998 06:17:21 -0700 (PDT)
Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21457 for <[e-mail]>; Thu, 10 Sep 1998 06:17:20 -0700 (PDT)
Received: from xedia.com by relay5.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgft03924; Thu, 10 Sep 1998 09:21:34 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09439; Thu, 10 Sep 98 09:20:42 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA14290; Thu, 10 Sep 1998 09:21:30 -0400
Date: Thu, 10 Sep 1998 09:21:30 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <000701bddc29$99814e40$[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Tony" == Tony Bartoletti <[e-mail]> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21325 for ietf-pkix-bks; Thu, 10 Sep 1998 06:02:10 -0700 (PDT)
Received: from getafix.fcpl.co.in (Getafix.fcpl.co.in [196.1.104.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21320 for <[e-mail]>; Thu, 10 Sep 1998 06:02:03 -0700 (PDT)
Received: from TinTins.fcpl.co.in ([196.1.104.84]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA135 for <[e-mail]>; Thu, 10 Sep 1998 18:38:00 +0530
Message-ID: <000b01bddcbc$29a0ac40$[e-mail]>
From: "Shailesh" <[e-mail]>
To: <[e-mail]>
Subject: PKIX transports using HTTP
Date: Thu, 10 Sep 1998 18:38:54 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21056 for ietf-pkix-bks; Thu, 10 Sep 1998 05:47:22 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21051 for <[e-mail]>; Thu, 10 Sep 1998 05:47:17 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id OAA01964; Thu, 10 Sep 1998 14:54:13 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id OAA19716; Thu, 10 Sep 1998 14:54:06 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 10 Sep 1998 14:53:26 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Eric Murray <[e-mail]>
CC: [e-mail]
Subject: Re: New Extension Proposed: Method Of Authentication
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20901 for ietf-pkix-bks; Thu, 10 Sep 1998 05:19:37 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20897 for <[e-mail]>; Thu, 10 Sep 1998 05:19:34 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id OAA22350; Thu, 10 Sep 1998 14:26:25 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id OAA19816; Thu, 10 Sep 1998 14:26:20 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 10 Sep 1998 14:25:40 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Mike Smith <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: New Extension Proposed: Method Of Authentication
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20886 for ietf-pkix-bks; Thu, 10 Sep 1998 05:16:33 -0700 (PDT)
Received: from getafix.fcpl.co.in (Getafix.fcpl.co.in [196.1.104.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20879 for <[e-mail]>; Thu, 10 Sep 1998 05:16:12 -0700 (PDT)
Received: from dynamo ([196.1.104.100]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA142 for <[e-mail]>; Thu, 10 Sep 1998 17:52:05 +0530
Message-ID: <002b01bddcb6$078be850$[e-mail]>
From: "Abhay Kulkarni" <[e-mail]>
To: <[e-mail]>
Subject: PKIX Certificate Management Protocols
Date: Thu, 10 Sep 1998 17:54:53 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BDDCE4.1D99E100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2110.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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:  [e-mail]
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:[e-mail]">[e-mail]</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--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20830 for ietf-pkix-bks; Thu, 10 Sep 1998 05:10:30 -0700 (PDT)
Received: from gatekeeper.domus.com ([198.166.58.193]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20826 for <[e-mail]>; Thu, 10 Sep 1998 05:10:28 -0700 (PDT)
Received: from dns_int.domus.com by gatekeeper1.domus.com (8.6.13/200.19.1.1) id IAA27690; Thu, 10 Sep 1998 08:07:14 -0400
Received: (from smap@localhost) by dns_int.domus.com (8.6.8/8.6.6) id HAA24702 for <[e-mail]>; Thu, 10 Sep 1998 07:35:30 -0400
Received: from wpgate.domus.com(198.166.59.10) by dns_int.domus.com via smap (V1.3) id sma024700; Thu Sep 10 07:35:22 1998
Received: from DOMUS-Message_Server by wpgate.domus.com with Novell_GroupWise; Thu, 10 Sep 1998 08:07:25 -0400
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 10 Sep 1998 08:07:16 -0400
From: William Dziadyk <[e-mail]>
To: [e-mail]
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

      
---------------------------------------------------------------------------------
   William Dziadyk, PEng
   IT Security Services, DOMUS Software, Ottawa, Ontario, Canada 
   [phone]  ext 342  ----   [e-mail] 
 ---------------------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12866 for ietf-pkix-bks; Wed, 9 Sep 1998 23:54:28 -0700 (PDT)
Received: from genius.tisl.soft.net (genius.tisl.soft.net [164.164.20.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA12861; Wed, 9 Sep 1998 23:54:22 -0700 (PDT)
Received: from narayan ([32.97.253.98]) by genius.tisl.soft.net (AIX4.3/UCB 8.7/8.7) with ESMTP id MAA20198; Thu, 10 Sep 1998 12:25:52 -0530 (ist)
Message-ID: <[e-mail]>
Date: Thu, 10 Sep 1998 12:27:57 +0530
From: Narayan Raghu <[e-mail]>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail]
Subject: Re: New Extension Proposed: Method Of Authentication
X-Priority: 3 (Normal)
References: <000701bddc29$99814e40$[e-mail]> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27613 for ietf-pkix-bks; Wed, 9 Sep 1998 16:56:28 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27609 for <[e-mail]>; Wed, 9 Sep 1998 16:56:27 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ879>; Wed, 9 Sep 1998 20:00:03 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A6C@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Santosh Chokhani <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail], Eric Murray <[e-mail]>
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 20:00:00 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 7:20 PM
> To:	Phillip M Hallam-Baker; Santosh Chokhani; Mike Smith;
> [e-mail]; [e-mail]; Eric Murray
> Cc:	[e-mail]
> 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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27585 for ietf-pkix-bks; Wed, 9 Sep 1998 16:53:54 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA27581 for <[e-mail]>; Wed, 9 Sep 1998 16:53:53 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 09 Sep 1998 16:58:57 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
In-Reply-To: <[e-mail]>
References: <000701bddc29$99814e40$[e-mail]> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27403 for ietf-pkix-bks; Wed, 9 Sep 1998 16:16:15 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27399 for <[e-mail]>; Wed, 9 Sep 1998 16:16:14 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id QAA10253; Wed, 9 Sep 1998 16:21:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 09 Sep 1998 16:20:25 -0700
To: "Phillip M Hallam-Baker" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>, Eric Murray <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: <[e-mail]>
In-Reply-To: <000701bddc29$99814e40$[e-mail]>
References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26368 for ietf-pkix-bks; Wed, 9 Sep 1998 14:15:07 -0700 (PDT)
Received: from relay1.eds.com (relay1.eds.com [199.228.142.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26364 for <[e-mail]>; Wed, 9 Sep 1998 14:15:05 -0700 (PDT)
Received: from nnsa.eds.com (nnsa.eds.com [192.85.154.30] (may be forged)) by relay1.eds.com (8.8.8/8.8.8) with ESMTP id RAA03200 for <[e-mail]>; Wed, 9 Sep 1998 17:20:25 -0400 (EDT)
Received: from usahm007.exmi01.exch.eds.com ([207.37.138.147]) by nnsa.eds.com (8.8.8/8.8.8) with ESMTP id RAA10704 for <[e-mail]>; Wed, 9 Sep 1998 17:19:54 -0400 (EDT)
Received: by USAHM007 with Internet Mail Service (5.5.2232.9) id <S1N8LKJ3>; Wed, 9 Sep 1998 17:19:50 -0400
Message-ID: <92D60A12331ED2119F5300A02461F047B20386@USAHM009>
From: "Corcoran, Dan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 9 Sep 1998 17:19:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25592 for ietf-pkix-bks; Wed, 9 Sep 1998 12:38:45 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25588 for <[e-mail]>; Wed, 9 Sep 1998 12:38:32 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA20000 for <[e-mail]>; Wed, 9 Sep 1998 15:43:40 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA19994 for <[e-mail]>; Wed, 9 Sep 1998 15:43:39 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA09823 for <[e-mail]>; Wed, 9 Sep 1998 15:42:59 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 09 Sep 1998 15:43:23 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Wed, 9 Sep 1998 15:44:33 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, "'Mike Smith'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:44:32 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Wednesday, September 09, 1998 3:12 PM
>To: 	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
>[e-mail]; [e-mail]
>Cc: 	[e-mail]
>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:[e-mail]]
>>> Sent:	Wednesday, September 09, 1998 1:16 PM
>>> To:	Mike Smith; [e-mail]; [e-mail]
>>> Cc:	[e-mail]
>>> 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: [e-mail]   phone: [phone]             LLLLLLLL
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25538 for ietf-pkix-bks; Wed, 9 Sep 1998 12:34:48 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25534 for <[e-mail]>; Wed, 9 Sep 1998 12:34:47 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id MAA29427; Wed, 9 Sep 1998 12:37:44 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA16381; Wed, 9 Sep 1998 12:39:30 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:39:46 -0400
Message-ID: <000701bddc29$99814e40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Sender: [e-mail]
Precedence: bulk

> 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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25446 for ietf-pkix-bks; Wed, 9 Sep 1998 12:20:41 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25442 for <[e-mail]>; Wed, 9 Sep 1998 12:20:40 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ8LG>; Wed, 9 Sep 1998 15:25:49 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A67@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:25:47 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 3:12 PM
> To:	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [e-mail]; [e-mail]
> Cc:	[e-mail]
> 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:[e-mail]]
> >> Sent:	Wednesday, September 09, 1998 1:16 PM
> >> To:	Mike Smith; [e-mail]; [e-mail]
> >> Cc:	[e-mail]
> >> 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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25432 for ietf-pkix-bks; Wed, 9 Sep 1998 12:19:09 -0700 (PDT)
Received: from slack.lne.com ([e-mail] [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25428 for <[e-mail]>; Wed, 9 Sep 1998 12:19:07 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id MAA11040; Wed, 9 Sep 1998 12:24:19 -0700
From: Eric Murray <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [e-mail] (Santosh Chokhani)
Date: Wed, 9 Sep 1998 12:24:18 -0700 (PDT)
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> from "Santosh Chokhani" at Sep 9, 98 01:44:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25299 for ietf-pkix-bks; Wed, 9 Sep 1998 12:07:59 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25295 for <[e-mail]>; Wed, 9 Sep 1998 12:07:58 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id MAA14051; Wed, 9 Sep 1998 12:13:05 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 09 Sep 1998 12:12:19 -0700
To: Santosh Chokhani <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Wednesday, September 09, 1998 1:16 PM
>> To:	Mike Smith; [e-mail]; [e-mail]
>> Cc:	[e-mail]
>> 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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25087 for ietf-pkix-bks; Wed, 9 Sep 1998 11:49:37 -0700 (PDT)
Received: from relay1.eds.com (relay1.eds.com [199.228.142.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25082 for <[e-mail]>; Wed, 9 Sep 1998 11:49:36 -0700 (PDT)
From: [e-mail]
Received: from nnsa.eds.com (nnsa.eds.com [192.85.154.30] (may be forged)) by relay1.eds.com (8.8.8/8.8.8) with ESMTP id OAA19121 for <[e-mail]>; Wed, 9 Sep 1998 14:54:51 -0400 (EDT)
Received: from usabhmg01.mail.gm.com ([207.37.138.86]) by nnsa.eds.com (8.8.8/8.8.8) with SMTP id OAA04446 for <[e-mail]>; Wed, 9 Sep 1998 14:54:20 -0400 (EDT)
Received: by usabhmg01.mail.gm.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 0525667A.006D0EAA ; Wed, 9 Sep 1998 14:51:11 -0500
X-Lotus-FromDomain: GM
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 14:51:15 -0500
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

For Option 2




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24576 for ietf-pkix-bks; Wed, 9 Sep 1998 10:59:45 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24572 for <[e-mail]>; Wed, 9 Sep 1998 10:59:44 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ8JL>; Wed, 9 Sep 1998 14:04:53 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A65@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Kurn, David'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 14:04:50 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 1:51 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 10:32 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> '[e-mail]'
> > 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>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24448 for ietf-pkix-bks; Wed, 9 Sep 1998 10:45:42 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24444 for <[e-mail]>; Wed, 9 Sep 1998 10:45:41 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA01170; Wed, 9 Sep 1998 10:50:49 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M2FMK>; Wed, 9 Sep 1998 10:50:45 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:50:42 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 10:32 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; '[e-mail]'
> 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>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24302 for ietf-pkix-bks; Wed, 9 Sep 1998 10:39:26 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24298 for <[e-mail]>; Wed, 9 Sep 1998 10:39:24 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ820>; Wed, 9 Sep 1998 13:44:33 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Phillip M Hallam-Baker'" <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:44:32 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 1:16 PM
> To:	Mike Smith; [e-mail]; [e-mail]
> Cc:	[e-mail]
> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24200 for ietf-pkix-bks; Wed, 9 Sep 1998 10:27:25 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24196 for <[e-mail]>; Wed, 9 Sep 1998 10:27:22 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ82Z>; Wed, 9 Sep 1998 13:32:31 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A62@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Kurn, David'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 13:32:28 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 1:12 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 9:53 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> '[e-mail]'
> > 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:[e-mail]]
> > > Sent:	Wednesday, September 09, 1998 12:16 PM
> > > To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> > > 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:[e-mail]]
> > > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > > To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > > To:	'[e-mail]'; '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:[e-mail]]
> > > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > ----------
> > > > > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > > > > 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.
> > > > > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23916 for ietf-pkix-bks; Wed, 9 Sep 1998 10:11:15 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23912 for <[e-mail]>; Wed, 9 Sep 1998 10:11:01 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA26409; Wed, 9 Sep 1998 10:13:52 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA05799; Wed, 9 Sep 1998 10:15:38 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:15:46 -0400
Message-ID: <001f01bddc15$7bf63980$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23875 for ietf-pkix-bks; Wed, 9 Sep 1998 10:07:22 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23871 for <[e-mail]>; Wed, 9 Sep 1998 10:07:21 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA25223; Wed, 9 Sep 1998 10:12:27 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M21Q3>; Wed, 9 Sep 1998 10:12:23 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:12:22 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 9:53 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 12:16 PM
> > To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> > 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:[e-mail]]
> > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > To:	'[e-mail]'; '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:[e-mail]]
> > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > ----------
> > > > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > > > 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.
> > > > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23614 for ietf-pkix-bks; Wed, 9 Sep 1998 09:48:09 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23601 for <[e-mail]>; Wed, 9 Sep 1998 09:48:05 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ81N>; Wed, 9 Sep 1998 12:53:13 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A61@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Kurn, David'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:53:12 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 12:16 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 8:27 AM
> > To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > To:	'[e-mail]'; '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:[e-mail]]
> > > > Sent: 	September 9, 1998 9:08 AM
> > > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > > Subject:	RE: forward & reverse elements - population
> > > > > 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > > 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.
> > > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23427 for ietf-pkix-bks; Wed, 9 Sep 1998 09:34:54 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23423 for <[e-mail]>; Wed, 9 Sep 1998 09:34:53 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Wed, 9 Sep 1998 17:38:36 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 09 Sep 1998 17:38:35 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23385 for ietf-pkix-bks; Wed, 9 Sep 1998 09:31:49 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23381 for <[e-mail]>; Wed, 9 Sep 1998 09:31:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 09 Sep 1998 09:36:53 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: New Extension Proposed: Method Of Authentication
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23254 for ietf-pkix-bks; Wed, 9 Sep 1998 09:18:59 -0700 (PDT)
Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23250 for <[e-mail]>; Wed, 9 Sep 1998 09:18:58 -0700 (PDT)
From: [e-mail]
Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id MAA10130 for <[e-mail]>; Wed, 9 Sep 1998 12:23:46 -0400 (EDT)
Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id MAA21732 for <[e-mail]>; Wed, 9 Sep 1998 12:23:44 -0400 (EDT)
Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 8525667A.005A117D ; Wed, 9 Sep 1998 12:23:47 -0400
X-Lotus-FromDomain: HWC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 12:23:30 -0400
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Alan Buffett
09/09/98 12:23 PM





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23155 for ietf-pkix-bks; Wed, 9 Sep 1998 09:10:39 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23151 for <[e-mail]>; Wed, 9 Sep 1998 09:10:38 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA17200; Wed, 9 Sep 1998 09:15:41 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M2DH3>; Wed, 9 Sep 1998 09:15:37 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:15:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 8:27 AM
> To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 11:02 AM
> > To:	'[e-mail]'; '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:[e-mail]]
> > > Sent: 	September 9, 1998 9:08 AM
> > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > 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.
> > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23089 for ietf-pkix-bks; Wed, 9 Sep 1998 09:03:17 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23085 for <[e-mail]>; Wed, 9 Sep 1998 09:03:16 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 09 Sep 1998 10:03:43 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 09 Sep 1998 10:03:36 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23032 for ietf-pkix-bks; Wed, 9 Sep 1998 09:00:26 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23028 for <[e-mail]>; Wed, 9 Sep 1998 09:00:24 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ75P>; Wed, 9 Sep 1998 12:05:31 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:05:30 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 8:44 PM
> To:	Santosh Chokhani
> Cc:	'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > To:   '[e-mail]'; 'Santosh Chokhani'
> > > Subject:      RE: forward & reverse elements - population
> > >
> > >
> > >
> > > > ----------
> > > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > > Sent:       September 8, 1998 10:05 AM
> > > > To:         'Sharon Boeyen'; '[e-mail]'
> > > > 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:[e-mail]
>       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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22846 for ietf-pkix-bks; Wed, 9 Sep 1998 08:41:31 -0700 (PDT)
Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22842 for <[e-mail]>; Wed, 9 Sep 1998 08:41:28 -0700 (PDT)
From: [e-mail]
Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id LAA05879 for <[e-mail]>; Wed, 9 Sep 1998 11:46:15 -0400 (EDT)
Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id LAA17566 for <[e-mail]>; Wed, 9 Sep 1998 11:46:13 -0400 (EDT)
Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 8525667A.0056A364 ; Wed, 9 Sep 1998 11:46:19 -0400
X-Lotus-FromDomain: HWC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 11:46:08 -0400
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

09/09/98 11:46 AM
Ross Smith
Ross Smith
Ross Smith
09/09/98 11:46 AM
09/09/98 11:46 AM





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22806 for ietf-pkix-bks; Wed, 9 Sep 1998 08:38:00 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22800 for <[e-mail]>; Wed, 9 Sep 1998 08:37:57 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id RAA29000; Wed, 9 Sep 1998 17:44:48 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id RAA21158; Wed, 9 Sep 1998 17:44:51 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 09 Sep 1998 17:44:12 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A5C@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > Sent: Tuesday, September 08, 1998 5:46 PM
> > To:   '[e-mail]'; 'Santosh Chokhani'
> > Subject:      RE: forward & reverse elements - population
> >
> >
> >
> > > ----------
> > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > Sent:       September 8, 1998 10:05 AM
> > > To:         'Sharon Boeyen'; '[e-mail]'
> > > 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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22663 for ietf-pkix-bks; Wed, 9 Sep 1998 08:21:38 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22659 for <[e-mail]>; Wed, 9 Sep 1998 08:21:36 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ7VA>; Wed, 9 Sep 1998 11:26:44 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A5F@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:26:42 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 11:02 AM
> To:	'[e-mail]'; '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:[e-mail]]
> > Sent: 	September 9, 1998 9:08 AM
> > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > 
> > > 
> > > > ----------
> > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > Sent: 	September 8, 1998 10:05 AM
> > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > 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.
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22485 for ietf-pkix-bks; Wed, 9 Sep 1998 08:01:33 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22479 for <[e-mail]>; Wed, 9 Sep 1998 08:01:31 -0700 (PDT)
Received: 	id LAA08881; Wed, 9 Sep 1998 11:04:43 -0400
Received: by gateway id <S2S6XZC1>; Wed, 9 Sep 1998 11:01:41 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:01:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 9, 1998 9:08 AM
> To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > Sent:	Tuesday, September 08, 1998 5:46 PM
> > To:	'[e-mail]'; 'Santosh Chokhani'
> > Subject:	RE: forward & reverse elements - population
> > 
> > 
> > 
> > > ----------
> > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > Sent: 	September 8, 1998 10:05 AM
> > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > 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.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21587 for ietf-pkix-bks; Wed, 9 Sep 1998 06:34:38 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21583 for <[e-mail]>; Wed, 9 Sep 1998 06:34:36 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id PAA17200 for <[e-mail]>; Wed, 9 Sep 1998 15:41:24 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id PAA20994 for <[e-mail]>; Wed, 9 Sep 1998 15:41:28 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 09 Sep 1998 15:40:49 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: For Option none
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21260 for ietf-pkix-bks; Wed, 9 Sep 1998 06:03:20 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21256 for <[e-mail]>; Wed, 9 Sep 1998 06:03:19 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ7R4>; Wed, 9 Sep 1998 09:08:26 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A5C@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:08:23 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Tuesday, September 08, 1998 5:46 PM
> To:	'[e-mail]'; 'Santosh Chokhani'
> Subject:	RE: forward & reverse elements - population
> 
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > Sent: 	September 8, 1998 10:05 AM
> > To: 	'Sharon Boeyen'; '[e-mail]'
> > 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18469 for ietf-pkix-bks; Wed, 9 Sep 1998 02:18:24 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18465 for <[e-mail]>; Wed, 9 Sep 1998 02:18:12 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFPT>; Wed, 9 Sep 1998 19:22:05 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC073861@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Mike Smith '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Phillip M Hallam-Baker '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OFF TOPIC ???? RE: Relational vs Directory Repository Models  (was RE: pathdevelopment complexity s)
Date: Wed, 9 Sep 1998 19:22:02 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thanks for the reply - comments in line. 

----------
From: Phillip M Hallam-Baker
To: Mike Smith; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02151 for ietf-pkix-bks; Tue, 8 Sep 1998 22:11:59 -0700 (PDT)
Received: from atlantic.valicert.com ([e-mail] [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA02147 for <[e-mail]>; Tue, 8 Sep 1998 22:11:57 -0700 (PDT)
Received: (qmail 8338 invoked from network); 9 Sep 1998 05:17:13 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 9 Sep 1998 05:17:13 -0000
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 22:17:20 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Posnak <[e-mail]>
CC: IETF PKIX <[e-mail]>
Subject: Re: OCSP in Chicago
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29394 for ietf-pkix-bks; Tue, 8 Sep 1998 20:42:56 -0700 (PDT)
Received: from 2gn.com (insectivora.unids.com [208.196.212.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29390 for <[e-mail]>; Tue, 8 Sep 1998 20:42:55 -0700 (PDT)
Received: from rodney (perm16-180.ij.net [209.4.16.180]) by 2gn.com (8.8.5/8.8.5) with SMTP id WAA25675; Tue, 8 Sep 1998 22:45:09 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 08 Sep 1998 23:44:10 -0400
To: Pavel Krylov <[e-mail]>
From: Rodney Thayer <[e-mail]>
Subject: Re: depth
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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          [e-mail]
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28554 for ietf-pkix-bks; Tue, 8 Sep 1998 18:18:59 -0700 (PDT)
Received: from ns1.auntmimi.net ([209.19.106.141]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28550 for <[e-mail]>; Tue, 8 Sep 1998 18:18:58 -0700 (PDT)
Received: from mail.xetex.com (1Cust101.tnt2.sfo3.da.uu.net [153.37.7.101]) by ns1.auntmimi.net (8.8.6/8.7.3) with SMTP id TAA21059; Tue, 8 Sep 1998 19:55:22 -0700 (PDT)
Received: from xetex.com by mail.xetex.com (SMI-8.6/SMI-SVR4) id SAA08850; Tue, 8 Sep 1998 18:20:05 -0700
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 18:27:51 -0700
From: Ed Posnak <[e-mail]>
Organization: Xetex Corporation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: IETF PKIX <[e-mail]>
Subject: Re: OCSP in Chicago
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26952 for ietf-pkix-bks; Tue, 8 Sep 1998 15:01:14 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26948 for <[e-mail]>; Tue, 8 Sep 1998 15:01:13 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id PAA24508 for <[e-mail]>; Tue, 8 Sep 1998 15:05:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Tue, 08 Sep 1998 18:07:20 -0400
To: "'[e-mail]'" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: For Option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26881 for ietf-pkix-bks; Tue, 8 Sep 1998 14:57:32 -0700 (PDT)
Received: from atlantic.valicert.com (atlantic.valicert.com [209.185.6.135] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26871 for <[e-mail]>; Tue, 8 Sep 1998 14:57:31 -0700 (PDT)
Received: (qmail 1104 invoked from network); 8 Sep 1998 22:02:24 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 8 Sep 1998 22:02:24 -0000
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 15:02:30 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF PKIX <[e-mail]>
Subject: OCSP in Chicago
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26782 for ietf-pkix-bks; Tue, 8 Sep 1998 14:46:42 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26778 for <[e-mail]>; Tue, 8 Sep 1998 14:46:40 -0700 (PDT)
Received: 	id RAA25638; Tue, 8 Sep 1998 17:49:05 -0400
Received: by gateway id <S2S6XV8N>; Tue, 8 Sep 1998 17:46:02 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 17:46:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 8, 1998 10:05 AM
> To: 	'Sharon Boeyen'; '[e-mail]'
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25829 for ietf-pkix-bks; Tue, 8 Sep 1998 13:02:56 -0700 (PDT)
Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA25825 for <[e-mail]>; Tue, 8 Sep 1998 13:02:55 -0700 (PDT)
Received: from mailext02.compaq.com by mailext02.compaq.com via smail with esmtp id <[e-mail]> for <[e-mail]>; Tue, 8 Sep 98 12:28:31 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.9 built 21-jan-98)
Received: from mail.compaq.com([207.18.199.32]) by mailext02.compaq.com with SMTP (peer mailint02.compaq.com[207.18.199.35]) id rcv009876; Tue, 8 Sep 1998 12:28:31 -0500 (CDT)
Received: from exchou-conn01.im.hou.compaq.com(really [172.18.22.253]) by mail.compaq.com via sendmail with esmtp id <[e-mail]> for <[e-mail]>; Tue, 8 Sep 98 12:28:04 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97)
Received: by EXCHOU-CONN01.im.hou.compaq.com with Internet Mail Service (5.5.1960.3) id <SQ38VL6L>; Tue, 8 Sep 1998 12:29:54 -0500
Message-ID: <[e-mail]>
From: "Fuerst, Neal" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FOR Option 2
Date: Tue, 8 Sep 1998 11:05:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thanks.

Neal Fuerst
Information Security Analyst
Compaq Computer Corporation
E-Mail: [e-mail]
Phone: [phone]
Pager: 713.509.4586

Entrust validation string: OMCO-KGMF-KQZN
"No matter how paranoid you are, you're not paranoid enough."



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25472 for ietf-pkix-bks; Tue, 8 Sep 1998 12:31:56 -0700 (PDT)
Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25468 for <[e-mail]>; Tue, 8 Sep 1998 12:31:55 -0700 (PDT)
Received: from napmsnoc02.shl.com (napmsnoc02.shl.com [159.249.47.179]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id OAA10756 for <[e-mail]>; Tue, 8 Sep 1998 14:21:38 -0500
Received: by napmsnoc02.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Tue, 8 Sep 1998 12:37:25 -0700
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'David Boyce'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population 
Date: Tue, 8 Sep 1998 12:37:04 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

in response to:
>From: 	David Boyce[SMTP:[e-mail]]
>"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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25463 for ietf-pkix-bks; Tue, 8 Sep 1998 12:31:26 -0700 (PDT)
Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25459 for <[e-mail]>; Tue, 8 Sep 1998 12:31:25 -0700 (PDT)
Received: from mrohub2.mro.dec.com (mrohub2.mro.dec.com [16.34.192.32]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with ESMTP id PAA00906 for <[e-mail]>; Tue, 8 Sep 1998 15:36:08 -0400 (EDT)
Received: by mrohub2.mro.dec.com with Internet Mail Service (5.5.1960.3) id <SQZT8L16>; Tue, 8 Sep 1998 15:36:09 -0400
Message-ID: <[e-mail]>
From: Daya Puls <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 15:36:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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: [phone], Eml: [e-mail]





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25403 for ietf-pkix-bks; Tue, 8 Sep 1998 12:22:07 -0700 (PDT)
Received: from 2keys.ca (cr318128-a.rchrd1.on.wave.home.com [24.112.92.155]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25399 for <[e-mail]>; Tue, 8 Sep 1998 12:22:06 -0700 (PDT)
From: [e-mail]
Received: (from rpierce@localhost) by 2keys.ca (8.8.7/8.8.7) id LAA16441 for [e-mail]; Tue, 8 Sep 1998 11:23:54 -0400
Message-Id: <[e-mail]>
Subject: For Option 2
To: [e-mail] (IETF PKIX)
Date: Tue, 8 Sep 1998 15:23:54 +0000 ()
Content-Type: text
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24057 for ietf-pkix-bks; Tue, 8 Sep 1998 10:11:58 -0700 (PDT)
Received: from lion.harrisbank.com (lion.harrisbank.com [204.148.73.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24053 for <[e-mail]>; Tue, 8 Sep 1998 10:11:54 -0700 (PDT)
From: [e-mail]
Received: by lion.harrisbank.com id AA24091 (SMTP Gateway 3.0 for [e-mail]); Tue, 8 Sep 1998 12:17:07 -0500
Received: by lion.harrisbank.com (Internal Mail Agent-1); Tue, 8 Sep 1998 12:17:07 -0500
To: ietf-pkiximcorg <[e-mail]>
Subject: For Option 2
Message-Id: <0056090002874024000002L942*@MHS>
Date: Tue, 8 Sep 1998 12:09:50 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23614 for ietf-pkix-bks; Tue, 8 Sep 1998 09:16:50 -0700 (PDT)
Received: from smtp-gw.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23610 for <[e-mail]>; Tue, 8 Sep 1998 09:16:49 -0700 (PDT)
Received: from mailhost.BayNetworks.COM ([141.251.211.49]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id MAA11637 for <[e-mail]>; Tue, 8 Sep 1998 12:21:27 -0400 (EDT)
Received: from ns2.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id SAA01073 for <[e-mail]>; Tue, 8 Sep 1998 18:20:50 +0200 (MET DST)
Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-nf0)  by ns2.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA00939; Tue, 8 Sep 98 12:20:50 EDT for [e-mail]
Received: from dgiglio.corpeast.baynetworks.com (bne-cnc-126.corpeast.baynetworks.com [132.245.134.126]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com for <[e-mail]>; Tue, 8 Sep 1998 12:20:46 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 08 Sep 1998 12:20:47 -0400
To: [e-mail]
From: [e-mail] (David Giglio)
Subject: For option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

___________________________________________________________________
David Giglio - Senior Product Manager 
Bay Networks, Inc.                Access Server Div.
M/S BL8-05                        [e-mail]
5 Federal Street                  978-916-4234 Office
Billerica, MA 01821               978-916-4782 Fax		

				


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23274 for ietf-pkix-bks; Tue, 8 Sep 1998 08:46:11 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23270 for <[e-mail]>; Tue, 8 Sep 1998 08:46:10 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA04410; Tue, 8 Sep 1998 08:49:02 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA13627; Tue, 8 Sep 1998 08:50:48 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Date: Tue, 8 Sep 1998 11:50:46 -0400
Message-ID: <004d01bddb40$7194a9c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk

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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23228 for ietf-pkix-bks; Tue, 8 Sep 1998 08:43:19 -0700 (PDT)
Received: from lion.harrisbank.com (lion.harrisbank.com [204.148.73.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23224 for <[e-mail]>; Tue, 8 Sep 1998 08:43:17 -0700 (PDT)
From: [e-mail]
Received: by lion.harrisbank.com id AA18645 (SMTP Gateway 3.0 for [e-mail]); Tue, 8 Sep 1998 10:48:27 -0500
Received: by lion.harrisbank.com (Internal Mail Agent-1); Tue, 8 Sep 1998 10:48:27 -0500
To: ietf-pkiximcorg <[e-mail]>
Subject: For Option 2
Message-Id: <0056090002871633000002L932*@MHS>
Date: Tue, 8 Sep 1998 10:41:10 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23117 for ietf-pkix-bks; Tue, 8 Sep 1998 08:34:16 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23113 for <[e-mail]>; Tue, 8 Sep 1998 08:34:14 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Tue, 8 Sep 1998 16:38:15 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: "PACHL, Jan" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: forward & reverse elements - population 
In-reply-to: Your message of "Tue, 08 Sep 1998 08:58:19 CDT." <c=US%a=MCI%p=SHL%l=[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Sep 1998 16:38:15 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk

"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:	[phone]		Richmond, Surrey, ENGLAND
I'net:	[e-mail]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23093 for ietf-pkix-bks; Tue, 8 Sep 1998 08:32:20 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23089 for <[e-mail]>; Tue, 8 Sep 1998 08:32:18 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Tue, 8 Sep 1998 16:36:44 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: Sharon Boeyen <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: forward & reverse elements - population 
In-reply-to: Your message of "Mon, 07 Sep 1998 20:01:30 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Sep 1998 16:36:43 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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:	[phone]		Richmond, Surrey, ENGLAND
I'net:	[e-mail]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22703 for ietf-pkix-bks; Tue, 8 Sep 1998 07:57:32 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22699 for <[e-mail]>; Tue, 8 Sep 1998 07:57:31 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04610; Tue, 8 Sep 1998 11:02:10 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-10.txt
Date: Tue, 08 Sep 1998 11:02:09 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail]
   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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22660 for ietf-pkix-bks; Tue, 8 Sep 1998 07:50:40 -0700 (PDT)
Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22656 for <[e-mail]>; Tue, 8 Sep 1998 07:50:38 -0700 (PDT)
From: [e-mail]
Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id KAA05514 for <[e-mail]>; Tue, 8 Sep 1998 10:55:00 -0400 (EDT)
Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id KAA11820 for <[e-mail]>; Tue, 8 Sep 1998 10:54:45 -0400 (EDT)
Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 85256679.0051E875 ; Tue, 8 Sep 1998 10:54:39 -0400
X-Lotus-FromDomain: HWC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 8 Sep 1998 10:55:28 -0400
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Jean Bernatchez
09/08/98 10:55 AM





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22068 for ietf-pkix-bks; Tue, 8 Sep 1998 07:00:36 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22063 for <[e-mail]>; Tue, 8 Sep 1998 07:00:32 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ5Q8>; Tue, 8 Sep 1998 10:05:31 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D248@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 10:05:30 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

comments in-line.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[e-mail]]
> Sent:	Monday, September 07, 1998 8:02 PM
> To:	'[e-mail]'
> 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:[e-mail]  Tel: [phone] 
> http://www.entrust.com            Fax: [phone] 
>        


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22025 for ietf-pkix-bks; Tue, 8 Sep 1998 06:55:51 -0700 (PDT)
Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22020 for <[e-mail]>; Tue, 8 Sep 1998 06:55:50 -0700 (PDT)
From: [e-mail]
Received: 	id JAA06138; Tue, 8 Sep 1998 09:57:04 -0400
Received: by gateway id <NWL91ZG3>; Tue, 8 Sep 1998 09:54:53 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Tue, 8 Sep 1998 10:03:01 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

To whom it may concern, 

For Option 2. 

Regards, 






J.P. Lachance 
Senior Systems Engineer 
PMO GOC PKI 
Communications Security Establishement 
Tel: [phone] 
Fax: [phone] 
Internet: [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22008 for ietf-pkix-bks; Tue, 8 Sep 1998 06:53:13 -0700 (PDT)
Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22004 for <[e-mail]>; Tue, 8 Sep 1998 06:53:11 -0700 (PDT)
Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id IAA57036 for <[e-mail]>; Tue, 8 Sep 1998 08:42:50 -0500
Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Tue, 8 Sep 1998 08:58:25 -0500
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 08:58:19 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>[ ... ]
>
>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?
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21745 for ietf-pkix-bks; Tue, 8 Sep 1998 06:07:58 -0700 (PDT)
Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA21741 for <[e-mail]>; Tue, 8 Sep 1998 06:07:57 -0700 (PDT)
From: [e-mail]
Received: 	id JAA05475; Tue, 8 Sep 1998 09:09:56 -0400
Received: by gateway id <NWL91ZFR>; Tue, 8 Sep 1998 09:07:45 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Tue, 8 Sep 1998 09:07:44 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21325 for ietf-pkix-bks; Tue, 8 Sep 1998 05:17:25 -0700 (PDT)
Received: from fin.gc.ca (cis-pec.fin.gc.ca [198.103.32.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21321 for <[e-mail]>; Tue, 8 Sep 1998 05:17:23 -0700 (PDT)
From: [e-mail]
Received: from connfax.fin.gc.ca ([172.17.22.10]) by sonic.fin.gc.ca with ESMTP id <19735>; Tue, 8 Sep 1998 08:20:39 -0400
Received: by CONNFAX with Internet Mail Service (5.5.1960.3) id <SQ2M0LBH>; Tue, 8 Sep 1998 08:22:19 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For option 2
Date: Mon, 7 Sep 1998 09:34:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20854 for ietf-pkix-bks; Tue, 8 Sep 1998 04:13:26 -0700 (PDT)
Received: from apollo.fedworld.gov (apollo.fedworld.gov [192.239.92.203]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20850 for <[e-mail]>; Tue, 8 Sep 1998 04:13:24 -0700 (PDT)
Received: from jdiduro.fedworld.gov ([208.232.200.69] (may be forged)) by apollo.fedworld.gov (8.8.6 (PHNE_14041)/8.8.6) with SMTP id HAA01052 for <[e-mail]>; Tue, 8 Sep 1998 07:17:43 -0400 (EDT)
Message-Id: <4.0.2.19980908072326.0443e530@192.239.92.203>
X-Sender: jdiduro@192.239.92.203
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 08 Sep 1998 07:23:34 -0400
To: [e-mail]
From: "John A. DiDuro" <[e-mail]>
Subject: for Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20761 for ietf-pkix-bks; Tue, 8 Sep 1998 04:07:11 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20755 for <[e-mail]>; Tue, 8 Sep 1998 04:07:09 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ537>; Tue, 8 Sep 1998 07:12:08 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E186603@WUHER>
From: Jeremy Bingham <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:12:07 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA08715 for ietf-pkix-bks; Tue, 8 Sep 1998 01:20:27 -0700 (PDT)
Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA08709 for <[e-mail]>; Tue, 8 Sep 1998 01:20:26 -0700 (PDT)
Received: from ben ([195.121.86.74]) by smtp03.wxs.nl (Netscape Messaging Server 3.54)  with SMTP id AAA16EA for <[e-mail]>; Tue, 8 Sep 1998 10:25:05 +0200
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 10:26:20 +0200
From: Ton van Lieshout <[e-mail]>
Reply-To: [e-mail]
Organization: Point Information Systems B.V.
X-Mailer: Mozilla 3.01C-WXS-16  (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: FOR OPTION 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

As an Entrust prtner, we vote for option 2.

Ton van Lieshout
Technical Director


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA29595 for ietf-pkix-bks; Mon, 7 Sep 1998 23:01:20 -0700 (PDT)
Received: from security.no ([193.71.64.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA29591 for <[e-mail]>; Mon, 7 Sep 1998 23:01:17 -0700 (PDT)
Received: by gateway.security.no id <26882>; Tue, 8 Sep 1998 07:01:48 +0100
Message-Id: <[e-mail]>
From: =?iso-8859-1?Q?Svein_L=F8seth?= <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:05:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA29592
Sender: [e-mail]
Precedence: bulk

---------------------------------------------------------------------------------------------------------------------------
Svein Løseth						Tlf.:    [phone]
Network Security AS					Fax:    [phone]
Gaustadalléen 21				    Dir. Line:    [phone]
N-0371 OSLO						GSM: [phone]
NORWAY						http://www.security.no




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26304 for ietf-pkix-bks; Mon, 7 Sep 1998 17:02:27 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA26299 for <[e-mail]>; Mon, 7 Sep 1998 17:02:26 -0700 (PDT)
Received: 	id UAA07858; Mon, 7 Sep 1998 20:04:33 -0400
Received: by gateway id <S2S6XSHF>; Mon, 7 Sep 1998 20:01:31 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: forward & reverse elements - population
Date: Mon, 7 Sep 1998 20:01:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA25807 for ietf-pkix-bks; Mon, 7 Sep 1998 15:26:02 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA25803 for <[e-mail]>; Mon, 7 Sep 1998 15:26:01 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 07 Sep 1998 15:30:57 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: PKIX freeware library coming soon (fwd)
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16002 for ietf-pkix-bks; Mon, 7 Sep 1998 11:55:40 -0700 (PDT)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15998 for <[e-mail]>; Mon, 7 Sep 1998 11:55:39 -0700 (PDT)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id PAA27888; Mon, 7 Sep 1998 15:00:41 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id PAA11891; Mon, 7 Sep 1998 15:00:39 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 85256678.006834C0 ; Mon, 7 Sep 1998 14:58:12 -0400
X-Lotus-FromDomain: FDC
To: Mike Smith <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 7 Sep 1998 11:59:43 -0700
Subject: Re: Relational vs Directory Repository Models (was RE: path development complexity s)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07642 for ietf-pkix-bks; Mon, 7 Sep 1998 10:30:30 -0700 (PDT)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07638 for <[e-mail]>; Mon, 7 Sep 1998 10:30:28 -0700 (PDT)
Received: by relay2.elvis.ru (8.8.5/1.25) id VAA29408; Mon, 7 Sep 1998 21:35:28 +0400 (MSK DST)
Message-ID: <[e-mail]>
X-Mailer: XFMail 1.3 [p0] on Solaris
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Mon, 07 Sep 1998 21:35:28 +0400 (MSK DST)
From: Pavel Krylov <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: depth
Sender: [e-mail]
Precedence: bulk

My question:
        What depth of certificate tree is exist now?? Average value?

Sharon, Santosh? 

---------------------------------------
Pavel V.Krylov          [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07055 for ietf-pkix-bks; Mon, 7 Sep 1998 10:23:19 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA07051 for <[e-mail]>; Mon, 7 Sep 1998 10:23:18 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 11:23:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 11:23:32 -0600
From: Mike Smith <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Re relational - and Dirs and all that
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06891 for ietf-pkix-bks; Mon, 7 Sep 1998 09:57:29 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06886 for <[e-mail]>; Mon, 7 Sep 1998 09:57:20 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFKM>; Tue, 8 Sep 1998 03:01:18 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07380E@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re relational - and Dirs and all that
Date: Tue, 8 Sep 1998 03:01:12 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA06888
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06469 for ietf-pkix-bks; Mon, 7 Sep 1998 09:01:23 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA06465 for <[e-mail]>; Mon, 7 Sep 1998 09:01:21 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 10:01:30 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 10:01:25 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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: [e-mail]; [e-mail] 
Cc: [e-mail]; [e-mail] 
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 <[e-mail]> 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; [e-mail] 
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.


                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06115 for ietf-pkix-bks; Mon, 7 Sep 1998 08:12:09 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06109 for <[e-mail]>; Mon, 7 Sep 1998 08:12:02 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFKB>; Tue, 8 Sep 1998 01:16:00 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC073803@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'Mike Smith '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Relational vs Directory Repository Models (was RE: pathdevelo pment complexity s)
Date: Tue, 8 Sep 1998 01:15:58 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 Mike - I am not sure if I understand your response as it mixes
technology statements.
So comments in line.

----------
From: Mike Smith
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
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 <[e-mail]> 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; [e-mail] 
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.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05809 for ietf-pkix-bks; Mon, 7 Sep 1998 07:27:40 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA05805 for <[e-mail]>; Mon, 7 Sep 1998 07:27:39 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 08:27:27 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 08:27:08 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Relational vs Directory Repository Models (was RE: path development complexity s)
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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; [e-mail] 
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.

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05623 for ietf-pkix-bks; Mon, 7 Sep 1998 06:56:10 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05618 for <[e-mail]>; Mon, 7 Sep 1998 06:56:06 -0700 (PDT)
Received: from d1o65.telia.com ([e-mail] [62.20.132.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id QAA03923; Mon, 7 Sep 1998 16:01:01 +0200 (CEST)
Received: from stefans (t2o65p95.telia.com [62.20.132.215]) by d1o65.telia.com (8.8.8/8.8.5) with SMTP id QAA03606; Mon, 7 Sep 1998 16:00:42 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 07 Sep 1998 15:58:39 +0200
To: "Aram Perez" <[e-mail]>, bob jueneman <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA05620
Sender: [e-mail]
Precedence: bulk

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
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05609 for ietf-pkix-bks; Mon, 7 Sep 1998 06:51:36 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05605 for <[e-mail]>; Mon, 7 Sep 1998 06:51:29 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFJX>; Mon, 7 Sep 1998 23:55:10 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0737F9@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Frank O'Dwyer '" <[e-mail]>
Cc: "'Dave Horvath '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Mon, 7 Sep 1998 23:55:08 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

 
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; [e-mail]
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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05308 for ietf-pkix-bks; Mon, 7 Sep 1998 05:51:16 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05304 for <[e-mail]>; Mon, 7 Sep 1998 05:50:53 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id OAA00330; Mon, 7 Sep 1998 14:55:39 +0200 (CEST)
Received: from stefans (t3o68p29.telia.com [62.20.139.29]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA28463; Mon, 7 Sep 1998 14:55:35 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 07 Sep 1998 14:53:16 +0200
To: Bill Brice <[e-mail]>, pkix <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Defining Non-Repudiation
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA05305
Sender: [e-mail]
Precedence: bulk

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. :)
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA01907 for ietf-pkix-bks; Mon, 7 Sep 1998 01:23:43 -0700 (PDT)
Received: from mailhost.dircon.co.uk (mailhost.dircon.co.uk [194.112.32.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA01902 for <[e-mail]>; Mon, 7 Sep 1998 01:23:41 -0700 (PDT)
Received: from dircon.co.uk (th-en133-079.pool.dircon.co.uk [194.112.53.79]) by mailhost.dircon.co.uk (8.9.1/8.8.7) with ESMTP id JAA13359 for <[e-mail]>; Mon, 7 Sep 1998 09:28:29 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 07 Sep 1998 09:35:36 +0100
From: Jorgen Moller <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.02 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27936 for ietf-pkix-bks; Sun, 6 Sep 1998 09:51:13 -0700 (PDT)
Received: from out5.ibm.net (out5.ibm.net [165.87.194.243]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27932 for <[e-mail]>; Sun, 6 Sep 1998 09:51:11 -0700 (PDT)
Received: from 730xcdt (slip139-92-24-251.por.uk.ibm.net [139.92.24.251]) by out5.ibm.net (8.8.5/8.6.9) with SMTP id QAA26578 for <[e-mail]>; Sun, 6 Sep 1998 16:56:09 GMT
From: "CliveBetteridge" <[e-mail]>
To: <[e-mail]>
Subject: Internet Directory Consortium call for participation in DirConnect3
Date: Sun, 6 Sep 1998 17:48:12 +0100
Message-ID: <01bdd9b6$22a8b940$LocalHost@730xcdt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01BDD9BE.846D2140"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

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:[e-mail] Ph: [phone]

http://www.opengroup.org/idc/ Fx: [phone]=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:[e-mail]</U></FONT><FONT color=3D#000000=20
face=3DArial>&nbsp;Ph: [phone]</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: [phone] =
</FONT></P></DIV></DIV></BODY></HTML>

------=_NextPart_000_00D9_01BDD9BE.846D2140--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA22327 for ietf-pkix-bks; Sat, 5 Sep 1998 13:17:35 -0700 (PDT)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA22323 for <[e-mail]>; Sat, 5 Sep 1998 13:17:33 -0700 (PDT)
Received: from [158.152.104.114] (helo=brd.ie) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zFOqt-0007Cf-00 for [e-mail]; Sat, 5 Sep 1998 20:22:31 +0000
Message-ID: <[e-mail]>
Date: Sat, 05 Sep 1998 21:20:16 +0100
From: "Frank O'Dwyer" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: path development complexity
References: <001201bdd8d7$6a2f60a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21055 for ietf-pkix-bks; Sat, 5 Sep 1998 07:09:49 -0700 (PDT)
Received: from mailsvr.basit.com (mailsvr.basit.com [128.209.2.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21051 for <[e-mail]>; Sat, 5 Sep 1998 07:09:43 -0700 (PDT)
Received: from klerer.basit.com (shiva119 [128.209.144.119]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id KAA28073 for <[e-mail]>; Sat, 5 Sep 1998 10:13:15 -0400 (EDT)
Message-ID: <001201bdd8d7$6a2f60a0$[e-mail]>
From: "Robert Klerer" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: path development complexity 
Date: Sat, 5 Sep 1998 10:13:36 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
To: Alan Lloyd <[e-mail]>
Cc: Dave Horvath <[e-mail]>; [e-mail] <[e-mail]>
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.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA17401 for ietf-pkix-bks; Sat, 5 Sep 1998 04:41:03 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA17397 for <[e-mail]>; Sat, 5 Sep 1998 04:41:02 -0700 (PDT)
Received: from [158.152.104.114] (helo=brd.ie) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zFGmh-0007jD-00; Sat, 5 Sep 1998 11:45:40 +0000
Message-ID: <[e-mail]>
Date: Sat, 05 Sep 1998 12:44:06 +0100
From: "Frank O'Dwyer" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: Dave Horvath <[e-mail]>, [e-mail]
Subject: Re: path development complexity (was Re: What the straw poll mean s)
References: <D1A949D4508DD1119C8100400533BEDC05D489@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA16384 for ietf-pkix-bks; Sat, 5 Sep 1998 04:27:42 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA16371 for <[e-mail]>; Sat, 5 Sep 1998 04:27:35 -0700 (PDT)
Received: from patrik (dialup185-1-22.swipnet.se [130.244.185.22])  by mb05.swip.net (8.8.8/8.8.8) with SMTP  id NAA10743;  Sat, 5 Sep 1998 13:32:17 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: Patrik [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.44 (Beta)
Date: Sat, 05 Sep 1998 13:32:45 +0200
To: WHenry <[e-mail]>
From: Patrik Nilsson <[e-mail]>
Subject: RE: Heads Up - Historic digital signing ceremony
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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:	[e-mail]
>> 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:[e-mail]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[e-mail]
>> > 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.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA11433 for ietf-pkix-bks; Fri, 4 Sep 1998 17:15:01 -0700 (PDT)
Received: from nick.arc.nasa.gov (nick.arc.nasa.gov [143.232.48.121]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA11426 for <[e-mail]>; Fri, 4 Sep 1998 17:15:00 -0700 (PDT)
Received: from [128.102.131.45] (hotdog.arc.nasa.gov [128.102.131.45]) by nick.arc.nasa.gov (8.8.7/8.8.7) with ESMTP id RAA16856 for <[e-mail]>; Fri, 4 Sep 1998 17:19:49 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011726b216213153a7@[128.102.131.45]>
Date: Fri, 4 Sep 1998 17:21:49 -0800
To: [e-mail]
From: Paul Ma <[e-mail]>
Subject: FOR Option2
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10422 for ietf-pkix-bks; Fri, 4 Sep 1998 14:44:40 -0700 (PDT)
Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10418 for <[e-mail]>; Fri, 4 Sep 1998 14:44:39 -0700 (PDT)
Received: from mailtst1 (mailtst1.us.oracle.com [144.25.88.179]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id OAA16968 for <[e-mail]>; Fri, 4 Sep 1998 14:49:32 -0700 (PDT)
Received:  from inferno by mailtst1 with SMTP (SMI-8.6/37.9) id OAA09210; Fri, 4 Sep 1998 14:47:47 -0700
From: "Surendra Reddy" <[e-mail]>
To: <[e-mail]>
Subject:  For option 2
Date: Fri, 4 Sep 1998 14:49:11 +0100
Message-ID: <001101bdd80a$cb797850$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10255 for ietf-pkix-bks; Fri, 4 Sep 1998 14:17:50 -0700 (PDT)
Received: from docws007.shl.com (docws007.shl.com [159.249.56.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10251 for <[e-mail]>; Fri, 4 Sep 1998 14:17:49 -0700 (PDT)
Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws007.shl.com (8.9.1/8.9.1) with SMTP id QAA03170 for <[e-mail]>; Fri, 4 Sep 1998 16:28:37 -0500
Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Fri, 4 Sep 1998 16:22:39 -0500
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'WHenry'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 16:22:33 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA10252
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Friday, September 04, 1998 1:48 PM
>To: 	'Kurn, David'
>Cc: 	'[e-mail]'
>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:	[e-mail]
>> 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:[e-mail]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[e-mail]
>> > 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.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA10107 for ietf-pkix-bks; Fri, 4 Sep 1998 13:58:54 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA10103 for <[e-mail]>; Fri, 4 Sep 1998 13:58:54 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA23121 for <[e-mail]>; Fri, 4 Sep 1998 14:03:48 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04MGZZ7>; Fri, 4 Sep 1998 14:03:01 -0700
Message-ID: <[e-mail]>
From: "Salmond, Kent" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:57 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA10021 for ietf-pkix-bks; Fri, 4 Sep 1998 13:52:28 -0700 (PDT)
Received: from portal.visa.com (portal.visa.com [198.80.42.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA10017 for <[e-mail]>; Fri, 4 Sep 1998 13:52:26 -0700 (PDT)
Received: by portal.visa.com id NAA11445 (InterLock SMTP Gateway 3.0 for [e-mail]); Fri, 4 Sep 1998 13:57:19 -0700
Received: by portal.visa.com (Protected-side Proxy Mail Agent-1); Fri, 4 Sep 1998 13:57:19 -0700
Message-Id: <[e-mail]>
From: "Smith, David" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 13:56:51 -0700 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08871 for ietf-pkix-bks; Fri, 4 Sep 1998 12:18:09 -0700 (PDT)
Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA08867 for <[e-mail]>; Fri, 4 Sep 1998 12:18:07 -0700 (PDT)
Received: from m5pqp [195.99.53.190]  by tungsten.btinternet.com with smtp (Exim 1.70 #1) id 0zF1Ox-0001O7-00; Fri, 4 Sep 1998 20:20:07 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 04 Sep 1998 20:24:15 +0100
To: "[e-mail]" <[e-mail]>
From: John Hughes <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

 -------------------------------------------------------------------
| John Hughes             [e-mail]                 |
| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
|                         Home Fax No:           [phone]  |
|                         Main Office Tel:       [phone] |
| www.entegrity.com       Mobile:                [phone]   |
 ------------------------------------------------------------------- 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08796 for ietf-pkix-bks; Fri, 4 Sep 1998 12:10:32 -0700 (PDT)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08791 for <[e-mail]>; Fri, 4 Sep 1998 12:10:30 -0700 (PDT)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.1960.3) id <RDRTQCTS>; Fri, 4 Sep 1998 14:16:49 -0500
Message-ID: <[e-mail]>
From: Bill Brice <[e-mail]>
To: "'Kurn, David'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 14:16:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: Friday, September 04, 1998 11:43 AM
> To: [e-mail]
> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA08431 for ietf-pkix-bks; Fri, 4 Sep 1998 11:27:08 -0700 (PDT)
Received: from labcalserver.labcal.qc.ca (labcal.qc.ca [199.45.69.189]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA08423 for <[e-mail]>; Fri, 4 Sep 1998 11:26:57 -0700 (PDT)
Received: from jfsauriol (ott-on3-07.netcom.ca [207.181.90.135]) by labcalserver.labcal.qc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id S1MV02KP; Fri, 4 Sep 1998 14:37:38 -0400
Reply-To: <[e-mail]>
From: "JF Sauriol" <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:31:02 -0400
Message-ID: <001101bdd832$2bb357a0$0500a8c0@jfsauriol>
MIME-Version: 1.0
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="winmail.dat"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
X-MS-TNEF-Correlator: 00000000EE66A839D9EFBB118ED2727702A12BC664302300
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

eJ8+IgISAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAAM4HCQAEAA4AHgAAAAUAEwEB
A5AGAAAEAAAmAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAADQAAAEZvciBPcHRpb24gMgAAAAACAXEAAQAAABYAAAABvdgyJWrd9tAMRAAR0qKdAAAAAADe
AAACAR0MAQAAABwAAABTTVRQOkpGU0FVUklPTEBMQUJDQUwuUUMuQ0EACwABDgAAAABAAAYOAMQv
BjLYvQECAQoOAQAAABgAAAAAAAAA7maoOdnvuxGO0nJ3AqErxsKAAAALAB8OAQAAAAMABhAAAAAA
AwAHEAAAAAAeAAgQAQAAAAUAAADYIwR4AAAAAAMAEBAAAgAAAwAREDERAHgLAACACCAGAAAAAADA
AAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAgg
BgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAA
AAQAAAA4LjUAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAA
AAAARgAAAAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAA
AAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEA
AAAAAAAAHgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAA
AMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAMaACyAGAAAAAADAAAAAAAAARgAAAAAAiAAA
AAAAAAsAyIALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAACwDugAggBgAAAAAAwAAAAAAAAEYA
AAAABoUAAAAAAAALAPKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAIB+A8BAAAAEAAAAO5m
qDnZ77sRjtJydwKhK8YCAfoPAQAAABAAAADuZqg52e+7EY7ScncCoSvGAgH7DwEAAABkAAAAAAAA
ADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAARDpc
V09SS1xPdXRsb29rIEZpbGVzXGpmc2F1cmlvbC1sYWJjYWwucHN0AAMA/g8FAAAAAwANNP03AAAC
AX8AAQAAADEAAAAwMDAwMDAwMEVFNjZBODM5RDlFRkJCMTE4RUQyNzI3NzAyQTEyQkM2NjQzMDIz
MDAAAAAAXJI=



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08215 for ietf-pkix-bks; Fri, 4 Sep 1998 10:58:33 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08211 for <[e-mail]>; Fri, 4 Sep 1998 10:58:32 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZX7Z>; Fri, 4 Sep 1998 14:02:54 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E0D95CF@WUHER>
From: Larry Shomo <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:52 -0400
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Lawrence P. Shomo
Vice President

********************************
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia, 22102-3305
[phone], x202 (Phone)
[phone] (Fax)
[e-mail] (Email)

********************************



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08085 for ietf-pkix-bks; Fri, 4 Sep 1998 10:41:07 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08080 for <[e-mail]>; Fri, 4 Sep 1998 10:41:06 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQffkh26911; Fri, 4 Sep 1998 13:45:50 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRBN14>; Fri, 4 Sep 1998 13:48:02 -0400
Message-ID: <[e-mail]>
From: WHenry <[e-mail]>
To: "'Kurn, David'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 13:48:00 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA08082
Sender: [e-mail]
Precedence: bulk

 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:	[e-mail]
> 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:[e-mail]]
> > Sent:	Friday, September 04, 1998 9:12 AM
> > To:	[e-mail]
> > 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07931 for ietf-pkix-bks; Fri, 4 Sep 1998 10:27:06 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07927 for <[e-mail]>; Fri, 4 Sep 1998 10:27:05 -0700 (PDT)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA19928 for <[e-mail]>; Fri, 4 Sep 1998 10:19:27 -0700
Received: from scv1.apple.com (scv1.apple.com [17.128.100.139]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id <[e-mail]>; Fri, 04 Sep 1998 10:17:29 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA43944; Fri, 4 Sep 1998 10:17:28 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) 
Date: Fri, 04 Sep 1998 10:17:26 -0700
Subject: Re: Digital signature and non-repudiation key usage bits
From: "Aram Perez" <[e-mail]>
To: Stefan Santesson <[e-mail]>, bob jueneman <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07483 for ietf-pkix-bks; Fri, 4 Sep 1998 09:39:19 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07479 for <[e-mail]>; Fri, 4 Sep 1998 09:39:17 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA18402 for <[e-mail]>; Fri, 4 Sep 1998 09:44:09 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04MG4T0>; Fri, 4 Sep 1998 09:43:22 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: [e-mail]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 09:43:21 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA07480
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, September 04, 1998 9:12 AM
> To:	[e-mail]
> 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07475 for ietf-pkix-bks; Fri, 4 Sep 1998 09:38:56 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07471 for <[e-mail]>; Fri, 4 Sep 1998 09:38:55 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id SAA19894; Fri, 4 Sep 1998 18:43:31 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA00279; Fri, 4 Sep 1998 18:43:30 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA12254; Fri, 4 Sep 1998 18:43:29 +0200
Date: Fri, 4 Sep 1998 18:43:29 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: What the straw poll means
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

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?
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07312 for ietf-pkix-bks; Fri, 4 Sep 1998 09:17:45 -0700 (PDT)
Received: from ewa-canada.com (ewa-canada.com [209.146.131.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07308 for <[e-mail]>; Fri, 4 Sep 1998 09:17:41 -0700 (PDT)
Received: by ewa-canada.com from localhost (router,SLMail V2.6); Fri, 04 Sep 1998 12:21:59 -0400
Received: by ewa-canada.com from def23.ewa-canada.com (209.146.131.23::mail daemon,SLMail V2.6); Fri, 04 Sep 1998 12:21:58 -0400
Message-Id: <[e-mail]>
X-Sender: "Erin Connor" <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 04 Sep 1998 12:18:06 -0400
To: [e-mail]
From: "Erin Connor" <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

--------------------------------------------------------------------------
Erin Connor                             EWA-Canada Ltd.
Voice:  [phone] Ext 234       Suite 1600 - 275 Slater Street
Fax:    [phone]               Ottawa, Ontario, Canada  K1P 5H9
mailto:[e-mail]         	http://www.ewa-canada.com

** Visit the CanCERT website at  http://cancert.ca ***
--------------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07186 for ietf-pkix-bks; Fri, 4 Sep 1998 09:05:35 -0700 (PDT)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07182 for <[e-mail]>; Fri, 4 Sep 1998 09:05:33 -0700 (PDT)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.1960.3) id <RDRTQCSX>; Fri, 4 Sep 1998 11:11:53 -0500
Message-ID: <[e-mail]>
From: Bill Brice <[e-mail]>
To: [e-mail]
Subject: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 11:11:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA07183
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07000 for ietf-pkix-bks; Fri, 4 Sep 1998 08:48:15 -0700 (PDT)
Received: from mailsvr.basit.com (mailsvr.basit.com [128.209.2.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06996 for <[e-mail]>; Fri, 4 Sep 1998 08:48:13 -0700 (PDT)
Received: from klerer.basit.com (shiva118 [128.209.144.118]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id LAA18007 for <[e-mail]>; Fri, 4 Sep 1998 11:51:49 -0400 (EDT)
Message-ID: <008c01bdd81b$faa3d740$[e-mail]>
From: "Robert Klerer" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: path development complexity (was Re: What the straw poll means)
Date: Fri, 4 Sep 1998 11:52:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
To: Dave Horvath <[e-mail]>
Cc: [e-mail] <[e-mail]>
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.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06761 for ietf-pkix-bks; Fri, 4 Sep 1998 08:25:50 -0700 (PDT)
Received: from nad.ic.gc.ca (nad.ic.gc.ca [192.197.184.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06757 for <[e-mail]>; Fri, 4 Sep 1998 08:25:47 -0700 (PDT)
Message-Id: <[e-mail]>
Received: by nad.ic.gc.ca with Internet Mail Service (5.5.1960.3) id <SGCYYQ51>; Fri, 4 Sep 1998 11:26:42 -0400
From: "Power, Michael: LEG" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:24:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06565 for ietf-pkix-bks; Fri, 4 Sep 1998 08:10:35 -0700 (PDT)
Received: from gatekeeper.domus.com (gatekeeper.domus.com [198.166.58.193]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA06561 for <[e-mail]>; Fri, 4 Sep 1998 08:10:32 -0700 (PDT)
Received: from dns_int.domus.com by gatekeeper1.domus.com (8.6.13/200.19.1.1) id LAA13793; Fri, 4 Sep 1998 11:03:44 -0400
Received: (from smap@localhost) by dns_int.domus.com (8.6.8/8.6.6) id KAA05253 for <[e-mail]>; Fri, 4 Sep 1998 10:31:52 -0400
Received: from wpgate.domus.com(198.166.59.10) by dns_int.domus.com via smap (V1.3) id sma005251; Fri Sep  4 10:31:44 1998
Received: from DOMUS-Message_Server by wpgate.domus.com with Novell_GroupWise; Fri, 04 Sep 1998 11:03:54 -0400
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 04 Sep 1998 11:03:15 -0400
From: Pamela Grannum <[e-mail]>
To: [e-mail]
Subject: For Option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06518 for ietf-pkix-bks; Fri, 4 Sep 1998 08:07:16 -0700 (PDT)
Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA06514 for <[e-mail]>; Fri, 4 Sep 1998 08:07:14 -0700 (PDT)
From: [e-mail]
Received: 	id LAA03483; Fri, 4 Sep 1998 11:08:05 -0400
Received: by gateway id <NWL91YVT>; Fri, 4 Sep 1998 11:05:15 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:13:27 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

My vote is for Option 2 of the LDAP schema companion paper.


Edmond P. van Hees
GOC PKI Security Engineer
telephone: [phone] 
Fax: [phone]
E-Mail:  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06435 for ietf-pkix-bks; Fri, 4 Sep 1998 07:55:22 -0700 (PDT)
Received: from us.checkpoint.com (oak.us.checkpoint.com [206.86.35.94]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06431 for <[e-mail]>; Fri, 4 Sep 1998 07:55:21 -0700 (PDT)
Received: from 101.101.101.103 ([207.245.220.71]) by us.checkpoint.com (8.9.1/8.9.1/CPoak/1.3.3) with SMTP id IAA06119 for <[e-mail]>; Fri, 4 Sep 1998 08:00:05 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 04 Sep 1998 10:37:54 -0700
To: [e-mail]
From: "Steve O'Neil" <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06318 for ietf-pkix-bks; Fri, 4 Sep 1998 07:32:22 -0700 (PDT)
Received: from mail.storm.ca ([e-mail] [207.245.225.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06314 for <[e-mail]>; Fri, 4 Sep 1998 07:32:20 -0700 (PDT)
Received: from treebeard (dial02p48.ottawa.storm.ca [207.245.246.112]) by mail.storm.ca (8.8.8/8.8.8) with SMTP id KAA04568 for <[e-mail]>; Fri, 4 Sep 1998 10:36:18 -0400 (EDT)
Message-ID: <00cf01bdd811$0b0a25e0$70f6f5cf@treebeard>
Reply-To: "Mark Scherling" <[e-mail]>
From: "Mark Scherling" <[e-mail]>
To: <[e-mail]>
Subject: option 2
Date: Fri, 4 Sep 1998 10:33:53 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06293 for ietf-pkix-bks; Fri, 4 Sep 1998 07:30:01 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06286 for <[e-mail]>; Fri, 4 Sep 1998 07:29:59 -0700 (PDT)
Received: by gateway.r3.ch id <6806>; Fri, 4 Sep 1998 16:36:05 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Sharon Boeyen <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:30:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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.





>  
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06081 for ietf-pkix-bks; Fri, 4 Sep 1998 07:03:55 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06075 for <[e-mail]>; Fri, 4 Sep 1998 07:03:52 -0700 (PDT)
Received: by gateway.r3.ch id <6813>; Fri, 4 Sep 1998 16:10:03 +0100
Message-Id: <[e-mail]>
From: Rene Eberhard <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 15:06:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Best regards Rene



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06072 for ietf-pkix-bks; Fri, 4 Sep 1998 07:02:43 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06068 for <[e-mail]>; Fri, 4 Sep 1998 07:02:41 -0700 (PDT)
Received: by gateway.r3.ch id <6814>; Fri, 4 Sep 1998 16:08:52 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:02:50 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 4, 1998 9:19 AM
> To: 	'Bill Burr'; Santosh Chokhani
> Cc: 	[e-mail]
> 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
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05948 for ietf-pkix-bks; Fri, 4 Sep 1998 06:41:14 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05944 for <[e-mail]>; Fri, 4 Sep 1998 06:41:12 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZXT1>; Fri, 4 Sep 1998 09:45:37 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D230@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: [e-mail], Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:45:36 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Comments in line.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[e-mail]]
> Sent:	Friday, September 04, 1998 1:03 PM
> To:	Sharon Boeyen
> Cc:	[e-mail]; '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:[e-mail]
>       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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05674 for ietf-pkix-bks; Fri, 4 Sep 1998 06:18:54 -0700 (PDT)
Received: from att.com (kcgw2.att.com [192.128.133.152]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA05670 for <[e-mail]>; Fri, 4 Sep 1998 06:18:53 -0700 (PDT)
Received: from kcig2.fw.att.com by kcgw2.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-pkix sender att.com!jayhawk (att.com!jayhawk); Fri Sep  4 08:02 CDT 1998
Received: from qsun.ho.att.com (qsunn.ho.att.com [135.16.30.2]) by kcig2.fw.att.com (AT&T/IPNS/GW-1.0) with SMTP id IAA12147 for <[e-mail]>; Fri, 4 Sep 1998 08:23:37 -0500 (CDT)
Received: from sloop.local.windrose.omaha.ne.us by qsun.ho.att.com (SMI-8.6/EMS-1.2 sol2) id JAA18228; Fri, 4 Sep 1998 09:23:33 -0400
From: "Ryan Moats" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <002201bdd807$903c8d20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05652 for ietf-pkix-bks; Fri, 4 Sep 1998 06:15:08 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05648 for <[e-mail]>; Fri, 4 Sep 1998 06:15:06 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZXSN>; Fri, 4 Sep 1998 09:19:30 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D22E@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:19:29 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA05649
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, September 04, 1998 9:21 AM
> To:	Santosh Chokhani
> Cc:	[e-mail]
> 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:[e-mail]]
> >> Sent:	Friday, September 04, 1998 7:20 AM
> >> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
> >> 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
> >> 
> >> 
> >> 
> >> 
> >> 
> >> -------------------------------------------------------------------
> >> Stefan Santesson                <[e-mail]>
> >> Accurata Systemsäkerhet AB     
> >> Lotsgatan 27 D                  Tel. [phone]              
> >> 216 42  Malmö                   Fax. [phone]              
> >> Sweden                        Mobile [phone]
> >> 
> >> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> >> -------------------------------------------------------------------
> >
> >
> Regards,
> 
> Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05612 for ietf-pkix-bks; Fri, 4 Sep 1998 06:12:19 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA05608 for <[e-mail]>; Fri, 4 Sep 1998 06:12:17 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id JAA11951; Fri, 4 Sep 1998 09:16:57 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 04 Sep 1998 09:20:36 -0400
To: Santosh Chokhani <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: RE: What the straw poll means
Cc: [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E16D22D@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA05609
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Friday, September 04, 1998 7:20 AM
>> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
>> 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
>> 
>> 
>> 
>> 
>> 
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB     
>> Lotsgatan 27 D                  Tel. [phone]              
>> 216 42  Malmö                   Fax. [phone]              
>> Sweden                        Mobile [phone]
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>
Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05206 for ietf-pkix-bks; Fri, 4 Sep 1998 05:53:27 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05201 for <[e-mail]>; Fri, 4 Sep 1998 05:53:26 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA12341 for <[e-mail]>; Fri, 4 Sep 1998 08:58:18 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA12333 for <[e-mail]>; Fri, 4 Sep 1998 08:58:17 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA14842 for <[e-mail]>; Fri, 4 Sep 1998 08:57:41 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 04 Sep 1998 08:58:32 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Fri, 4 Sep 1998 08:58:26 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
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
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Thursday, September 03, 1998 4:41 PM
>To: 	Carlisle Adams
>Cc: 	[e-mail]
>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:[e-mail]]
>> > Sent:         Thursday, September 03, 1998 12:14 PM
>> > To:   [e-mail]
>> > Cc:   [e-mail]
>> > 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.				        [e-mail]
>1215 Terra Bella Ave.		              http://www.valicert.com
>Mountain View, CA 94043-1833
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA04409 for ietf-pkix-bks; Fri, 4 Sep 1998 05:07:00 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04405 for <[e-mail]>; Fri, 4 Sep 1998 05:06:58 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZXQV>; Fri, 4 Sep 1998 08:11:21 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D22D@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 08:11:19 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA04406
Sender: [e-mail]
Precedence: bulk

Stefan:

I agree with every thing you say in this mail message,

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[e-mail]]
> Sent:	Friday, September 04, 1998 7:20 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
> 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
> 
> 
> 
> 
> 
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB     
> Lotsgatan 27 D                  Tel. [phone]              
> 216 42  Malmö                   Fax. [phone]              
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04107 for ietf-pkix-bks; Fri, 4 Sep 1998 04:21:09 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04103 for <[e-mail]>; Fri, 4 Sep 1998 04:21:07 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Fri, 4 Sep 1998 12:24:48 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
cc: Sharon Boeyen <[e-mail]>, [e-mail], "'Santosh Chokhani'" <[e-mail]>
Subject: Re: What the straw poll means 
In-reply-to: Your message of "Fri, 04 Sep 1998 10:03:20 PDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 04 Sep 1998 12:24:47 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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:	[phone]		Richmond, Surrey, ENGLAND
I'net:	[e-mail]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04089 for ietf-pkix-bks; Fri, 4 Sep 1998 04:17:27 -0700 (PDT)
Received: from maila.telia.com ([e-mail] [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04085 for <[e-mail]>; Fri, 4 Sep 1998 04:17:24 -0700 (PDT)
Received: from stefans (t3o68p109.telia.com [62.20.139.109]) by maila.telia.com (8.8.8/8.8.8) with SMTP id NAA11442; Fri, 4 Sep 1998 13:22:05 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 04 Sep 1998 13:19:51 +0200
To: Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA04086
Sender: [e-mail]
Precedence: bulk

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





-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA02805 for ietf-pkix-bks; Fri, 4 Sep 1998 03:18:52 -0700 (PDT)
Received: from maila.telia.com ([e-mail] [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA02801 for <[e-mail]>; Fri, 4 Sep 1998 03:18:50 -0700 (PDT)
Received: from stefans (t4o68p88.telia.com [62.20.139.208]) by maila.telia.com (8.8.8/8.8.8) with SMTP id MAA14602; Fri, 4 Sep 1998 12:22:18 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 04 Sep 1998 12:20:04 +0200
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA02802
Sender: [e-mail]
Precedence: bulk

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


-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA29009 for ietf-pkix-bks; Fri, 4 Sep 1998 02:49:39 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA29005 for <[e-mail]>; Fri, 4 Sep 1998 02:49:37 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090405534560:1457  for <[e-mail]> ; Fri, 4 Sep 1998 05:53:45 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090405534560:1457  for <[e-mail]> ; Fri, 4 Sep 1998 05:53:45 -0400 
X-Lotus-FromDomain: IRIS
Message-ID: <[e-mail]>
Date: Fri, 4 Sep 1998 05:56:52 -0400
Mime-Version: 1.0
x-notes-Form: Memo
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: [e-mail]
Precedence: bulk

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Dave Horvath <[e-mail]> 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

UmVjZWl2ZWQ6IGZyb20gYXJpc3RhLmlyaXMuY29tIChbOS45NS42NS4xNV0pDQogICAgICAgICAg
YnkgZXBpYy5pcmlzLmNvbSAoTG90dXMgRG9taW5vIEJ1aWxkIDE2MSAoQmV0YSkpDQogICAgICAg
ICAgd2l0aCBTTVRQIGlkIDE5OTgwOTAzMjIwMDAxNTk6MTQyOCANCiAgICAgICAgICBmb3IgPGRh
dmVAY2hyb21hdGl4LmNvbT4gLA0KICAgICAgICAgICAgICA8aWV0Zi1wa2ljQGltYy5vcmc+IDsN
CiAgICAgICAgICBUaHUsIDMgU2VwIDE5OTggMjI6MDA6MDEgLTA0MDAgDQpSZWNlaXZlZDogZnJv
bSBhcmlzdGEuaXJpcy5jb20gKFs5Ljk1LjY1LjE1XSkNCiAgICAgICAgICBieSBlcGljLmlyaXMu
Y29tIChMb3R1cyBEb21pbm8gQnVpbGQgMTYxIChCZXRhKSkNCiAgICAgICAgICB3aXRoIFNNVFAg
aWQgMTk5ODA5MDMyMjAwMDE1OToxNDI4IA0KICAgICAgICAgIGZvciA8ZGF2ZUBjaHJvbWF0aXgu
Y29tPiAsDQogICAgICAgICAgICAgIDxpZXRmLXBraWNAaW1jLm9yZz4gOw0KICAgICAgICAgIFRo
dSwgMyBTZXAgMTk5OCAyMjowMDowMSAtMDQwMCANClgtTG90dXMtRnJvbURvbWFpbjogSVJJUw0K
RnJvbTogSm9obl9XcmF5QGlyaXMuY29tDQpUbzogRGF2ZSBIb3J2YXRoIDxkYXZlQGNocm9tYXRp
eC5jb20+DQpjYzogaWV0Zi1wa2ljQGltYy5vcmcNCk1lc3NhZ2UtSUQ6IDw4NTI1NjY3NS4wMDBC
MjM1Ny4wMEBhcmlzdGEuaXJpcy5jb20+DQpEYXRlOiBUaHUsIDMgU2VwIDE5OTggMTk6NTY6MTQg
LTA0MDANClN1YmplY3Q6IFJlOiBXaGF0IHRoZSBzdHJhdyBwb2xsIG1lYW5zDQpNaW1lLVZlcnNp
b246IDEuMA0KeC1ub3Rlcy0kMjROb3RlSGFzTmF0aXZlTUlNRTogMQ0KeC1ub3Rlcy1TTVRQT3Jp
Z2luYXRvcjogSm9obl9XcmF5QGlyaXMuY29tDQp4LW5vdGVzLSQyNFVwZGF0ZWRCeTogQ049RXBp
Yy9PPUlyaXMNCngtbm90ZXMtUm91dGVTZXJ2ZXJzOiBDTj1FcGljL089SXJpcw0KeC1ub3Rlcy1N
YWlsU2F2ZWRGb3JtOiBNZW1vDQp4LW5vdGVzLUZvcm06IE5vbkRlbGl2ZXJ5IFJlcG9ydA0KeC1u
b3Rlcy1GYWlsdXJlUmVhc29uOiBFcnJvciB0cmFuc2ZlcnJpbmcgdG8gaW1jLm9yZzsgU01UUCBQ
cm90b2NvbCBSZXR1cm5lZCBhIFBlcm1hbmVudCBFcnJvciA1NTAgPGlldGYtcGtpY0BpbWMub3Jn
Pi4uLiBVc2VyIHVua25vd24NCngtbm90ZXMtSW50ZW5kZWRSZWNpcGllbnQ6IGlldGYtcGtpY0Bp
bWMub3JnDQpDb250ZW50LXR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWkNCkNvbnRl
bnQtRGlzcG9zaXRpb246IGlubGluZQ0KDQpEYXZlIEhvcnZhdGggPGRhdmVAY2hyb21hdGl4LmNv
bT4gd3JpdGVzOg0KDQoNCj4+IFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byBvcHRpb25z
IGlzIHByaW1hcmlseSBzdG9yYWdlIGVmZmljaWVuY3kNCnZzLg0KPj4gcmV0cmlldmFsIGVmZmlj
aWVuY3kuICBCb3RoIG9wdGlvbnMgZGl2aWRlIGEgQ0FzIGNlcnRzIGludG8gdHdvIHBpbGVzLg0K
Pj4gT3B0aW9uIDEgaGFzIHBpbGUgQSBjb250YWluaW5nIG9ubHkgaW50cmEtZG9tYWluIGNlcnRz
LCBhbmQgcGlsZSBCDQo+PiBjb250YWluaW5nIG9ubHkgaW50ZXItZG9tYWluIGNlcnRzOyBvcHRp
b24gMiBoYXMgcGlsZSBBIGNvbnRhaW5pbmcgb25seQ0KPj4gaW50cmEtZG9tYWluIGNlcnRzIGFu
ZCBwaXRlIEIgY29udGFpbmluZyBhbGwgY2VydHMuICBXaGljaCBvcHRpb24gaXMNCj4+IHN1cGVy
aW9yIGRlcGVuZHMgb24gdHdvIHRoaW5nczoNCj4+DQo+Pi4uLg0KPj4NCj4+IEhhdmluZyB0aGUg
dGFyZ2V0IENBIGRpdmlkZSBpdHMgY2VydGlmaWNhdGVzIGJldHdlZW4gdHdvIHBsYWNlcyB3aXRo
aW4NCnRoZQ0KPj4gZGlyZWN0b3J5IGlzIG5vIGhlbHAgdG8gdGhpcyB2ZXJpZmllci4gIEFsbCBp
dCBkb2VzIGl0IGZvcmNlIHRoZQ0KdmVyaWZpZXINCj4+IHRvIG1ha2UgdHdvIHJldHJpZXZhbCBv
cGVyYXRpb25zIGluc3RlYWQgb2YgdGhlIG9uZSB0aGF0IHdvdWxkIGJlDQpyZXF1aXJlZA0KPj4g
Ynkgb3B0aW9uIDIuICBUaGUgdmVyaWZpZXIgaXNuJ3QgcmVhbGx5IGludGVyZXN0ZWQgaW4gd2hl
dGhlciBhDQpwYXJ0aWN1bGFyDQo+PiBjZXJ0aWZpY2F0ZSBjb21lcyBmcm9tIGFub3RoZXIgQ0Eg
ZnJvbSB0aGUgc2FtZSAiZG9tYWluIiBhcyB0aGUgdGFyZ2V0J3MNCkNBDQo+PiAtIGlmIGl0IGNh
cmVzIGFib3V0ICJkb21haW5zIiBhdCBhbGwsIHdoYXQgaXQgd291bGQgYmUgaW50ZXJlc3RlZCBp
biBpcw0KaWYNCj4+IGFueSBjZXJ0cyBjb21lIGZyb20gdGhlIHNhbWUgZG9tYWluIGFzIHRoZSB2
ZXJpZmllciAob3Igb25lIG9mIGl0cw0KdHJ1c3RlZA0KPj4gcm9vdHMpLCBub3QgdGhlIHRhcmdl
dCAoYW5kIG9mIGNvdXJzZSB0aGF0J3MgdmVyaWZpZXItc3BlY2lmaWMpLg0KPg0KPiAgICBKb2hu
LCAgdGhlIHZlcmlmaWVyIGRvZXMgTk9UIGhhdmUgdG8gaW52b2tlIHR3byByZXRyaWV2YWwgb3Bl
cmF0aW9ucy4NCj5UaGUgdmVyaWZpZXIgc2ltcGx5IHJlYWRzIHRoZSBDQSBlbnRyeSByZXF1ZXN0
aW5nIGJvdGggdGhlIGNBQ2VydGlmaWNhdGUNCj5hdHRyaWJ1dGUgYW5kIHRoZSBjcm9zc0NlcnRp
ZmljYXRlUGFpciBhdHRyaWJ1dGUgaW4gdGhlIHNhbWUgc2VhcmNoL3JlYWQNCj5vcGVyYXRpb24u
ICBBbGwgY2VydGlmaWNhdGVzIGFyZSByZXR1cm5lZC4gIFRoZSB2ZXJpZmllciBjYW4gdGhlbiBk
ZWNpZGUNCj53aGV0aGVyIHRvIGV4cGxvcmUgaW50ZXItZG9tYWluLCBpbnRyYS1kb21haW4sIGJv
dGggLCBub25lLCB3aGF0ZXZlci4NCj5UaGUgdmVyaWZpZXIgY2FuIGx1bXAgdGhlbSBhbGwgdG9n
ZXRoZXIgaW4gdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBpZg0KPnRoZXkgbGlrZSEgIFRoZSBtYWlu
IGFkdmFudGFnZSB0byBvcHRpb24gMSBpcyB3ZSBkb24ndCBzdG9yZSB0aGUNCj5jZXJ0aWZpY2F0
ZXMgdHdpY2Ugd2hpY2ggaXMgIGEgZnVuZGFtZW50YWwgZ29hbCBpbiBhbGwgZGF0YWJhc2UNCj5h
cHBsaWNhdGlvbnMuICAgSU1ITyBpdCBhcHBsaWVzIHRvIHJlcG9zaXRvcmllcyBhbmQgcHVibGlj
IGtleQ0KPmluZnJhc3RydWN0dXJlcyBhbHNvLg0KDQpUaGVyZSBtYXkgbm90IGJlIHR3byBwcm90
b2NvbCBhY3Rpb25zIGFjcm9zcyB0aGUgd2lyZSwgYnV0IGl0J3MgZGVmaW5pdGVseQ0KbGVzcyB3
b3JrIGZvciB0aGUgY2xpZW50IHRvIHJlY2VpdmUgYSBzaW5nbGUgc2V0IG9mIG9iamVjdHMgYWxs
IG9mIHRoZSBzYW1lDQp0eXBlLCBjb21wYXJlZCB0byB0aGUgdHdvIHNldHMgb2YgZGlmZmVyZW50
bHkgdHlwZWQgb2JqZWN0cyB0aGF0IG9wdGlvbiAxDQpyZXF1aXJlcyBpdCB0byByZXRyaWV2ZS4g
IFVuZGVyIG9wdGlvbiAyLCB2ZXJpZmllcnMgdGhhdCBkb24ndCBjYXJlIGFib3V0DQp0aGUgQ0Fz
IGlkZWFzIGFib3V0IGRvbWFpbnMgY2FuIHNpbXBseSByZXRyaWV2ZSBhbGwgdGhlIENBcyBjZXJ0
aWZpY2F0ZXMuDQpIYXZpbmcgdGhlIENBIGRpdmlkZSBpdHMgY2VydGlmaWNhdGVzIGludG8gdHdv
IHBpbGVzIG9ubHkgYWRkcyBjb21wbGV4aXR5DQp0byB0aGUgY2xpZW50J3MgdGFzay4NCg0KVGhl
IG9ubHkgcGxhY2Ugd2hlcmUgdmVyaWZpZXJzIHdpbGwgY2FyZSBhYm91dCB3aGljaCBkb21haW4g
dGhlIENBIHRoaW5rcw0KaXQncyBpbiwgaXMgaWYgdGhleSB0aGluayB0aGV5IChvciBvbmUgb2Yg
dGhlaXIgcm9vdHMpIGFyZSBpbiB0aGUgc2FtZQ0KZG9tYWluLiAgT25seSBpbiB0aGF0IGNhc2Ug
aXMgYSB2ZXJpZmllciBsaWtlbHkgdG8gZGVjaWRlIHRvIGxvb2sgZmlyc3QgYXQNCnRoZSBDQXMg
aW50cmEtZG9tYWluIGNlcnRzLCBhbmQgb3B0aW9uIDIgYWxsb3dzIGZvciB0aGlzIGNob2ljZSBq
dXN0IGFzDQpzaW1wbHkgYXMgZG9lcyBvcHRpb24gMS4NCg0KVGhlIGNvc3Qgb2YgdGhpcyBpbiBv
cHRpb24gMiBpcyB0aGUgZHVwbGljYXRpb24gb2Ygc29tZSBjZXJ0aWZpY2F0ZXMgaW4gdGhlDQpk
aXJlY3RvcnkgKHdlIGFscmVhZHkgaGF2ZSBkdXBsaWNhdGlvbiBpbiB0aGlzIGFyZWEsIHVubGVz
cyB0aGUgZGlyZWN0b3J5DQpoYXMgc29tZSBpbnRlbGxpZ2VuY2UgdGhhdCB3aWxsIGVuYWJsZSBp
dCB0byBzdG9yZSBjcm9zcy1jZXJ0IHBhaXJzIG9ubHkNCm9uY2UgYW5kIHNvbWVob3cgcGxhY2Ug
YSByZWZlcmVuY2UgdG8gdGhlIHNoYXJlZCBvYmplY3QgZnJvbSBib3RoIENBDQplbnRyaWVzKS4g
IEJ1dCB0aGlzIGR1cGxpY2F0aW9uIGlzIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBDQSAtIGlm
IGl0DQpkb2Vzbid0IHRoaW5rIHRoZSBiZW5lZml0cyBvZiBzdG9yaW5nIGhpbnRzIGZvciBsb2Nh
bCB2ZXJpZmllcnMgYXJlDQp3b3J0aHdoaWxlLCBvcHRpb24gMiBhbGxvd3MgaXQgdG8gdXNlIF9v
bmx5XyB0aGUgY3Jvc3NDZXJ0aWZpY2F0ZSBlbnRyeSBmb3INCmFsbCBpdHMgY2VydHMuDQoNCj4g
ICAgVGhlIGdlbmVyYWwgYWxnb3JpdGhtIHdlIGVudmlzaW9uIGlzIGZvciBjbGllbnRzIHRvIGZp
cnN0IGV4cGxvcmUgdGhlDQo+Y0FDZXJ0aWZpY2F0ZSBhdHRyaWJ1dGUsIHRoZW4gZXhwbG9yZSB0
aGUgY3Jvc3NDZXJ0aWZpY2F0ZVBhaXINCj5hdHRyaWJ1dGUuICAgVGhhdCB3YXkgbm90aGluZyB3
aWxsIGdldCBtaXNzZWQuICBJdCdzIG5vdCBhbiBhbGwgb3INCj5ub3RoaW5nIGNob2ljZS4gIEl0
J3MgYW4gYXR0ZW1wdCB0byBzdG9yZSB0aGUgY2VydGlmaWNhdGVzIG9uY2UgYW5kIHRvDQo+Z3Jv
dXAgdGhlbSB0byBtYWtlIGxvZ2ljYWwgZGVjaXNpb25zIHdoZW4gZXhwbG9yaW5nIHBvc3NpYmx5
IGNvbXBsZXgNCj5wYXRocy4NCg0KQnV0IHlvdSBjYW4gb25seSBtYWtlIGxvZ2ljYWwgZGVjaXNp
b25zIHdoZW4geW91IGhhdmUgc29tZSBkYXRhIHRvIHdvcmsNCndpdGguICBBIENBIGhhcyBubyBp
ZGVhIHdoZW4gaXQncyBwbGFjaW5nIGl0cyBjZXJ0cyBpbiB0aGUgZGlyZWN0b3J5IGFib3V0DQp3
aG8gaXMgZ29pbmcgdG8gY29tZSBsb29rIGZvciB0aGVtLiAgV2l0aG91dCBrbm93aW5nIHdoYXQg
ZG9tYWluIHRoZQ0KdmVyaWZpZXIgaXMgaW4sIHRoZSBDQSBjYW4ndCBob3BlIHRvIGhlbHAgaXQg
b3V0LiAgSXQgY2FuIG1ha2UgYQ0Kc3BlY2lhbC1jYXNlIG9wdGltaXphdGlvbiB1bmRlciBlaXRo
ZXIgb3B0aW9uIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUNCnZlcmlmaWVyIGlzIGluIHRoZSBzYW1l
IGRvbWFpbiBhcyB0aGUgQ0EgICh3aGljaCBpcyByZWFsbHkgdGhlIG9ubHkgdGltZQ0KdGhhdCBl
aXRoZXIgb3B0aW9uIG9mZmVycyBhbnkgYWR2YW50YWdlIG92ZXIgc2ltcGx5IGhhdmluZyBhIHNp
bmdsZSBlbnRyeQ0KaW50byB3aGljaCBhbGwgY2VydHMgYXJlIHBsYWNlZCkuDQoNCg0KDQpJbiBz
dW1tYXJ5LCBteSBjb250ZW50aW9uIGlzIHRoYXQgdmVyeSBmZXcgdmVyaWZpZXJzIHdpbGwgZXZl
ciB3YW50IHRvIGJlDQpib3RoZXJlZCB3aXRoICJkb21haW5zIiAob3IgYXQgbGVhc3QsIG5vdCB3
aXRoIHNvbWUgZm9yZWlnbiBDQSdzIGlkZWEgb2YNCndoYXQgYSBkb21haW4gaXMpLiAgT2YgdGhl
IHR3byBvcHRpb25zIHVuZGVyIGRpc2N1c3Npb24sIG9wdGlvbiAyIGFsbG93cw0KbW9zdCB2ZXJp
ZmllcnMgdG8gc2ltcGx5IGlnbm9yZSB0aGUgZmFjdCB0aGF0IGEgQ0EgaGFzIGNob3NlbiB0byBp
c3N1ZQ0KdW53YW50ZWQgaGludHMsIGFuZCBqdXN0IHJldHJpZXZlIHRoZSBjZXJ0cyBpdCB3YW50
cyBmcm9tIGEgc2luZ2xlIHBsYWNlLg0KVGhlIGZldyB2ZXJpZmllcnMgdGhhdCB3YW50IHRvIGRv
IHNvbWV0aGluZyB3aXRoIGEgQ0EncyBoaW50cyBjYW4gY2hvb3NlIHRvDQpkbyBzbyB1bmRlciBl
aXRoZXIgb3B0aW9uLCBidXQgb3B0aW9uIDEgd291bGQgZm9yY2UgYWxsIGNsaWVudCBzb2Z0d2Fy
ZSB0bw0KaW5jcmVhc2UgaW4gY29tcGxleGl0eSB0byBnYWluIHRoYXQgY2hvaWNlLiAgT3B0aW9u
IDIgYnVyZGVucyBvbmx5IHRob3NlDQpjbGllbnRzIHRoYXQgd2lzaCB0byBleHBsb2l0IHRoZSBo
aW50cy4NCg0KDQpKb2huDQoNCg0KDQo=

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA23308 for ietf-pkix-bks; Fri, 4 Sep 1998 01:26:28 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA23296 for <[e-mail]>; Fri, 4 Sep 1998 01:26:25 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA25196; Fri, 4 Sep 1998 10:32:57 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id KAA16302; Fri, 4 Sep 1998 10:32:58 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 10:32:23 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: TemporalData (Time Stamp Protocol)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA22177 for ietf-pkix-bks; Fri, 4 Sep 1998 01:17:11 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA22167 for <[e-mail]>; Fri, 4 Sep 1998 01:17:09 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA13628; Fri, 4 Sep 1998 10:23:38 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id KAA05764; Fri, 4 Sep 1998 10:23:39 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 10:23:03 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: [e-mail]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA21703 for ietf-pkix-bks; Fri, 4 Sep 1998 01:05:24 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21551 for <[e-mail]>; Fri, 4 Sep 1998 00:59:48 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA12425; Fri, 4 Sep 1998 10:03:56 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id KAA22052; Fri, 4 Sep 1998 10:03:56 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 10:03:20 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: [e-mail], "'Santosh Chokhani'" <[e-mail]>
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12924 for ietf-pkix-bks; Thu, 3 Sep 1998 23:12:31 -0700 (PDT)
Received: from fw.ssb.it (fw.ssb.it [192.106.128.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA12918 for <[e-mail]>; Thu, 3 Sep 1998 23:12:29 -0700 (PDT)
Received: from notesmail.ssb.it (domino.ssb.it [192.168.19.5]) by ns.ssb.it (8.8.5/8.7.3) with SMTP id KAA02099 for <[e-mail]>; Fri, 4 Sep 1998 10:14:03 +0200 (CEST)
Received: by notesmail.ssb.it(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id C1256675.00231CDF ; Fri, 4 Sep 1998 08:23:31 +0200
X-Lotus-FromDomain: SSB
From: "Andrea Sansone" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 4 Sep 1998 08:21:29 +0200
Subject: for option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA12415 for ietf-pkix-bks; Thu, 3 Sep 1998 21:21:59 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA12411 for <[e-mail]>; Thu, 3 Sep 1998 21:21:52 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R8ZDT79L>; Fri, 4 Sep 1998 14:22:19 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D489@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Frank O'Dwyer'" <[e-mail]>, Dave Horvath <[e-mail]>
Cc: [e-mail]
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Fri, 4 Sep 1998 14:22:16 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, 4 September 1998 12:36
> To:	Dave Horvath
> Cc:	[e-mail]
> 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA12101 for ietf-pkix-bks; Thu, 3 Sep 1998 20:30:18 -0700 (PDT)
Received: from mail1.toronto.istar.net (mail1.toronto.istar.net [209.89.75.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA12097 for <[e-mail]>; Thu, 3 Sep 1998 20:30:11 -0700 (PDT)
Received: from ts55-02.tor.istar.ca ([204.191.148.33] helo=2keys.ca) by mail1.toronto.istar.net with esmtp (Exim 2.02 #1) id 0zEmeE-0007PK-00 for [e-mail]; Thu, 3 Sep 1998 23:34:54 -0400
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 23:31:01 -0400
From: Tony Bates <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11572 for ietf-pkix-bks; Thu, 3 Sep 1998 19:33:51 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11568 for <[e-mail]>; Thu, 3 Sep 1998 19:33:50 -0700 (PDT)
Received: from [158.152.104.114] (helo=brd.ie) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zEllm-00049c-00; Fri, 4 Sep 1998 02:38:39 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 03:35:30 +0100
From: "Frank O'Dwyer" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: Dave Horvath <[e-mail]>
CC: [e-mail]
Subject: path development complexity (was Re: What the straw poll means)
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11432 for ietf-pkix-bks; Thu, 3 Sep 1998 19:01:53 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11427 for <[e-mail]>; Thu, 3 Sep 1998 19:01:45 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R8ZDT787>; Fri, 4 Sep 1998 12:02:05 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D484@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Where to store CA certificates
Date: Fri, 4 Sep 1998 12:02:04 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, 4 September 1998 10:11
> To:	'Ambarish Malpani'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Thursday, September 03, 1998 12:54 PM
> > To:	'[e-mail]'
> > 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.
> > [e-mail]
> > 1215 Terra Bella Ave.
> http://www.valicert.com
> > Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA10891 for ietf-pkix-bks; Thu, 3 Sep 1998 18:29:34 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA10887 for <[e-mail]>; Thu, 3 Sep 1998 18:29:29 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R8ZDT78T>; Fri, 4 Sep 1998 11:29:45 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D483@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, Carlisle Adams <[e-mail]>
Cc: [e-mail]
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
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

comments in line

> -----Original Message-----
> From:	Ambarish Malpani [SMTP:[e-mail]]
> Sent:	Friday, 4 September 1998 6:41
> To:	Carlisle Adams
> Cc:	[e-mail]
> 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:[e-mail]]
> > > Sent:         Thursday, September 03, 1998 12:14 PM
> > > To:   [e-mail]
> > > Cc:   [e-mail]
> > > 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.
> [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10579 for ietf-pkix-bks; Thu, 3 Sep 1998 17:29:36 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10575 for <[e-mail]>; Thu, 3 Sep 1998 17:29:35 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZW17>; Thu, 3 Sep 1998 20:33:56 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D22B@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 20:33:53 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 8:19 PM
> To:	'[e-mail]'; 'Santosh Chokhani'
> Cc:	[e-mail]
> Subject:	RE: What the straw poll means
> 
>        
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > Sent: 	September 3, 1998 7:50 PM
> > To: 	'[e-mail]'; Santosh Chokhani
> > Cc: 	[e-mail]
> > 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:	[e-mail] [SMTP:[e-mail]]
> > > Sent:	Thursday, September 03, 1998 8:51 AM
> > > To:	Santosh Chokhani
> > > Cc:	[e-mail]
> > > Subject:	RE: What the straw poll means
> > > 
> > > Santosh Chokhani <[e-mail]> 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
> > > 
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10535 for ietf-pkix-bks; Thu, 3 Sep 1998 17:19:11 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10529 for <[e-mail]>; Thu, 3 Sep 1998 17:19:09 -0700 (PDT)
Received: by gateway.r3.ch id <6801>; Fri, 4 Sep 1998 02:25:16 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 01:19:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 3, 1998 7:50 PM
> To: 	'[e-mail]'; Santosh Chokhani
> Cc: 	[e-mail]
> 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:	[e-mail] [SMTP:[e-mail]]
> > Sent:	Thursday, September 03, 1998 8:51 AM
> > To:	Santosh Chokhani
> > Cc:	[e-mail]
> > Subject:	RE: What the straw poll means
> > 
> > Santosh Chokhani <[e-mail]> 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
> > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10465 for ietf-pkix-bks; Thu, 3 Sep 1998 17:06:35 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10461 for <[e-mail]>; Thu, 3 Sep 1998 17:06:34 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZWAW>; Thu, 3 Sep 1998 20:10:55 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D229@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 20:10:53 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Thursday, September 03, 1998 12:54 PM
> To:	'[e-mail]'
> 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.
> [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10394 for ietf-pkix-bks; Thu, 3 Sep 1998 16:59:54 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10390 for <[e-mail]>; Thu, 3 Sep 1998 16:59:52 -0700 (PDT)
Received: by gateway.r3.ch id <6804>; Fri, 4 Sep 1998 02:05:54 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], [e-mail], "'John Everson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:59:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	John Everson[SMTP:[e-mail]]
> Sent: 	September 3, 1998 10:52 AM
> To: 	[e-mail]; [e-mail]
> Cc: 	[e-mail]
> 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:[e-mail]]
> Sent: Thursday, September 03, 1998 7:51 AM
> To: chokhani
> Cc: John.Wray; ietf-pkix
> Subject: RE: What the straw poll means
> 
> 
> Santosh Chokhani <[e-mail]> 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
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10378 for ietf-pkix-bks; Thu, 3 Sep 1998 16:59:19 -0700 (PDT)
Received: from portalcp.chevron.com ([e-mail] [207.24.17.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10374 for <[e-mail]>; Thu, 3 Sep 1998 16:59:18 -0700 (PDT)
Received: (from uucp@localhost) by portalcp.chevron.com (8.9.1a/8.9.1) id RAA23158 for <[e-mail]>; Thu, 3 Sep 1998 17:03:51 -0700 (PDT)
Received: from orbitcity.sr.chevron.com(146.27.94.253) by portalcp.chevron.com via smap (4.1) id xma023027; Thu, 3 Sep 98 17:03:40 -0700
Received: from chvpk-msxb1.sr.chevron.com (chvpk-msxb1.sr.chevron.com [146.27.94.102]) by orbitcity.chevron.com (8.9.1a/8.9.1) with ESMTP id RAA21084 for <[e-mail]>; Thu, 3 Sep 1998 17:03:35 -0700 (PDT)
Received: by chvpk-msxb1.sr.chevron.com with Internet Mail Service (5.5.1960.3) id <SG6CMP1Q>; Thu, 3 Sep 1998 17:03:35 -0700
Message-ID: <[e-mail]>
From: "Eaton, James (EATO)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 17:01:52 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.proper.com id QAA10375
Sender: [e-mail]
Precedence: bulk

 
 
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10349 for ietf-pkix-bks; Thu, 3 Sep 1998 16:53:54 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10345 for <[e-mail]>; Thu, 3 Sep 1998 16:53:51 -0700 (PDT)
Received: by gateway.r3.ch id <6806>; Fri, 4 Sep 1998 01:59:55 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, Dave Horvath <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:53:58 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 3, 1998 7:41 PM
> To: 	'Bill Burr'; Dave Horvath
> Cc: 	[e-mail]
> 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:[e-mail]]
> > Sent:	Thursday, September 03, 1998 12:48 PM
> > To:	Dave Horvath
> > Cc:	[e-mail]
> > 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 <[e-mail]>
> > >To: [e-mail] <[e-mail]>;
> [e-mail]
> > ><[e-mail]>
> > >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:[e-mail]]
> > >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> > >>>> To: [e-mail]
> > >>>> Cc: [e-mail]
> > >>>> 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
> > >>>> [e-mail]
> > >>>> 1-801-861-7387
> > >>
> > >>
> > >
> > >
> > Regards,
> > 
> > Bill Burr
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10339 for ietf-pkix-bks; Thu, 3 Sep 1998 16:52:58 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10335 for <[e-mail]>; Thu, 3 Sep 1998 16:52:57 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV9J>; Thu, 3 Sep 1998 19:57:18 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D227@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, [e-mail]
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
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From:	Carlisle Adams [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 2:25 PM
> To:	[e-mail]
> 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:[e-mail]]
> > Sent: 	Thursday, September 03, 1998 12:14 PM
> > To: 	[e-mail]
> > Cc: 	[e-mail]
> > 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10316 for ietf-pkix-bks; Thu, 3 Sep 1998 16:48:45 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10312 for <[e-mail]>; Thu, 3 Sep 1998 16:48:43 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV8R>; Thu, 3 Sep 1998 19:53:03 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D226@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Nada Kapidzic Cicovic'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:53:00 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From:	Nada Kapidzic Cicovic [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 5:03 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
> 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:[e-mail]]
> >> Sent:	Wednesday, September 02, 1998 8:33 PM
> >> To:	[e-mail]
> >> Cc:	[e-mail]
> >> 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
> >> [e-mail]
> >> 1-801-861-7387
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10300 for ietf-pkix-bks; Thu, 3 Sep 1998 16:46:40 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10296 for <[e-mail]>; Thu, 3 Sep 1998 16:46:38 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV8D>; Thu, 3 Sep 1998 19:50:59 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D225@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:50:58 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:	[e-mail] [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 8:51 AM
> To:	Santosh Chokhani
> Cc:	[e-mail]
> Subject:	RE: What the straw poll means
> 
> Santosh Chokhani <[e-mail]> 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
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10264 for ietf-pkix-bks; Thu, 3 Sep 1998 16:41:27 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10259 for <[e-mail]>; Thu, 3 Sep 1998 16:41:25 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <117939>; Thu, 3 Sep 1998 09:57:08 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Thu, 3 Sep 1998 09:51:37 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id JAA13959; Thu, 3 Sep 1998 09:52:30 -0500 (CDT)
From: John Everson <[e-mail]>
X-OpenMail-Hops: 1
Date: Thu, 3 Sep 1998 09:52:26 -0500
Message-Id: <H0001a0e0314a456@MHS>
Subject: RE: What the straw poll means
TO: [e-mail], [e-mail]
CC: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="openmail-part-0ef743e1-00000001"
Sender: [e-mail]
Precedence: bulk

--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:[e-mail]]
Sent: Thursday, September 03, 1998 7:51 AM
To: chokhani
Cc: John.Wray; ietf-pkix
Subject: RE: What the straw poll means


Santosh Chokhani <[e-mail]> 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--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10263 for ietf-pkix-bks; Thu, 3 Sep 1998 16:41:26 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10255 for <[e-mail]>; Thu, 3 Sep 1998 16:41:25 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <116352>; Thu, 3 Sep 1998 11:26:02 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Thu, 3 Sep 1998 11:26:45 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id LAA08023; Thu, 3 Sep 1998 11:27:38 -0500 (CDT)
X-OpenMail-Hops: 1
Date: Thu, 3 Sep 1998 11:27:34 -0500
Message-Id: <H00017cc03153bdb@MHS>
Subject: Option 2
FROM: GIUBILEO/unix////////RFC-822/GIUBILEO#a#SPRINTSEC#f#[e-mail]
TO: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="openmail-part-0ef92b5d-00000001"
Sender: [e-mail]
Precedence: bulk

--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: [phone]
[e-mail]
[PICTURE]


--openmail-part-0ef92b5d-00000001--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10254 for ietf-pkix-bks; Thu, 3 Sep 1998 16:41:24 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10250 for <[e-mail]>; Thu, 3 Sep 1998 16:41:23 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <119676>; Thu, 3 Sep 1998 11:21:53 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Thu, 3 Sep 1998 11:19:38 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id LAA06624 for [e-mail]; Thu, 3 Sep 1998 11:20:03 -0500 (CDT)
From: John Everson <[e-mail]>
X-OpenMail-Hops: 1
Date: Thu, 3 Sep 1998 11:20:00 -0500
Message-Id: <H0001a0e03154315@MHS>
Subject: Voting Question
TO: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="openmail-part-0ef90993-00000001"
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10227 for ietf-pkix-bks; Thu, 3 Sep 1998 16:38:00 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10223 for <[e-mail]>; Thu, 3 Sep 1998 16:37:57 -0700 (PDT)
Received: by gateway.r3.ch id <6804>; Fri, 4 Sep 1998 01:44:05 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Bill Burr <[e-mail]>, "'Dave Horvath'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:38:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

	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:[e-mail]]
> Sent: 	September 3, 1998 2:14 PM
> To: 	Bill Burr
> Cc: 	[e-mail]
> 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 <[e-mail]>
> To: Dave Horvath <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> 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 <[e-mail]>
> >>To: [e-mail] <[e-mail]>; [e-mail]
> >><[e-mail]>
> >>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:[e-mail]]
> >>>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>>> To: [e-mail]
> >>>>> Cc: [e-mail]
> >>>>> 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
> >>>>> [e-mail]
> >>>>> 1-801-861-7387
> >>>
> >>>
> >>
> >>
> >Regards,
> >
> >Bill Burr
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10215 for ietf-pkix-bks; Thu, 3 Sep 1998 16:37:21 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10211 for <[e-mail]>; Thu, 3 Sep 1998 16:37:18 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV6T>; Thu, 3 Sep 1998 19:41:38 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D224@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, Dave Horvath <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:41:37 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Thursday, September 03, 1998 12:48 PM
> To:	Dave Horvath
> Cc:	[e-mail]
> 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 <[e-mail]>
> >To: [e-mail] <[e-mail]>; [e-mail]
> ><[e-mail]>
> >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:[e-mail]]
> >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>> To: [e-mail]
> >>>> Cc: [e-mail]
> >>>> 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
> >>>> [e-mail]
> >>>> 1-801-861-7387
> >>
> >>
> >
> >
> Regards,
> 
> Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10138 for ietf-pkix-bks; Thu, 3 Sep 1998 16:24:42 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10134 for <[e-mail]>; Thu, 3 Sep 1998 16:24:41 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZVZ4>; Thu, 3 Sep 1998 19:29:01 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D222@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Carlisle Adams <[e-mail]>, [e-mail]
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
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:	[e-mail] [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 5:09 PM
> To:	Carlisle Adams; [e-mail]
> 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10018 for ietf-pkix-bks; Thu, 3 Sep 1998 16:08:07 -0700 (PDT)
Received: from tac-nt-excom1.russell.com (mailgate1.russell.com [208.152.45.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10014 for <[e-mail]>; Thu, 3 Sep 1998 16:08:06 -0700 (PDT)
Received: by tac-nt-excom1.russell.com with Internet Mail Service (5.5.2232.9) id <S17JTY5D>; Thu, 3 Sep 1998 16:10:21 -0700
Message-ID: <[e-mail]>
From: "Tuttle, Kimberly (OSSC)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2.
Date: Thu, 3 Sep 1998 16:10:29 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09871 for ietf-pkix-bks; Thu, 3 Sep 1998 15:50:23 -0700 (PDT)
Received: from tac-nt-excom1.russell.com (mailgate1.russell.com [208.152.45.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09867 for <[e-mail]>; Thu, 3 Sep 1998 15:50:22 -0700 (PDT)
Received: by tac-nt-excom1.russell.com with Internet Mail Service (5.5.2232.9) id <S17JTYV0>; Thu, 3 Sep 1998 15:52:36 -0700
Message-ID: <[e-mail]>
From: "Evans,  Jim (OSSC)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 15:52:45 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Evans
Frank Russell Company

Security is what YOU Practice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09496 for ietf-pkix-bks; Thu, 3 Sep 1998 15:05:28 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09492 for <[e-mail]>; Thu, 3 Sep 1998 15:05:26 -0700 (PDT)
Received: by gateway.r3.ch id <6814>; Fri, 4 Sep 1998 00:11:30 +0100
Message-Id: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
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
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Ryan,

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Sent: 	Thursday, September 03, 1998 5:09 PM
> To: 	Carlisle Adams; [e-mail]
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09480 for ietf-pkix-bks; Thu, 3 Sep 1998 15:04:31 -0700 (PDT)
Received: from fep2.mail.ozemail.net (fep2.mail.ozemail.net [203.2.192.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09476 for <[e-mail]>; Thu, 3 Sep 1998 15:04:29 -0700 (PDT)
Received: from lesm95 (slcan52p02.ozemail.com.au [203.108.176.130]) by fep2.mail.ozemail.net (8.9.0/8.6.12) with SMTP id IAA11167 for <[e-mail]>; Fri, 4 Sep 1998 08:09:16 +1000 (EST)
Message-ID: <000b01bdd787$498d5d80$82b06ccb@lesm95>
From: "Les Mitchell" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Fri, 4 Sep 1998 08:07:40 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA09198 for ietf-pkix-bks; Thu, 3 Sep 1998 14:30:43 -0700 (PDT)
Received: from att.com (cagw2.att.com [192.128.52.90]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA09194 for <[e-mail]>; Thu, 3 Sep 1998 14:30:41 -0700 (PDT)
Received: from caig1.fw.att.com by cagw2.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-pkix sender qsun.ho.att.com!jayhawk (qsun.ho.att.com!jayhawk); Thu Sep  3 17:05 EDT 1998
Received: from qsun.ho.att.com (qsunn.ho.att.com [135.16.30.2]) by caig1.fw.att.com (AT&T/IPNS/GW-1.0) with SMTP id RAA02720 for <[e-mail]>; Thu, 3 Sep 1998 17:09:04 -0400 (EDT)
Received: by qsun.ho.att.com (SMI-8.6/EMS-1.2 sol2) id RAA27748; Thu, 3 Sep 1998 17:09:01 -0400
Date: Thu, 3 Sep 1998 17:09:01 -0400
Message-Id: <[e-mail]>
From: [e-mail] (Ryan Moats)
To: Carlisle Adams <[e-mail]>, [e-mail]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Content-Type: text
Sender: [e-mail]
Precedence: bulk

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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08976 for ietf-pkix-bks; Thu, 3 Sep 1998 14:05:48 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA08972 for <[e-mail]>; Thu, 3 Sep 1998 14:05:47 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id RAA08361 for <[e-mail]>; Thu, 3 Sep 1998 17:10:25 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 03 Sep 1998 17:14:02 -0400
To: [e-mail]
From: Bill Burr <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08900 for ietf-pkix-bks; Thu, 3 Sep 1998 13:58:53 -0700 (PDT)
Received: from dtol.com ([e-mail] [206.51.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA08895 for <[e-mail]>; Thu, 3 Sep 1998 13:58:52 -0700 (PDT)
Received: from dtol.com (cyborg.dilkie.com [206.51.1.171]) by dtol.com (8.6.12/8.6.9) with ESMTP id RAA03433 for <[e-mail]>; Thu, 3 Sep 1998 17:07:44 GMT
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 17:02:06 -0400
From: Susan Lang <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08759 for ietf-pkix-bks; Thu, 3 Sep 1998 13:48:36 -0700 (PDT)
Received: from egate2.citicorp.com (egate2.citicorp.com [192.193.196.194]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA08755 for <[e-mail]>; Thu, 3 Sep 1998 13:48:35 -0700 (PDT)
Received: by egate2.citicorp.com id QAA00653 (InterLock SMTP Gateway 3.0 for [e-mail]); Thu, 3 Sep 1998 16:53:15 -0400
Message-Id: <[e-mail]>
Received: by egate2.citicorp.com (Protected-side Proxy Mail Agent-1); Thu, 3 Sep 1998 16:53:15 -0400
Date: Thu, 03 Sep 1998 16:52:36 -0400
From: David Solo <[e-mail]>
Reply-To: [e-mail]
Organization: Citicorp
X-Sender: "David Solo" <[e-mail]>
X-Mailer: Mozilla 4.04 [en]C-Citicorp  (WinNT; U)
Mime-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08394 for ietf-pkix-bks; Thu, 3 Sep 1998 13:36:31 -0700 (PDT)
Received: from atlantic.valicert.com (atlantic.valicert.com [209.185.6.135] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA08390 for <[e-mail]>; Thu, 3 Sep 1998 13:36:30 -0700 (PDT)
Received: (qmail 27414 invoked from network); 3 Sep 1998 20:41:06 -0000
Received: from amazon.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 3 Sep 1998 20:41:06 -0000
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 13:41:00 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: [e-mail]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > Sent:         Thursday, September 03, 1998 12:14 PM
> > To:   [e-mail]
> > Cc:   [e-mail]
> > 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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08321 for ietf-pkix-bks; Thu, 3 Sep 1998 13:34:47 -0700 (PDT)
Received: from host.ott.igs.net (host.ott.igs.net [206.248.16.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08313 for <[e-mail]>; Thu, 3 Sep 1998 13:34:42 -0700 (PDT)
Received: from igs.net (ttyE0a.ott.igs.net [207.210.11.12]) by host.ott.igs.net (8.8.5/8.6.12) with ESMTP id QAA04133 for <[e-mail]>; Thu, 3 Sep 1998 16:39:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 16:33:13 -0400
From: Robert Sabourin <[e-mail]>
Organization: TBS TechWatch
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06917 for ietf-pkix-bks; Thu, 3 Sep 1998 11:55:53 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06913 for <[e-mail]>; Thu, 3 Sep 1998 11:55:52 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQffgu13666; Thu, 3 Sep 1998 15:00:39 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRBJKA>; Thu, 3 Sep 1998 15:02:21 -0400
Message-ID: <[e-mail]>
From: GMurphy <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Option 2
Date: Thu, 3 Sep 1998 15:02:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06657 for ietf-pkix-bks; Thu, 3 Sep 1998 11:25:03 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06653 for <[e-mail]>; Thu, 3 Sep 1998 11:25:01 -0700 (PDT)
Received: by gateway.r3.ch id <6799>; Thu, 3 Sep 1998 20:31:12 +0100
Message-Id: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail]
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
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi all,

I propose that we try (once again) to understand what the real issue is
here.

> ----------
> From: 	Ryan Moats[SMTP:[e-mail]]
> Sent: 	Thursday, September 03, 1998 12:14 PM
> To: 	[e-mail]
> Cc: 	[e-mail]
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06580 for ietf-pkix-bks; Thu, 3 Sep 1998 11:19:46 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06576 for <[e-mail]>; Thu, 3 Sep 1998 11:19:44 -0700 (PDT)
Received: from ash (ash.chromatix.com [207.97.115.9]) by chromatix.com (8.8.8/8.8.8) with SMTP id OAA21961; Thu, 3 Sep 1998 14:23:52 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <00f701bdd766$a98bcf30$[e-mail]>
From: "Dave Horvath" <[e-mail]>
To: "Bill Burr" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 14:14:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

    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 <[e-mail]>
To: Dave Horvath <[e-mail]>
Cc: [e-mail] <[e-mail]>
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 <[e-mail]>
>>To: [e-mail] <[e-mail]>; [e-mail]
>><[e-mail]>
>>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:[e-mail]]
>>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>>> To: [e-mail]
>>>>> Cc: [e-mail]
>>>>> 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
>>>>> [e-mail]
>>>>> 1-801-861-7387
>>>
>>>
>>
>>
>Regards,
>
>Bill Burr
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06389 for ietf-pkix-bks; Thu, 3 Sep 1998 10:59:08 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06385 for <[e-mail]>; Thu, 3 Sep 1998 10:59:06 -0700 (PDT)
Received: by gateway.r3.ch id <6807>; Thu, 3 Sep 1998 20:05:15 +0100
Message-Id: <[e-mail]>
From: Rainer Rueppel <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 19:01:41 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06098 for ietf-pkix-bks; Thu, 3 Sep 1998 10:26:28 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06094 for <[e-mail]>; Thu, 3 Sep 1998 10:26:25 -0700 (PDT)
Received: by gateway.r3.ch id <6804>; Thu, 3 Sep 1998 19:32:13 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 18:26:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Ambarish Malpani[SMTP:[e-mail]]
> Sent: 	September 3, 1998 12:54 PM
> To: 	'[e-mail]'
> 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.
> [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05571 for ietf-pkix-bks; Thu, 3 Sep 1998 09:49:59 -0700 (PDT)
Received: from atlantic.valicert.com (atlantic.valicert.com [209.185.6.135] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA05566 for <[e-mail]>; Thu, 3 Sep 1998 09:49:58 -0700 (PDT)
Received: (qmail 24860 invoked from network); 3 Sep 1998 16:54:25 -0000
Received: from amazon.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 3 Sep 1998 16:54:25 -0000
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 09:54:19 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Where to store CA certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05522 for ietf-pkix-bks; Thu, 3 Sep 1998 09:46:08 -0700 (PDT)
Received: from chopin.digsigtrust.com (chopin.digsigtrust.com [208.30.64.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA05518 for <[e-mail]>; Thu, 3 Sep 1998 09:46:07 -0700 (PDT)
Received: from digsigtrust.com (rfwdesktop.digsigtrust.com [208.30.64.114]) by chopin.digsigtrust.com (8.9.1/8.9.1) with ESMTP id KAA12051 for <[e-mail]>; Thu, 3 Sep 1998 10:50:13 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 11:14:45 -0600
From: "Russel F. Weiser" <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------4DB9C958A073A47F89771625"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone]
> http://www.entrust.com            Fax: [phone]
>
>
> > ----------
> > From:         Santosh Chokhani[SMTP:[e-mail]]
> > Sent:         September 2, 1998 8:48 PM
> > To:   'Bob Jueneman'; [e-mail]
> > 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:[e-mail]]
> > > Sent:       Wednesday, September 02, 1998 8:33 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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
> > > [e-mail]
> > > 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: [e-mail]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------4DB9C958A073A47F89771625--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05452 for ietf-pkix-bks; Thu, 3 Sep 1998 09:40:08 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA05448 for <[e-mail]>; Thu, 3 Sep 1998 09:40:07 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id MAA05240; Thu, 3 Sep 1998 12:44:14 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 03 Sep 1998 12:47:53 -0400
To: "Dave Horvath" <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: What the straw poll means
Cc: [e-mail]
In-Reply-To: <008001bdd74d$95b14bc0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
>To: [e-mail] <[e-mail]>; [e-mail]
><[e-mail]>
>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:[e-mail]]
>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>> To: [e-mail]
>>>> Cc: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> 1-801-861-7387
>>
>>
>
>
Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05420 for ietf-pkix-bks; Thu, 3 Sep 1998 09:37:57 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA05416 for <[e-mail]>; Thu, 3 Sep 1998 09:37:56 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Thu, 03 Sep 1998 10:42:00 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 03 Sep 1998 10:41:47 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: What the straw poll means
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA05417
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05400 for ietf-pkix-bks; Thu, 3 Sep 1998 09:36:11 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA05396 for <[e-mail]>; Thu, 3 Sep 1998 09:36:10 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQffgk13897; Thu, 3 Sep 1998 12:40:21 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRB215>; Thu, 3 Sep 1998 12:42:33 -0400
Message-ID: <[e-mail]>
From: WHenry <[e-mail]>
To: [e-mail]
Subject: For Option #2
Date: Thu, 3 Sep 1998 12:42:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04949 for ietf-pkix-bks; Thu, 3 Sep 1998 09:27:37 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04942 for <[e-mail]>; Thu, 3 Sep 1998 09:27:35 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-US Robotics) id LAA09323; Thu, 3 Sep 1998 11:36:23 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 86256674.005B319B ; Thu, 3 Sep 1998 11:36:04 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Boby Joseph" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 3 Sep 1998 11:36:24 -0500
Subject: For option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04631 for ietf-pkix-bks; Thu, 3 Sep 1998 09:25:19 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04623 for <[e-mail]>; Thu, 3 Sep 1998 09:25:18 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA23905 for <[e-mail]>; Thu, 3 Sep 1998 12:30:05 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011704b214746ad0fe@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Thu, 3 Sep 1998 12:32:04 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: What the straw poll means
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA03056 for ietf-pkix-bks; Thu, 3 Sep 1998 09:09:07 -0700 (PDT)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA03051 for <[e-mail]>; Thu, 3 Sep 1998 09:09:05 -0700 (PDT)
Received: from kcig1.fw.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-pkix sender att.com!jayhawk (att.com!jayhawk); Thu Sep  3 11:12 CDT 1998
Received: from qsun.ho.att.com (qsunn.ho.att.com [135.16.30.2]) by kcig1.fw.att.com (AT&T/IPNS/GW-1.0) with SMTP id LAA02486 for <[e-mail]>; Thu, 3 Sep 1998 11:12:13 -0500 (CDT)
Received: from sloop.local.windrose.omaha.ne.us by qsun.ho.att.com (SMI-8.6/EMS-1.2 sol2) id MAA15045; Thu, 3 Sep 1998 12:12:00 -0400
From: "Ryan Moats" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Retrieval efficiency herring? (was... RE: What the straw poll means)
Date: Thu, 3 Sep 1998 11:14:31 -0500
Message-ID: <000101bdd755$ef033a00$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

[e-mail] writes:

> Santosh Chokhani <[e-mail]> 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02866 for ietf-pkix-bks; Thu, 3 Sep 1998 08:46:32 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02862 for <[e-mail]>; Thu, 3 Sep 1998 08:46:31 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090311504488:1045  for <[e-mail]> ; Thu, 3 Sep 1998 11:50:44 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090311504488:1045  for <[e-mail]> ; Thu, 3 Sep 1998 11:50:44 -0400 
X-Lotus-FromDomain: IRIS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 3 Sep 1998 11:53:53 -0400
Subject: For Option 2
x-notes-Form: Memo
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02506 for ietf-pkix-bks; Thu, 3 Sep 1998 08:20:25 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02502 for <[e-mail]>; Thu, 3 Sep 1998 08:20:24 -0700 (PDT)
Received: from ash (ash.chromatix.com [207.97.115.9]) by chromatix.com (8.8.8/8.8.8) with SMTP id LAA21436; Thu, 3 Sep 1998 11:24:22 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <008001bdd74d$95b14bc0$[e-mail]>
From: "Dave Horvath" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 11:14:45 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
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:[e-mail]]
>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> 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
>>> [e-mail]
>>> 1-801-861-7387
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02269 for ietf-pkix-bks; Thu, 3 Sep 1998 08:04:30 -0700 (PDT)
Received: from war.wyeth.com (ramail1.labs.wyeth.com [155.94.101.101] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA02265 for <[e-mail]>; Thu, 3 Sep 1998 08:04:22 -0700 (PDT)
Received: from USRA08-Message_Server by war.wyeth.com with Novell_GroupWise; Thu, 03 Sep 1998 11:08:48 -0400
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 03 Sep 1998 11:08:28 -0400
From: Peter Lindstrom <[e-mail]>
To: [e-mail]
Subject: For Option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01888 for ietf-pkix-bks; Thu, 3 Sep 1998 07:29:48 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01883 for <[e-mail]>; Thu, 3 Sep 1998 07:29:46 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id KAA21240; Thu, 3 Sep 1998 10:33:54 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 10:33:58 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: [e-mail]
CC: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

See comment below.

[e-mail] wrote:
> 
> Santosh Chokhani <[e-mail]> 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. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01852 for ietf-pkix-bks; Thu, 3 Sep 1998 07:26:05 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA01848 for <[e-mail]>; Thu, 3 Sep 1998 07:26:04 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA03719; Thu, 3 Sep 1998 10:30:39 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 03 Sep 1998 10:34:19 -0400
To: "Bob Jueneman" <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: What the straw poll means
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01521 for ietf-pkix-bks; Thu, 3 Sep 1998 06:54:16 -0700 (PDT)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA01517 for <[e-mail]>; Thu, 3 Sep 1998 06:54:15 -0700 (PDT)
Received: from GRIMM.BBN.COM by COLUMBIA.BBN.COM id aa11646; 3 Sep 98 9:55 EDT
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 09:56:48 -0400
From: Susan Joseph <[e-mail]>
Reply-To: [e-mail]
Organization: BBN
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

--
Susan Joseph
GTE Internetworking
9810 Patuxent Woods Drive
Columbia, MD 21046
Tel:  [phone]
Fax: [phone]
E-Mail:  [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01462 for ietf-pkix-bks; Thu, 3 Sep 1998 06:48:47 -0700 (PDT)
Received: from callisto.eci-esyst.com ([205.129.215.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA01458 for <[e-mail]>; Thu, 3 Sep 1998 06:48:45 -0700 (PDT)
Date: 3 Sep 1998 08:52:29 -0400
Subject: For Option 1
To: "PKIX Mail List" <[e-mail]>
X-Mailer: Mail*Link SMTP-QM 4.1.0
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body"
From: "Chris Francis" <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA01459
Sender: [e-mail]
Precedence: bulk

                                             Inter-Office Memo
                                      For Option 1

Chris Francis
Raytheon Systems



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA00872 for ietf-pkix-bks; Thu, 3 Sep 1998 05:49:16 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA00868 for <[e-mail]>; Thu, 3 Sep 1998 05:49:15 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id IAA20701; Thu, 3 Sep 1998 08:53:15 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 08:53:19 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: Nada Kapidzic Cicovic <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> >> Sent:        Wednesday, September 02, 1998 8:33 PM
> >> To:  [e-mail]
> >> Cc:  [e-mail]
> >> 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
> >> [e-mail]
> >> 1-801-861-7387
> >

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA00808 for ietf-pkix-bks; Thu, 3 Sep 1998 05:43:05 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA00804 for <[e-mail]>; Thu, 3 Sep 1998 05:43:04 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090308471794:820  for <[e-mail]> , <[e-mail]> ; Thu, 3 Sep 1998 08:47:17 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090308471794:820  for <[e-mail]> , <[e-mail]> ; Thu, 3 Sep 1998 08:47:17 -0400 
X-Lotus-FromDomain: IRIS
To: Santosh Chokhani <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 3 Sep 1998 08:50:38 -0400
Subject: RE: What the straw poll means
Mime-Version: 1.0
x-notes-Form: Memo
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: [e-mail]
Precedence: bulk

Santosh Chokhani <[e-mail]> 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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA00646 for ietf-pkix-bks; Thu, 3 Sep 1998 05:23:58 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA00642 for <[e-mail]>; Thu, 3 Sep 1998 05:23:57 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id IAA20594; Thu, 3 Sep 1998 08:27:46 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 08:27:50 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: Sean Mullan <[e-mail]>
CC: Sharon Boeyen <[e-mail]>, [e-mail]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone]
> > http://www.entrust.com            Fax: [phone]
> >
> >
> > > ----------
> > > From:         Bob Jueneman[SMTP:[e-mail]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [e-mail]; [e-mail]; [e-mail]
> > > 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. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00488 for ietf-pkix-bks; Thu, 3 Sep 1998 04:53:43 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00484 for <[e-mail]>; Thu, 3 Sep 1998 04:53:42 -0700 (PDT)
Received: from chromatix.com (palm.chromatix.com [207.97.115.21]) by chromatix.com (8.8.8/8.8.8) with ESMTP id HAA20517 for <[e-mail]>; Thu, 3 Sep 1998 07:57:51 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 08:00:17 -0400
From: Richard Pimental <[e-mail]>
Organization: Chromatix, Inc.
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Content-Type: multipart/mixed; boundary="------------BBC97F524D955BDFBA611C8B"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
title:          Software Engineer
tel;work:       [phone]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------BBC97F524D955BDFBA611C8B--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00358 for ietf-pkix-bks; Thu, 3 Sep 1998 04:34:51 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00354 for <[e-mail]>; Thu, 3 Sep 1998 04:34:49 -0700 (PDT)
Received: by gateway.r3.ch id <6803>; Thu, 3 Sep 1998 13:40:59 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], "'Santosh Chokhani'" <[e-mail]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 12:35:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 2, 1998 8:48 PM
> To: 	'Bob Jueneman'; [e-mail]
> 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:[e-mail]]
> > Sent:	Wednesday, September 02, 1998 8:33 PM
> > To:	[e-mail]
> > Cc:	[e-mail]
> > 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
> > [e-mail]
> > 1-801-861-7387
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00104 for ietf-pkix-bks; Thu, 3 Sep 1998 04:04:33 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00100 for <[e-mail]>; Thu, 3 Sep 1998 04:04:30 -0700 (PDT)
Received: by gateway.r3.ch id <6803>; Thu, 3 Sep 1998 13:10:35 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Sharon Boeyen <[e-mail]>, "'Sean Mullan'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX  LDAPv2 schema I-D
Date: Thu, 3 Sep 1998 11:57:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Sean Mullan[SMTP:[e-mail]]
> Sent: 	September 2, 1998 4:32 PM
> To: 	Sharon Boeyen
> Cc: 	[e-mail]
> 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:[e-mail]  Tel: [phone]
> > http://www.entrust.com            Fax: [phone]
> > 
> > 
> > > ----------
> > > From:         Bob Jueneman[SMTP:[e-mail]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [e-mail]; [e-mail]; [e-mail]
> > > 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
> > >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA27382 for ietf-pkix-bks; Thu, 3 Sep 1998 02:02:08 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27378 for <[e-mail]>; Thu, 3 Sep 1998 02:02:06 -0700 (PDT)
Received: from jimmie ([10.0.0.22]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id LAA10604; Thu, 3 Sep 1998 11:02:05 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 03 Sep 1998 11:02:39 +0200
To: Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[e-mail]>
In-Reply-To: <51BF55C30B4FD1118B4900207812701E16D21E@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[e-mail]
>> Cc:	[e-mail]
>> 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
>> [e-mail]
>> 1-801-861-7387
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA01178 for ietf-pkix-bks; Wed, 2 Sep 1998 18:05:36 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA01174 for <[e-mail]>; Wed, 2 Sep 1998 18:05:34 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Wed, 02 Sep 1998 19:09:51 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 02 Sep 1998 19:09:16 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: What the straw poll means
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id SAA01175
Sender: [e-mail]
Precedence: bulk

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:[e-mail]] 
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[e-mail] 
>> Cc:	[e-mail] 
>> 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
>> [e-mail] 
>> 1-801-861-7387



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA00961 for ietf-pkix-bks; Wed, 2 Sep 1998 17:43:57 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA00957 for <[e-mail]>; Wed, 2 Sep 1998 17:43:55 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1TZ3RTW>; Wed, 2 Sep 1998 20:48:07 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D21E@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Wed, 2 Sep 1998 20:48:05 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 02, 1998 8:33 PM
> To:	[e-mail]
> Cc:	[e-mail]
> 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
> [e-mail]
> 1-801-861-7387


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA00925 for ietf-pkix-bks; Wed, 2 Sep 1998 17:39:04 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA00921 for <[e-mail]>; Wed, 2 Sep 1998 17:39:03 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Wed, 02 Sep 1998 18:43:13 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 02 Sep 1998 18:42:40 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA00922
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA00862 for ietf-pkix-bks; Wed, 2 Sep 1998 17:29:02 -0700 (PDT)
Received: from prv-mail25.provo.novelll.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA00858 for <[e-mail]>; Wed, 2 Sep 1998 17:29:01 -0700 (PDT)
Received: from INET-PRV1-Message_Server by prv-mail25.provo.novelll.com with Novell_GroupWise; Wed, 02 Sep 1998 18:33:06 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 02 Sep 1998 18:33:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: What the straw poll means
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA00859
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
1-801-861-7387


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00484 for ietf-pkix-bks; Wed, 2 Sep 1998 16:33:42 -0700 (PDT)
Received: from dc.jones.com ([206.156.0.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA00480 for <[e-mail]>; Wed, 2 Sep 1998 16:33:40 -0700 (PDT)
Received: from dc.jones.com (cm0714h.jones.com [208.159.209.173]) by dc.jones.com (8.8.8/8.8.8) with ESMTP id TAA11700 for <[e-mail]>; Wed, 2 Sep 1998 19:35:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 19:35:39 -0400
From: bgmiller <[e-mail]>
Reply-To: [e-mail]
Organization: Jones Internet Channel
X-Mailer: Mozilla 4.05 [en]C-JIC-DC  (Win95; I)
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29792 for ietf-pkix-bks; Wed, 2 Sep 1998 15:56:02 -0700 (PDT)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29788 for <[e-mail]>; Wed, 2 Sep 1998 15:56:00 -0700 (PDT)
Received: from cwallace (jazzhive.erols.com [207.96.124.71]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id TAA11116 for <[e-mail]>; Wed, 2 Sep 1998 19:00:06 -0400 (EDT)
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 19:19:11 -0400
Message-ID: <01bdd6c8$17c917e0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BDD6A6.90B777E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29757 for ietf-pkix-bks; Wed, 2 Sep 1998 15:53:24 -0700 (PDT)
Received: from mail-oak-1.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29753 for <[e-mail]>; Wed, 2 Sep 1998 15:53:23 -0700 (PDT)
Received: from sfns01.hewm.com ([206.189.8.8]) by mail-oak-1.pilot.net with ESMTP id PAA23446 for <[e-mail]>; Wed, 2 Sep 1998 15:58:07 -0700 (PDT)
Received: by SFNS01 with Internet Mail Service (5.5.1960.3) id <RH9AD63X>; Wed, 2 Sep 1998 15:58:07 -0700
Message-ID: <422B07DB41D7D111B9AF00805F19B04C2BB524@SFNS01>
From: "Maloney, Teresa A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 15:58:03 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Thanks


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29732 for ietf-pkix-bks; Wed, 2 Sep 1998 15:47:08 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29728 for <[e-mail]>; Wed, 2 Sep 1998 15:47:07 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <114634>; Wed, 2 Sep 1998 17:50:51 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Wed, 2 Sep 1998 17:51:42 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id RAA20639 for [e-mail]; Wed, 2 Sep 1998 17:52:36 -0500 (CDT)
From: John Everson <[e-mail]>
X-OpenMail-Hops: 1
Date: Wed, 2 Sep 1998 17:52:31 -0500
Message-Id: <H0001a0e0313ef37@MHS>
Subject: For Option 2
TO: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29140 for ietf-pkix-bks; Wed, 2 Sep 1998 14:18:33 -0700 (PDT)
Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29136 for <[e-mail]>; Wed, 2 Sep 1998 14:18:32 -0700 (PDT)
Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id QAA34790 for <[e-mail]>; Wed, 2 Sep 1998 16:07:53 -0500
Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 2 Sep 1998 16:23:07 -0500
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 16:22:19 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29086 for ietf-pkix-bks; Wed, 2 Sep 1998 14:13:32 -0700 (PDT)
Received: from mail.spyrus.com.au (fwuser@[203.37.128.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29081 for <[e-mail]>; Wed, 2 Sep 1998 14:13:26 -0700 (PDT)
Message-ID: <A1019E9C2D34D211A501006008C204506FAC@MAIL>
From: Charles Moore <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: for Option 1
Date: Thu, 3 Sep 1998 07:03:54 +1000 
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29024 for ietf-pkix-bks; Wed, 2 Sep 1998 14:09:13 -0700 (PDT)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29020 for <[e-mail]>; Wed, 2 Sep 1998 14:09:12 -0700 (PDT)
Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id RAA56410 for <[e-mail]>; Wed, 2 Sep 1998 17:03:09 -0400
Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id RAA36166 for <[e-mail]>; Wed, 2 Sep 1998 17:12:53 -0400
Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU014 id 5040300019930751; Wed, 2 Sep 1998 17:09:46 -0400
From: MA Crane <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Message-ID: <5040300019930751000002L012*@MHS>
Date: Wed, 2 Sep 1998 17:09:46 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28896 for ietf-pkix-bks; Wed, 2 Sep 1998 13:55:12 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28892 for <[e-mail]>; Wed, 2 Sep 1998 13:55:11 -0700 (PDT)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id <RWPXR37C>; Wed, 2 Sep 1998 13:59:24 -0700
Message-ID: <D70342829C12D2119D0700805FBECA2FC79AF0@RED-MSG-55>
From: Rick Johnson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:59:20 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28703 for ietf-pkix-bks; Wed, 2 Sep 1998 13:28:05 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA28698 for <[e-mail]>; Wed, 2 Sep 1998 13:28:04 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA03697; Wed, 2 Sep 1998 13:32:16 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA05825; Wed, 2 Sep 1998 16:32:04 -0400
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA22112; Wed, 2 Sep 1998 16:32:04 -0400
Received: from east.sun.com by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA21764; Wed, 2 Sep 1998 16:32:02 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 16:32:03 -0400
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.5b1 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: [e-mail]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone]
> http://www.entrust.com            Fax: [phone]
> 
> 
> > ----------
> > From:         Bob Jueneman[SMTP:[e-mail]]
> > Sent:         September 1, 1998 7:20 PM
> > To:   [e-mail]; [e-mail]; [e-mail]
> > 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
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27945 for ietf-pkix-bks; Wed, 2 Sep 1998 11:50:59 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27941 for <[e-mail]>; Wed, 2 Sep 1998 11:50:58 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1BY50L2>; Wed, 2 Sep 1998 14:55:09 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E0EC4A7@WUHER>
From: Kenneth Eggers <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 14:55:08 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Kenneth W. Eggers  <[e-mail]> http://www.cygnacom.com
CygnaCom Solutions, Inc.  
7927 Jones Branch Drive, Suite 100 West
McLean, VA  22102
[phone]x228  fax: [phone]                    



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27858 for ietf-pkix-bks; Wed, 2 Sep 1998 11:40:48 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27854 for <[e-mail]>; Wed, 2 Sep 1998 11:40:46 -0700 (PDT)
Received: by gateway.r3.ch id <6802>; Wed, 2 Sep 1998 20:46:47 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, [e-mail], [e-mail], "'Bob Jueneman'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 19:40:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 2, 1998 2:17 PM
> To: 	'Sharon Boeyen'; [e-mail]; [e-mail]; '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:[e-mail]]
> > Sent:	Wednesday, September 02, 1998 8:46 AM
> > To:	[e-mail]; [e-mail]; '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:[e-mail]  Tel: [phone] 
> > http://www.entrust.com            Fax: [phone] 
> >        
> > 
> > 
> > > ----------
> > > From: 	Bob Jueneman[SMTP:[e-mail]]
> > > Sent: 	September 1, 1998 7:20 PM
> > > To: 	[e-mail]; [e-mail]; [e-mail]
> > > 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
> > > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27837 for ietf-pkix-bks; Wed, 2 Sep 1998 11:37:20 -0700 (PDT)
Received: from krusty.rosenquist.com (cr462639-a.flfrd1.on.wave.home.com [24.112.89.61]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27833 for <[e-mail]>; Wed, 2 Sep 1998 11:37:19 -0700 (PDT)
Received: by krusty.rosenquist.com with Internet Mail Service (5.5.1960.3) id <RTZXP18A>; Wed, 2 Sep 1998 14:42:03 -0400
Message-ID: <[e-mail]>
From: Eric Rosenquist <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 14:42:00 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDD6A1.5ED91770"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27631 for ietf-pkix-bks; Wed, 2 Sep 1998 11:13:11 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27627 for <[e-mail]>; Wed, 2 Sep 1998 11:13:09 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1BY50GJ>; Wed, 2 Sep 1998 14:17:20 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D219@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, [e-mail], [e-mail], "'Bob Jueneman'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 14:17:18 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 02, 1998 8:46 AM
> To:	[e-mail]; [e-mail]; '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:[e-mail]  Tel: [phone] 
> http://www.entrust.com            Fax: [phone] 
>        
> 
> 
> > ----------
> > From: 	Bob Jueneman[SMTP:[e-mail]]
> > Sent: 	September 1, 1998 7:20 PM
> > To: 	[e-mail]; [e-mail]; [e-mail]
> > 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
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA27427 for ietf-pkix-bks; Wed, 2 Sep 1998 10:57:12 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA27423 for <[e-mail]>; Wed, 2 Sep 1998 10:57:11 -0700 (PDT)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id <RWP6JHY3>; Wed, 2 Sep 1998 11:01:25 -0700
Message-ID: <61AC5C9A4B9CD11181A200805F57CD5403F46D21@RED-MSG-44>
From: Peter Brundrett <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 11:01:16 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA27149 for ietf-pkix-bks; Wed, 2 Sep 1998 10:31:11 -0700 (PDT)
Received: from dell_srv.bankers.org (l131.wespay.org [204.188.21.131]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA27145 for <[e-mail]>; Wed, 2 Sep 1998 10:31:10 -0700 (PDT)
Received: by l130.wespay.org with Internet Mail Service (5.5.1960.3) id <RYVJG1T6>; Wed, 2 Sep 1998 10:35:02 -0700
Message-ID: <[e-mail]>
From: Peter Yeatrakas <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:34:55 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26986 for ietf-pkix-bks; Wed, 2 Sep 1998 10:17:47 -0700 (PDT)
Received: from shadow.munge.com ([e-mail] [24.3.19.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26982 for <[e-mail]>; Wed, 2 Sep 1998 10:17:45 -0700 (PDT)
Received: from localhost (kaos@localhost) by shadow.munge.com (8.8.7/8.8.7) with SMTP id NAA11361; Wed, 2 Sep 1998 13:20:43 -0400 (EDT) (envelope-from [e-mail])
Date: Wed, 2 Sep 1998 13:20:42 -0400 (EDT)
From: Karen Oostendorp <[e-mail]>
To: [e-mail]
cc: Chris Vance <[e-mail]>
Subject: For Option 1
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26827 for ietf-pkix-bks; Wed, 2 Sep 1998 10:07:57 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26823 for <[e-mail]>; Wed, 2 Sep 1998 10:07:56 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1BY501N>; Wed, 2 Sep 1998 13:12:02 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E12B0DF@WUHER>
From: Peter Hesse <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:11:54 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

----------------------------------------------------------------
Peter M. Hesse           [e-mail]   
CygnaCom Solutions, Inc. [phone](voice) [phone](fax)
Visit the CygnaCom Solutions Web Site:  http://www.cygnacom.com
Page me instantly! http://wwp.mirabilis.com/1942828#pager


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26794 for ietf-pkix-bks; Wed, 2 Sep 1998 10:04:13 -0700 (PDT)
Received: from hq.freegate.com ([208.226.86.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA26790 for <[e-mail]>; Wed, 2 Sep 1998 10:04:12 -0700 (PDT)
Received: (qmail+freegate 12097 invoked by alias); 2 Sep 1998 17:08:41 -0000
Received: from ws37-n0.hq.freegate.com (HELO tardo2.hq.freegate.com) (208.226.86.165) by hq.freegate.com with SMTP; 2 Sep 1998 17:08:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 02 Sep 1998 10:08:25 -0700
To: [e-mail]
From: Joe Tardo <[e-mail]>
Subject: For Option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26755 for ietf-pkix-bks; Wed, 2 Sep 1998 10:00:11 -0700 (PDT)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA26751 for <[e-mail]>; Wed, 2 Sep 1998 10:00:10 -0700 (PDT)
Received: from [10.81.217.217] by eagle.rsa.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 2 Sep 1998 17:17:36 UT
Received: by LOBESTER with Internet Mail Service (5.0.1460.8) id <P3J70J5X>; Wed, 2 Sep 1998 10:07:06 -0700
Message-ID: <6236E58EC451D1119E80006097040ED98D3C04@LOBESTER>
From: Bruce Greenblatt <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:07:04 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Note new phone number below |
                            v
----------------------------------------------------
Bruce Greenblatt      
[e-mail]   Personal: [e-mail]
[phone]        http://www.innetix.com/~bruceg
----------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA26612 for ietf-pkix-bks; Wed, 2 Sep 1998 09:48:47 -0700 (PDT)
Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA26608 for <[e-mail]>; Wed, 2 Sep 1998 09:48:45 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo28.mx.aol.com (IMOv16.1) id 7WUCa24183 for <[e-mail]>; Wed, 2 Sep 1998 12:52:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 2 Sep 1998 12:52:48 EDT
To: [e-mail]
Mime-Version: 1.0
Subject: For Option 1
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 3.0 for Windows 95 sub 18
Sender: [e-mail]
Precedence: bulk

I vote for Option 1.

EAL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA25443 for ietf-pkix-bks; Wed, 2 Sep 1998 09:03:45 -0700 (PDT)
Received: from dkeynt1.DATAKEY.COM (dkeynt1.datakey.com [205.218.59.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25439 for <[e-mail]>; Wed, 2 Sep 1998 09:03:44 -0700 (PDT)
Received: from datakey.com ([205.218.59.20]) by dkeynt1.DATAKEY.COM (Netscape Messaging Server 3.5)  with ESMTP id 382 for <[e-mail]>; Wed, 2 Sep 1998 11:09:26 -0500
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:10:19 -0500
From: "Dale Gustafson" <[e-mail]>
Organization: Datakey, Inc.
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: PKIX Working Group <[e-mail]>
Subject: For Option 2
References: <5040300019913452000002L022*@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA25345 for ietf-pkix-bks; Wed, 2 Sep 1998 08:54:18 -0700 (PDT)
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25341 for <[e-mail]>; Wed, 2 Sep 1998 08:54:17 -0700 (PDT)
Received: from erols.com (207-172-132-91.s91.tnt5.col.erols.com [207.172.132.91]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id MAA06506 for <[e-mail]>; Wed, 2 Sep 1998 12:00:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:06:52 +0000
From: susanmaloney <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA25191 for ietf-pkix-bks; Wed, 2 Sep 1998 08:40:02 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25187 for <[e-mail]>; Wed, 2 Sep 1998 08:40:01 -0700 (PDT)
Received: by gateway.r3.ch id <6803>; Wed, 2 Sep 1998 17:46:05 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Extension of straw poll
Date: Wed, 2 Sep 1998 16:40:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA25160 for ietf-pkix-bks; Wed, 2 Sep 1998 08:36:10 -0700 (PDT)
Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25156 for <[e-mail]>; Wed, 2 Sep 1998 08:36:09 -0700 (PDT)
Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id LAA62454 for <[e-mail]>; Wed, 2 Sep 1998 11:25:17 -0400
Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id LAA37654 for <[e-mail]>; Wed, 2 Sep 1998 11:39:46 -0400
Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU053 id 5040300019913452; Wed, 2 Sep 1998 11:36:41 -0400
From: Ivan Milman <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Message-ID: <5040300019913452000002L022*@MHS>
Date: Wed, 2 Sep 1998 11:36:41 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Thanks,
Ivan

Ivan M. Milman
IBM/Austin
Distributed System Services
Email:  [e-mail]        Phone:
1-512-838-8152                                       Fax:
1-512-838-8597                      T/L:  678-8152


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24801 for ietf-pkix-bks; Wed, 2 Sep 1998 08:01:01 -0700 (PDT)
Received: from thunder.smartlink.navy.mil (thunder.smartlink.navy.mil [204.36.16.143]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24790 for <[e-mail]>; Wed, 2 Sep 1998 08:01:00 -0700 (PDT)
Received: (from smap@localhost) by thunder.smartlink.navy.mil (8.7.3/8.7.3) id LAA01758 for <[e-mail]>; Wed, 2 Sep 1998 11:03:13 -0400 (EDT)
X-Authentication-Warning: thunder.smartlink.navy.mil: smap set sender to <[e-mail]> using -f
Received: from localhost(127.0.0.1) by thunder via smap (V2.0) id xma001756; Wed, 2 Sep 98 11:02:48 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:02:48 -0400
From: Tom Horvath <[e-mail]>
Organization: Smart Link Office
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24771 for ietf-pkix-bks; Wed, 2 Sep 1998 07:59:29 -0700 (PDT)
Received: from stingray.missi.ncsc.mil ([144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24767 for <[e-mail]>; Wed, 2 Sep 1998 07:59:28 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA29628 for <[e-mail]>; Wed, 2 Sep 1998 11:03:31 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA29624 for <[e-mail]>; Wed, 2 Sep 1998 11:03:31 -0400 (EDT)
Received: from [144.51.53.159] (impala.missi.ncsc.mil [144.51.53.159]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA01159 for <[e-mail]>; Wed, 2 Sep 1998 11:02:54 -0400 (EDT)
X-Sender: [e-mail]
Message-Id: <v03110700b2130f1ae193@[144.51.53.159]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 Sep 1998 11:05:12 -0400
To: [e-mail]
From: David Dalkowski <[e-mail]>
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24736 for ietf-pkix-bks; Wed, 2 Sep 1998 07:55:24 -0700 (PDT)
Received: from mclean2-mail.usae.bah.com (mclean2-mail.usae.bah.com [156.80.5.110]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24732 for <[e-mail]>; Wed, 2 Sep 1998 07:55:23 -0700 (PDT)
Received: from bah.com ([156.80.128.200]) by mclean2-mail.usae.bah.com (Netscape Messaging Server 3.01)  with ESMTP id AAA27454 for <[e-mail]>; Wed, 2 Sep 1998 10:54:26 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:00:48 -0400
From: "Hirsch Matthew" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.03 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24667 for ietf-pkix-bks; Wed, 2 Sep 1998 07:48:37 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24663 for <[e-mail]>; Wed, 2 Sep 1998 07:48:35 -0700 (PDT)
Received: from juniper (juniper.chromatix.com [207.97.115.33]) by chromatix.com (8.8.8/8.8.8) with SMTP id KAA09830 for <[e-mail]>; Wed, 2 Sep 1998 10:52:43 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <008401bdd680$fb7af820$[e-mail]>
From: "Bill Lenz" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 10:50:09 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01BDD65F.74558200"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24607 for ietf-pkix-bks; Wed, 2 Sep 1998 07:44:25 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24603 for <[e-mail]>; Wed, 2 Sep 1998 07:44:25 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA02474 for <[e-mail]>; Wed, 2 Sep 1998 07:49:07 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04MF3N5>; Wed, 2 Sep 1998 07:48:19 -0700
Message-ID: <[e-mail]>
From: "Pawluk, Jean" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 07:48:14 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24547 for ietf-pkix-bks; Wed, 2 Sep 1998 07:38:43 -0700 (PDT)
Received: from marlowe.APSINC.COM (marlowe.apsinc.com [198.160.146.80]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24543 for <[e-mail]>; Wed, 2 Sep 1998 07:38:42 -0700 (PDT)
Received: by MARLOWE with Internet Mail Service (5.5.2232.9) id <R4PAPTDT>; Wed, 2 Sep 1998 07:41:32 -0700
Message-ID: <70EAEA308C1FD211BF9B00805FBEF6B4158921@MARLOWE>
From: Bruce Bell <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: for option 1
Date: Wed, 2 Sep 1998 07:41:24 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Bruce S. Bell
Compliance Officer
phone [phone] ext.361
fax      [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA24010 for ietf-pkix-bks; Wed, 2 Sep 1998 06:46:56 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA24006 for <[e-mail]>; Wed, 2 Sep 1998 06:46:55 -0700 (PDT)
Received: from bonsai.chromatix.com (bonsai.chromatix.com [207.97.115.32]) by chromatix.com (8.8.8/8.8.8) with SMTP id JAA09586 for <[e-mail]>; Wed, 2 Sep 1998 09:51:03 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <00c101bdd678$680639e0$[e-mail]>
From: "Nora Kraemer" <[e-mail]>
To: <[e-mail]>
Subject: Option 1
Date: Wed, 2 Sep 1998 09:48:46 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01BDD656.E0E3D100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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:  [phone]
Fax:       [phone]
[e-mail]
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:[e-mail]">[e-mail]</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--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23960 for ietf-pkix-bks; Wed, 2 Sep 1998 06:42:29 -0700 (PDT)
Received: from post.queensu.ca (post.QueensU.CA [130.15.126.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23956 for <[e-mail]>; Wed, 2 Sep 1998 06:42:23 -0700 (PDT)
Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.9.0/8.9.0) with SMTP id JAA29695 for <[e-mail]>; Wed, 2 Sep 1998 09:47:06 -0400 (EDT)
Received: from apollo.ee.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA22895; Wed, 2 Sep 98 09:47:05 EDT
Received: from localhost by apollo.ee.queensu.ca (SMI-8.6/SMI-SVR4) id JAA14757; Wed, 2 Sep 1998 09:47:04 -0400
Date: Wed, 2 Sep 1998 09:47:04 -0400 (EDT)
From: Serge Mister <[e-mail]>
X-Sender: misters@apollo
Reply-To: Serge Mister <[e-mail]>
To: [e-mail]
Subject: For Option 2
Message-Id: <Pine.GSO.3.96.980902094403.14741B-100000@apollo>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23926 for ietf-pkix-bks; Wed, 2 Sep 1998 06:39:03 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23921 for <[e-mail]>; Wed, 2 Sep 1998 06:39:02 -0700 (PDT)
Received: from chromatix.com (maple.chromatix.com [207.97.115.23]) by chromatix.com (8.8.8/8.8.8) with ESMTP id JAA09547; Wed, 2 Sep 1998 09:43:10 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 09:38:22 -0400
From: David Berstein <[e-mail]>
Organization: Chromatix
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

--
      _/_/_/         David M. Berstein
   _/      _/
  _/                 Chromatix, Inc.
 _/           _/  _/ 10451 Twin Rivers Road, Suite 265
_/            _/_/   Columbia, MD 21044
 _/     _/   _/_/    Phone:  [phone] | http://www.chromatix.com
  _/_/_/   _/   _/   Fax:    [phone] | [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23868 for ietf-pkix-bks; Wed, 2 Sep 1998 06:33:01 -0700 (PDT)
Received: from ha1.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23863 for <[e-mail]>; Wed, 2 Sep 1998 06:33:00 -0700 (PDT)
Received: from shadow.munge.com ([24.3.19.3]) by ha1.rdc1.md.home.com (Netscape Mail Server v2.02) with SMTP id AAA28598 for <[e-mail]>; Wed, 2 Sep 1998 06:37:42 -0700
Date: Wed, 2 Sep 1998 09:36:05 -0400 (EDT)
From: Chris Vance <[e-mail]>
To: [e-mail]
Subject: For Option 1
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23392 for ietf-pkix-bks; Wed, 2 Sep 1998 05:47:21 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA23388 for <[e-mail]>; Wed, 2 Sep 1998 05:47:20 -0700 (PDT)
Received: 	id IAA23613; Wed, 2 Sep 1998 08:49:31 -0400
Received: by gateway id <RNJC07PP>; Wed, 2 Sep 1998 08:46:38 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 08:46:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23383 for ietf-pkix-bks; Wed, 2 Sep 1998 05:47:04 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA23378 for <[e-mail]>; Wed, 2 Sep 1998 05:47:03 -0700 (PDT)
Received: 	id IAA23379; Wed, 2 Sep 1998 08:48:31 -0400
Received: by gateway id <RNJC07PN>; Wed, 2 Sep 1998 08:45:38 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], [e-mail], "'Bob Jueneman'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 08:45:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Bob Jueneman[SMTP:[e-mail]]
> Sent: 	September 1, 1998 7:20 PM
> To: 	[e-mail]; [e-mail]; [e-mail]
> 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
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23301 for ietf-pkix-bks; Wed, 2 Sep 1998 05:40:29 -0700 (PDT)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23297 for <[e-mail]>; Wed, 2 Sep 1998 05:40:26 -0700 (PDT)
Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id IAA14963 for <[e-mail]>; Wed, 2 Sep 1998 08:45:08 -0400 (EDT)
Received: from mm60206-lptp.mitre.org (128.29.105.60) by fuzzy.mitre.org with SMTP id 389257; Wed, 02 Sep 1998 08:45:07 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 02 Sep 1998 08:37:49 -0400
To: [e-mail]
From: [e-mail] (Ella P. Gardner)
Subject: For Option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Ella P. Gardner	               phone: [phone]
The MITRE Corporation	         fax    [phone]
1820 Dolley Madison Boulevard	   email: [e-mail]
McLean, VA 22102-3481



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23208 for ietf-pkix-bks; Wed, 2 Sep 1998 05:26:25 -0700 (PDT)
Received: from Sonnet.GSC.GTE.Com (Sonnet.GSC.GTE.Com [131.131.251.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23204 for <[e-mail]>; Wed, 2 Sep 1998 05:26:24 -0700 (PDT)
Received: from gscex01.ndhm.gtegsc.com ("port 3641"@gscex01.ndhm.gtegsc.com) by Sonnet.GSC.GTE.Com (PMDF V5.0-8 #17886) id <[e-mail]> for [e-mail]; Wed, 02 Sep 1998 08:30:46 -0400 (EDT)
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.0.1460.8) id <Q16F2A6D>; Wed, 02 Sep 1998 08:28:31 -0400
Date: Wed, 02 Sep 1998 08:34:05 -0400
From: "Saylor, John" <[e-mail]>
Subject: For Option 2
To: "'[e-mail]'" <[e-mail]>
Message-id: <ED3CB0BEB22CD211A4580008C756184441476F@NDHMEX01>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-type: text/plain
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk

\js



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22985 for ietf-pkix-bks; Wed, 2 Sep 1998 04:53:31 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22981 for <[e-mail]>; Wed, 2 Sep 1998 04:53:29 -0700 (PDT)
Received: from chromatix.com (redoak.chromatix.com [207.97.115.4]) by chromatix.com (8.8.8/8.8.8) with ESMTP id HAA09208 for <[e-mail]>; Wed, 2 Sep 1998 07:57:37 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 08:01:58 -0400
From: John Garner <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: "IETF X.509 PKI" <[e-mail]>
Subject: For Option 1
Content-Type: multipart/alternative; boundary="------------06CB147F224BAAC5EA029C20"
Sender: [e-mail]
Precedence: bulk

--------------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:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]



--------------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; [phone]&nbsp; |&nbsp; <A HREF="http://www.chromatix.com">http://www.chromatix.com</A>
&nbsp; _/_/_/&nbsp;&nbsp; _/&nbsp;&nbsp; _/ Fax:&nbsp;&nbsp;&nbsp; [phone]&nbsp; |&nbsp; [e-mail]</PRE>
&nbsp;</HTML>

--------------06CB147F224BAAC5EA029C20--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22811 for ietf-pkix-bks; Wed, 2 Sep 1998 04:32:01 -0700 (PDT)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22807 for <[e-mail]>; Wed, 2 Sep 1998 04:31:59 -0700 (PDT)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id HAA03515 for <[e-mail]>; Wed, 2 Sep 1998 07:36:35 -0400 (EDT)
Received: from mwppp12.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA26210; Wed, 2 Sep 1998 07:36:34 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 02 Sep 1998 07:36:15 -0400
To: [e-mail]
From: Elliott N Ginsburg <[e-mail]>
Subject: for option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22784 for ietf-pkix-bks; Wed, 2 Sep 1998 04:28:38 -0700 (PDT)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22780 for <[e-mail]>; Wed, 2 Sep 1998 04:28:36 -0700 (PDT)
Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id HAA24382 for <[e-mail]>; Wed, 2 Sep 1998 07:22:32 -0400
Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id HAA24986 for <[e-mail]>; Wed, 2 Sep 1998 07:32:18 -0400
Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU014 id 5040300019901937; Wed, 2 Sep 1998 07:29:13 -0400
From: Mark C Davis <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Message-ID: <5040300019901937000002L072*@MHS>
Date: Wed, 2 Sep 1998 07:29:13 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

______________________________________________________________
Mark C Davis/Raleigh/IBM, DSS Network Security, [e-mail]
[phone], pager 1(800)946-4646 PIN 6066244,  FAX [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22620 for ietf-pkix-bks; Wed, 2 Sep 1998 04:08:00 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22616 for <[e-mail]>; Wed, 2 Sep 1998 04:07:59 -0700 (PDT)
Received: from stefans (t2o68p26.telia.com [62.20.138.146]) by mailc.telia.com (8.8.8/8.8.8) with SMTP id NAA05183; Wed, 2 Sep 1998 13:12:31 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Sep 1998 13:10:19 +0200
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA22617
Sender: [e-mail]
Precedence: bulk

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
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA22485 for ietf-pkix-bks; Wed, 2 Sep 1998 03:54:07 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA22480 for <[e-mail]>; Wed, 2 Sep 1998 03:54:06 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090206582906:162  for <[e-mail]> ; Wed, 2 Sep 1998 06:58:29 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090206582906:162  for <[e-mail]> ; Wed, 2 Sep 1998 06:58:29 -0400 
X-Lotus-FromDomain: IRIS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 2 Sep 1998 07:01:37 -0400
Subject: For Option 2
x-notes-Form: Memo
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA22420 for ietf-pkix-bks; Wed, 2 Sep 1998 03:47:26 -0700 (PDT)
Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA22416 for <[e-mail]>; Wed, 2 Sep 1998 03:47:25 -0700 (PDT)
Received: from wigeon.shiva.com (wigeon.shiva.com [140.248.194.223]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id GAA07839 for <[e-mail]>; Wed, 2 Sep 1998 06:49:05 -0400 (EDT)
Received: from shiva.com by wigeon.shiva.com (SMI-8.6/SMI-SVR4) id GAA05853; Wed, 2 Sep 1998 06:51:37 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 06:51:36 -0400
From: Jesse Walker <[e-mail]>
Organization: Shiva Corporation
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: [e-mail]
Subject: For option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA21021 for ietf-pkix-bks; Wed, 2 Sep 1998 03:06:50 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA21017 for <[e-mail]>; Wed, 2 Sep 1998 03:06:48 -0700 (PDT)
Received: from stefans (t2o68p44.telia.com [62.20.138.164]) by mailc.telia.com (8.8.8/8.8.8) with SMTP id MAA12855; Wed, 2 Sep 1998 12:10:23 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Sep 1998 12:08:11 +0200
To: Santosh Chokhani <[e-mail]>, Sharon Boeyen <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA21018
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Tuesday, September 01, 1998 3:54 PM
>> To:	Sharon Boeyen; '[e-mail]'
>> 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
>> 
>> 

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA21010 for ietf-pkix-bks; Wed, 2 Sep 1998 03:05:49 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA21006 for <[e-mail]>; Wed, 2 Sep 1998 03:05:46 -0700 (PDT)
Received: from stefans (t2o68p44.telia.com [62.20.138.164]) by mailc.telia.com (8.8.8/8.8.8) with SMTP id MAA12859 for <[e-mail]>; Wed, 2 Sep 1998 12:10:24 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Sep 1998 12:08:12 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA21007
Sender: [e-mail]
Precedence: bulk

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19711 for ietf-pkix-bks; Wed, 2 Sep 1998 01:35:50 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19707 for <[e-mail]>; Wed, 2 Sep 1998 01:35:49 -0700 (PDT)
Received: from roger ([10.0.0.21]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA05769 for <[e-mail]>; Wed, 2 Sep 1998 10:37:32 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 02 Sep 1998 10:39:52 +0200
To: [e-mail]
From: Martin =?iso-8859-1?Q?Lindström?= <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA19708
Sender: [e-mail]
Precedence: bulk

 ______________________________________
|________ Entegrity Solutions _________|
|                                      |
| Martin Lindström, Systems Engineer   |
|                                      |                                    
| Finlandsgatan 60                     |
| S-164 74 Kista, Sweden               |
| Direct: [phone]            |
| Fax:    [phone]            |
| Cell:   [phone]           |
|______________________________________|




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19623 for ietf-pkix-bks; Wed, 2 Sep 1998 01:18:14 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19619 for <[e-mail]>; Wed, 2 Sep 1998 01:18:13 -0700 (PDT)
Received: from esmarelda ([10.0.0.11]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA05687 for <[e-mail]>; Wed, 2 Sep 1998 10:20:01 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.44 (Beta)
Date: Wed, 02 Sep 1998 10:19:46 +0200
To: [e-mail]
From: Thomas Caldenius <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19614 for ietf-pkix-bks; Wed, 2 Sep 1998 01:17:50 -0700 (PDT)
Received: from ccas.ru (ext1.ccas.ru [193.233.208.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19610 for <[e-mail]>; Wed, 2 Sep 1998 01:17:47 -0700 (PDT)
Received: from sauron ([193.232.81.34]) by ccas.ru (8.7.5/8.7.3) with SMTP id MAA18012 for <[e-mail]>; Wed, 2 Sep 1998 12:19:50 +0300 (EET DST)
Message-ID: <005501bdd64a$e2293fc0$[e-mail]>
From: "Andrey Lopatenko" <[e-mail]>
To: <[e-mail]>
Subject: Option 2
Date: Wed, 2 Sep 1998 12:22:54 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01BDD66C.68EE6D70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19576 for ietf-pkix-bks; Wed, 2 Sep 1998 01:12:11 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19572 for <[e-mail]>; Wed, 2 Sep 1998 01:12:09 -0700 (PDT)
Received: from jimmie ([10.0.0.22]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA05667 for <[e-mail]>; Wed, 2 Sep 1998 10:13:54 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 02 Sep 1998 10:14:29 +0200
To: [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA08102 for ietf-pkix-bks; Tue, 1 Sep 1998 22:34:25 -0700 (PDT)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA08098 for <[e-mail]>; Tue, 1 Sep 1998 22:34:22 -0700 (PDT)
Received: by relay2.elvis.ru (8.8.5/1.24) id JAA19889; Wed, 2 Sep 1998 09:38:55 +0400 (MSK DST)
Message-ID: <[e-mail]>
X-Mailer: XFMail 1.3 [p0] on Solaris
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Wed, 02 Sep 1998 09:38:55 +0400 (MSK DST)
From: Pavel Krylov <[e-mail]>
To: [e-mail]
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA25421 for ietf-pkix-bks; Tue, 1 Sep 1998 21:15:31 -0700 (PDT)
Received: from mailer.Symantec.Com (mailer.symantec.com [198.6.49.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA25417 for <[e-mail]>; Tue, 1 Sep 1998 21:15:30 -0700 (PDT)
From: [e-mail]
Received: from smtp-ima.symantec.com (host39-sub74.symantec.com [155.64.74.39]) by mailer.Symantec.Com (8.8.8/8.8.8) with ESMTP id VAA24786 for <[e-mail]>; Tue, 1 Sep 1998 21:18:25 -0700 (PDT)
Received: from ccMail by smtp-ima.symantec.com (IMA Internet Exchange 3.1) id 00201118; Tue, 1 Sep 1998 21:17:59 -0700
Mime-Version: 1.0
Date: Tue, 1 Sep 1998 21:14:44 -0700
Message-ID: <[e-mail]>
To: [e-mail]
Subject: option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24963 for ietf-pkix-bks; Tue, 1 Sep 1998 19:38:21 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24959 for <[e-mail]>; Tue, 1 Sep 1998 19:38:19 -0700 (PDT)
Received: from yuriy_nb.spyrus.com ([209.66.65.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA26697 for <[e-mail]>; Tue, 1 Sep 1998 19:42:28 -0700 (PDT)
From: "Yuriy Dzambasow" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 22:44:42 -0400
Message-ID: <001e01bdd61b$a2db8b40$066c42d1@yuriy_nb.spyrus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22960 for ietf-pkix-bks; Tue, 1 Sep 1998 16:20:11 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA22956 for <[e-mail]>; Tue, 1 Sep 1998 16:20:10 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Tue, 01 Sep 1998 17:20:24 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 01 Sep 1998 17:20:10 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX LDAPv2 schema I-D
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA22957
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22879 for ietf-pkix-bks; Tue, 1 Sep 1998 16:12:52 -0700 (PDT)
Received: from aum.proper.com (ts011d20.cup-ca.concentric.net [209.31.12.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA22874 for <[e-mail]>; Tue, 1 Sep 1998 16:12:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Tue, 01 Sep 1998 09:01:49 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: For  Option 2
In-Reply-To: <[e-mail]>
References: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22266 for ietf-pkix-bks; Tue, 1 Sep 1998 14:58:03 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22262 for <[e-mail]>; Tue, 1 Sep 1998 14:58:03 -0700 (PDT)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <RWP6XMJM>; Tue, 1 Sep 1998 15:02:12 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0509BA3E@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:02:05 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22248 for ietf-pkix-bks; Tue, 1 Sep 1998 14:56:13 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22244 for <[e-mail]>; Tue, 1 Sep 1998 14:56:12 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SAKHKX5N>; Tue, 1 Sep 1998 18:00:16 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D210@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 18:00:13 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

For option 1

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
[phone] (voice)
[phone] (fax)
[e-mail]
http://www.cygnacom.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22241 for ietf-pkix-bks; Tue, 1 Sep 1998 14:56:00 -0700 (PDT)
Received: from louie.scs.carleton.ca (louie.scs.carleton.ca [134.117.5.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22237 for <[e-mail]>; Tue, 1 Sep 1998 14:55:58 -0700 (PDT)
Received: from turing (turing [134.117.5.10]) by louie.scs.carleton.ca (96/30.01.97) with SMTP id SAA04115 for <[e-mail]>; Tue, 1 Sep 1998 18:00:00 -0400 (EDT)
Received: from floyd by turing (5.x/SMI-SVR4) id AA03913; Tue, 1 Sep 1998 17:59:55 -0400
From: [e-mail] (Mike Just)
Received: by floyd (5.x/Scs-1.0-client) id AA17259; Tue, 1 Sep 1998 17:59:54 -0400
Date: Tue, 1 Sep 1998 17:59:54 -0400
Message-Id: <9809012159.AA17259@floyd>
To: [e-mail]
Subject: For Option 2
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22199 for ietf-pkix-bks; Tue, 1 Sep 1998 14:52:28 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22195 for <[e-mail]>; Tue, 1 Sep 1998 14:52:26 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SAKHKXZ0>; Tue, 1 Sep 1998 17:56:29 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D20F@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Sharon Boeyen <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Santosh Chokhani'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 17:56:27 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

They are stored in caCertificate attribute of directory entry
representing the subject (subscriber) CA.

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[e-mail]]
> Sent:	Tuesday, September 01, 1998 3:54 PM
> To:	Sharon Boeyen; '[e-mail]'
> 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 [e-mail] 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:[e-mail]  Tel: [phone] 
> >http://www.entrust.com            Fax: [phone] 
> >       
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB     
> Lotsgatan 27 D                  Tel. [phone]              
> 216 42  Malmö                   Fax. [phone]              
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22157 for ietf-pkix-bks; Tue, 1 Sep 1998 14:46:11 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22153 for <[e-mail]>; Tue, 1 Sep 1998 14:46:10 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA04459; Tue, 1 Sep 1998 14:48:30 -0700 (PDT)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA09078; Tue, 1 Sep 1998 14:50:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 01 Sep 1998 14:50:18 -0700
To: [e-mail]
From: Michael Myers <[e-mail]>
Subject: For Option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22067 for ietf-pkix-bks; Tue, 1 Sep 1998 14:37:38 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA22063 for <[e-mail]>; Tue, 1 Sep 1998 14:37:37 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA08469 for <[e-mail]>; Tue, 1 Sep 1998 14:41:46 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id RAA28723; Tue, 1 Sep 1998 17:41:41 -0400
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id RAA01584; Tue, 1 Sep 1998 17:41:43 -0400
Received: from east.sun.com by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id RAA17370; Tue, 1 Sep 1998 17:41:40 -0400
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 17:41:41 -0400
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.5b1 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21256 for ietf-pkix-bks; Tue, 1 Sep 1998 14:28:24 -0700 (PDT)
Received: from spacenet.com.br (saturno.spacenet.com.br [200.255.100.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21252 for <[e-mail]>; Tue, 1 Sep 1998 14:28:20 -0700 (PDT)
Received: from spacenet.com.br (lagoa.spacenet.com.br [200.255.243.65]) by spacenet.com.br (8.8.4/SMI-SVR4) id SAA00630; Tue, 1 Sep 1998 18:18:41 -0300 (EST)
X-Sender: lagoa.spacenet.com.br [200.255.243.65]
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 18:32:48 -0300
From: Eduardo Rosemberg de Moura <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

-- 
Eduardo Rosemberg de Moura
mailto:[e-mail] ([e-mail])
Phone: [phone] (voice)
       [phone] (fax)
Mobile:[phone]
ICQ:   6365858


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21166 for ietf-pkix-bks; Tue, 1 Sep 1998 14:17:29 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21162 for <[e-mail]>; Tue, 1 Sep 1998 14:17:28 -0700 (PDT)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <RWP6XHA8>; Tue, 1 Sep 1998 14:21:33 -0700
Message-ID: <39ADCF833E74D111A2D700805F1951EF056B9D4A@RED-MSG-06>
From: Brian LaMacchia <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:21:30 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20962 for ietf-pkix-bks; Tue, 1 Sep 1998 13:51:24 -0700 (PDT)
Received: from mtahqs2.ncr.disa.mil (mtahqs2.ncr.disa.mil [164.117.144.158]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20957 for <[e-mail]>; Tue, 1 Sep 1998 13:51:23 -0700 (PDT)
Received: by mtahqs2.ncr.disa.mil with Internet Mail Service (5.0.1460.8) id <R503HD5B>; Tue, 1 Sep 1998 20:55:56 -0000
Message-ID: <[e-mail]>
From: "Adkins, Sherrill" <[e-mail]>
To: [e-mail]
Subject: For Option 1
Date: Tue, 1 Sep 1998 20:55:47 -0000 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20951 for ietf-pkix-bks; Tue, 1 Sep 1998 13:50:49 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20947 for <[e-mail]>; Tue, 1 Sep 1998 13:50:48 -0700 (PDT)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id <RWPXN6PY>; Tue, 1 Sep 1998 13:54:57 -0700
Message-ID: <4FD6422BE942D111908D00805F3158DF055136F3@RED-MSG-52>
From: Barb Fox <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: for Option 1
Date: Tue, 1 Sep 1998 13:54:51 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20939 for ietf-pkix-bks; Tue, 1 Sep 1998 13:49:06 -0700 (PDT)
Received: from ultraman.ilan.net (ultraman.ilan.net [207.211.122.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20935 for <[e-mail]>; Tue, 1 Sep 1998 13:49:03 -0700 (PDT)
Received: from secantnet.com ([207.211.125.5]) by ultraman.ilan.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 610-52672U600L100S0V35) with SMTP id AAA5949 for <[e-mail]>; Tue, 1 Sep 1998 16:45:31 -0400
Received: from secantnet.com by secantnet.com (SMI-8.6/SMI-SVR4) id QAA06759; Tue, 1 Sep 1998 16:53:36 -0400
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 16:53:40 -0400
From: Greg Byrd <[e-mail]>
Organization: SECANT Network Technologies
X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: [e-mail]
Subject: for option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

-- 
Greg Byrd                          [e-mail]
SECANT Network Technologies, Inc.  919-462-1900 x229
P.O. Box 14285                     919-462-1933 (fax)
Research Triangle Park, NC 27709


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20554 for ietf-pkix-bks; Tue, 1 Sep 1998 13:02:41 -0700 (PDT)
Received: from chopin.digsigtrust.com (chopin.digsigtrust.com [208.30.64.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20550 for <[e-mail]>; Tue, 1 Sep 1998 13:02:40 -0700 (PDT)
Received: from digsigtrust.com (rfwdesktop.digsigtrust.com [208.30.64.114]) by chopin.digsigtrust.com (8.9.1/8.9.1) with ESMTP id OAA01554 for <[e-mail]>; Tue, 1 Sep 1998 14:06:48 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:31:19 -0600
From: "Russel F. Weiser" <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: multipart/mixed; boundary="------------C201775B051242826227D678"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------C201775B051242826227D678--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20474 for ietf-pkix-bks; Tue, 1 Sep 1998 12:51:51 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20470 for <[e-mail]>; Tue, 1 Sep 1998 12:51:47 -0700 (PDT)
Received: from stefans (t2o68p112.telia.com [62.20.138.232]) by maild.telia.com (8.8.8/8.8.8) with SMTP id VAA14836; Tue, 1 Sep 1998 21:55:47 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 01 Sep 1998 21:53:35 +0200
To: Sharon Boeyen <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA20471
Sender: [e-mail]
Precedence: bulk

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 [e-mail] 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:[e-mail]  Tel: [phone] 
>http://www.entrust.com            Fax: [phone] 
>       
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20428 for ietf-pkix-bks; Tue, 1 Sep 1998 12:44:44 -0700 (PDT)
Received: from fw.ssb.it (fw.ssb.it [192.106.128.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20424 for <[e-mail]>; Tue, 1 Sep 1998 12:44:40 -0700 (PDT)
Received: from notesmail.ssb.it (domino.ssb.it [192.168.19.5]) by ns.ssb.it (8.8.5/8.7.3) with SMTP id XAA26047 for <[e-mail]>; Tue, 1 Sep 1998 23:45:55 +0200 (CEST)
Received: by notesmail.ssb.it(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id C1256672.006D747B ; Tue, 1 Sep 1998 21:55:32 +0200
X-Lotus-FromDomain: SSB
From: "Fabio Omenigrandi" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 1 Sep 1998 21:32:35 +0200
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20329 for ietf-pkix-bks; Tue, 1 Sep 1998 12:37:15 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20325 for <[e-mail]>; Tue, 1 Sep 1998 12:37:13 -0700 (PDT)
Received: 	id PAA27010; Tue, 1 Sep 1998 15:38:44 -0400
Received: by gateway id <RNJC0ZXX>; Tue, 1 Sep 1998 15:35:52 -0400
Message-ID: <[e-mail]>
From: Ron Chittaro <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:35:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20095 for ietf-pkix-bks; Tue, 1 Sep 1998 12:08:59 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20091 for <[e-mail]>; Tue, 1 Sep 1998 12:08:56 -0700 (PDT)
Received: 	id PAA23359; Tue, 1 Sep 1998 15:09:38 -0400
Received: by gateway id <RNJC0ZSP>; Tue, 1 Sep 1998 15:06:46 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Tim Polk'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 15:06:36 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	Tuesday, September 01, 1998 1:39 PM
> To: 	'[e-mail]'
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20090 for ietf-pkix-bks; Tue, 1 Sep 1998 12:08:55 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20086 for <[e-mail]>; Tue, 1 Sep 1998 12:08:54 -0700 (PDT)
Received: 	id PAA23418; Tue, 1 Sep 1998 15:10:18 -0400
Received: by gateway id <RNJC0ZST>; Tue, 1 Sep 1998 15:07:26 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:07:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20051 for ietf-pkix-bks; Tue, 1 Sep 1998 12:03:04 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20047 for <[e-mail]>; Tue, 1 Sep 1998 12:03:03 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id PAA06735 for <[e-mail]>; Tue, 1 Sep 1998 15:07:10 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 15:07:07 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19990 for ietf-pkix-bks; Tue, 1 Sep 1998 11:59:18 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19986 for <[e-mail]>; Tue, 1 Sep 1998 11:59:17 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQfezk12448; Tue, 1 Sep 1998 15:03:22 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRA0CT>; Tue, 1 Sep 1998 15:05:27 -0400
Message-ID: <[e-mail]>
From: MHenry <[e-mail]>
To: [e-mail]
Subject: for option 2
Date: Tue, 1 Sep 1998 15:05:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19970 for ietf-pkix-bks; Tue, 1 Sep 1998 11:56:58 -0700 (PDT)
Received: from stingray.missi.ncsc.mil ([144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19966 for <[e-mail]>; Tue, 1 Sep 1998 11:56:57 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA22769 for <[e-mail]>; Tue, 1 Sep 1998 15:00:56 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA22763 for <[e-mail]>; Tue, 1 Sep 1998 15:00:55 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA14818 for <[e-mail]>; Tue, 1 Sep 1998 15:00:19 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 01 Sep 1998 15:01:51 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Tue, 1 Sep 1998 15:01:51 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'IETF/PKIX'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:01:50 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19925 for ietf-pkix-bks; Tue, 1 Sep 1998 11:47:27 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19921 for <[e-mail]>; Tue, 1 Sep 1998 11:47:25 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Tue, 1 Sep 1998 19:51:30 +0100
Received: from mail0.sse.ie (unverified [193.120.32.47]) by mail2.sse.ie (Integralis SMTPRS 2.04) with ESMTP id <[e-mail]>; Tue, 01 Sep 1998 19:51:21 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id TAA07273 for <[e-mail]>; Tue, 1 Sep 1998 19:51:19 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
Reply-To: [e-mail]
To: [e-mail]
Subject: For Option 2
From: Stephen Farrell <[e-mail]>
MIME-Version: 1.0
Date: Tue, 01 Sep 1998 19:52:09 +0100
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19878 for ietf-pkix-bks; Tue, 1 Sep 1998 11:38:52 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19874 for <[e-mail]>; Tue, 1 Sep 1998 11:38:51 -0700 (PDT)
Received: from chromatix.com (poplar.chromatix.com [207.97.115.14]) by chromatix.com (8.8.8/8.8.8) with ESMTP id OAA06632 for <[e-mail]>; Tue, 1 Sep 1998 14:42:57 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:43:28 -0400
From: Michael Maloney <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: multipart/mixed; boundary="------------10B5479D1700C8A1FFAC998E"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
title:          Senior Engineer
tel;work:       301 596-8466
tel;fax:        [phone]
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------10B5479D1700C8A1FFAC998E--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19820 for ietf-pkix-bks; Tue, 1 Sep 1998 11:35:01 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19816 for <[e-mail]>; Tue, 1 Sep 1998 11:35:00 -0700 (PDT)
Received: 	id OAA19092; Tue, 1 Sep 1998 14:36:01 -0400
Received: by gateway id <RNJC0ZNA>; Tue, 1 Sep 1998 14:33:07 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 14:33:05 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19706 for ietf-pkix-bks; Tue, 1 Sep 1998 11:23:55 -0700 (PDT)
Received: from inetgw.fs.lmco.com (inetgw.fs.lmco.com [204.177.125.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19702 for <[e-mail]>; Tue, 1 Sep 1998 11:23:53 -0700 (PDT)
Received: (from mail@localhost) by inetgw.fs.lmco.com (AIX4.2/UCB 8.7/8.7) id OAA33110 for <[e-mail]>; Tue, 1 Sep 1998 14:28:26 -0400 (EDT)
Received: from dmsman.man.fs.lmco.com(158.187.195.16) by inetgw.fs.lmco.com via smap (V2.0) id xma075892; Tue, 1 Sep 98 14:27:58 -0400
Received: by dmsman.man.fs.lmco.com with Internet Mail Service (5.5.2232.9) id <RQDKB2NB>; Tue, 1 Sep 1998 14:26:58 -0400
Message-ID: <[e-mail]>
From: "Rogers III, Edward B." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:26:56 -0400 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

R/ Ed
Technical Lead, DMS Security Evolution
Lockheed Martin Federal Systems



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19574 for ietf-pkix-bks; Tue, 1 Sep 1998 11:06:39 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19570 for <[e-mail]>; Tue, 1 Sep 1998 11:06:38 -0700 (PDT)
Received: from cedar.chromatix.com (cedar.chromatix.com [207.97.115.12]) by chromatix.com (8.8.8/8.8.8) with SMTP id OAA06514; Tue, 1 Sep 1998 14:10:42 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <018201bdd5d4$10ca0520$[e-mail]>
From: "Steven (Pete) Peterson" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:12:22 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017F_01BDD5B2.89B86520"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19563 for ietf-pkix-bks; Tue, 1 Sep 1998 11:05:08 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19559 for <[e-mail]>; Tue, 1 Sep 1998 11:05:04 -0700 (PDT)
Received: from chromatix.com (kapok.chromatix.com [207.97.115.37]) by chromatix.com (8.8.8/8.8.8) with ESMTP id OAA06501 for <[e-mail]>; Tue, 1 Sep 1998 14:09:07 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:12:56 -0400
From: Thomas Llanso <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

--

      _/_/_/                   Thomas H. Llanso
   _/      _/
  _/       _/                  Chromatix, Inc.
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/      Phone:  [phone]  |
http://www.chromatix.com
 _/_/_/   _/   _/      Fax:    [phone]  |
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19529 for ietf-pkix-bks; Tue, 1 Sep 1998 11:03:15 -0700 (PDT)
Received: from hq.vni.net (hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19524 for <[e-mail]>; Tue, 1 Sep 1998 11:03:12 -0700 (PDT)
Received: from ieca.com (nova-aaa-061.vni.net [205.177.115.61]) by hq.vni.net (8.8.8/8.8.5) with ESMTP id OAA10687 for <[e-mail]>; Tue, 1 Sep 1998 14:07:49 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:06:38 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.06 [en] (Win98; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19400 for ietf-pkix-bks; Tue, 1 Sep 1998 10:53:33 -0700 (PDT)
Received: from hq.ljl.COM (hq.ljl.com [206.151.234.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19394 for <[e-mail]>; Tue, 1 Sep 1998 10:53:28 -0700 (PDT)
Received: from larry.ljl.com by hq.ljl.COM. with smtp id aa23343; Tue, 1 Sep 1998 12:58:23 -0500
Received: by localhost with Microsoft MAPI; Tue, 1 Sep 1998 12:58:07 -0500
Message-ID: <[e-mail]>
From: Larry Layten <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 12:58:05 -0500
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19364 for ietf-pkix-bks; Tue, 1 Sep 1998 10:50:49 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19360 for <[e-mail]>; Tue, 1 Sep 1998 10:50:48 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Tue, 01 Sep 1998 11:51:07 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 01 Sep 1998 11:51:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes- PKIX LDAPv2 schema I-D
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA19361
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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.







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19335 for ietf-pkix-bks; Tue, 1 Sep 1998 10:44:44 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19330 for <[e-mail]>; Tue, 1 Sep 1998 10:44:43 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id NAA09240 for <[e-mail]>; Tue, 1 Sep 1998 13:52:46 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id NAA17303; Tue, 1 Sep 1998 13:51:23 -0400
Date: Tue, 1 Sep 1998 13:51:23 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19270 for ietf-pkix-bks; Tue, 1 Sep 1998 10:35:35 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19266 for <[e-mail]>; Tue, 1 Sep 1998 10:35:34 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Tue, 01 Sep 1998 11:35:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 01 Sep 1998 11:35:15 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA19267
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19246 for ietf-pkix-bks; Tue, 1 Sep 1998 10:32:52 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19242 for <[e-mail]>; Tue, 1 Sep 1998 10:32:51 -0700 (PDT)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id NAA17339 for <[e-mail]>; Tue, 1 Sep 1998 13:37:18 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 01 Sep 1998 13:39:54 -0400
To: "'[e-mail]'" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: For  Option 2
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19241 for ietf-pkix-bks; Tue, 1 Sep 1998 10:32:51 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19237 for <[e-mail]>; Tue, 1 Sep 1998 10:32:49 -0700 (PDT)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id NAA17327 for <[e-mail]>; Tue, 1 Sep 1998 13:37:11 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 01 Sep 1998 13:39:47 -0400
To: "'[e-mail]'" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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.






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18845 for ietf-pkix-bks; Tue, 1 Sep 1998 09:34:40 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA18836 for <[e-mail]>; Tue, 1 Sep 1998 09:34:39 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA06062 for <[e-mail]>; Tue, 1 Sep 1998 09:38:47 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id MAA08888; Tue, 1 Sep 1998 12:38:43 -0400
Received: from saguaro.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id MAA22275; Tue, 1 Sep 1998 12:38:45 -0400
Received: by saguaro.East.Sun.COM (SMI-8.6/SMI-SVR4) id MAA16476; Tue, 1 Sep 1998 12:38:44 -0400
From: Anne Anderson - Sun Microsystems <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue,  1 Sep 1998 12:38:44 -0400 (EDT)
To: [e-mail]
Subject: For Option 1
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13804.8941.806700.92413@saguaro>
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18167 for ietf-pkix-bks; Tue, 1 Sep 1998 08:12:58 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA18162 for <[e-mail]>; Tue, 1 Sep 1998 08:12:56 -0700 (PDT)
Received: 	id LAA21117; Tue, 1 Sep 1998 11:13:29 -0400
Received: by gateway id <RNJC0YLQ>; Tue, 1 Sep 1998 11:10:37 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Steve Kent'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 11:10:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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 [e-mail] 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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18070 for ietf-pkix-bks; Tue, 1 Sep 1998 08:03:07 -0700 (PDT)
Received: from hrdcgate.nhq.hrdc-drhc.gc.ca (hrdcgate.nhq.hrdc-drhc.gc.ca [198.103.152.3]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA18066 for <[e-mail]>; Tue, 1 Sep 1998 08:03:05 -0700 (PDT)
Received: from svmailsw1.hq-ac.prv by hrdcgate.nhq.hrdc-drhc.gc.ca via smtpd (for imc.org [206.184.129.134]) with SMTP; 1 Sep 1998 15:07:43 UT
Received: from gwsmtpim1.hq-ac.prv (10.54.254.16) by svmailsw1.hq-ac.prv (NPlex 1.3.152) for [e-mail]; 1 Sep 1998 11:10:02 -0400
Received: by gwsmtpim1.hq-ac.prv with VINES-ISMTP; Tue, 1 Sep 98 11:10:04 -0400
Date: Tue, 1 Sep 98 11:09:56 -0400
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
To: <[e-mail]>
From: "Fred Gloade Hrdc-drhc" <[e-mail]>
Reply-To: <[e-mail]>
Subject: fwd: Re: ...no subject...
X-Incognito-SN: 1396
X-Incognito-Version: 4.11.23
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA18067
Sender: [e-mail]
Precedence: bulk

Fred Gloade 
Senior Auditor/Vérificateur principal
Information Technology and Systems
Technologies et systèmes informatiques
[phone]
[e-mail]

-------------
Original Text
From: "Steve Coya" <[e-mail]>, on 9/1/98 8:37 AM:
To: [e-mail]@NHQ
Cc: INET[<[e-mail]>]

Fred,

Your question should be sent to the PKIX Working Group:
[e-mail]




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
>>[phone]
>>[e-mail]
>>
>>
>>

o



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA06142 for ietf-pkix-bks; Wed, 30 Sep 1998 20:42:21 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA06133 for <[e-mail]>; Wed, 30 Sep 1998 20:42:19 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id AAA28197; Thu, 1 Oct 1998 00:48:37 -0300
Date: Thu, 1 Oct 1998 00:48:37 -0300 (EST)
From: Ed Gerck <[e-mail]>
To: Stefan Santesson <[e-mail]>
cc: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Thu, 1 Oct 1998, Stefan Santesson wrote:

>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"

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!

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

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?

>Regardless of this I fail to see how this can be used to pick the right
>"non-repudiation" certificate in the Java script application.

Please read above, I hope it is clearer now.

> I also fail
>to understand if you suggest that the current SSL/TLS functions solves all
>my problems or just a part of them.
>

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

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


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
>equal to suggest that the SSN should be encrypted with a secret key (where
>the "salt" is being that secret key).
>

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


>You and I can argue for centuries if certificates handled in browsers
>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
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [e-mail]
http://novaware.cps.softex.br



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03186 for ietf-pkix-bks; Wed, 30 Sep 1998 16:21:27 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03180 for <[e-mail]>; Wed, 30 Sep 1998 16:21:04 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX35284S>; Thu, 1 Oct 1998 09:25:21 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B9C9@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Dave Horvath '" <[e-mail]>, "'Stefan Santesson '" <[e-mail]>
Cc: Alan Lloyd <[e-mail]>, "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 09:25:18 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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; '[e-mail] '; '[e-mail] ';
'[e-mail] '
Sent: 10/1/98 8:53:52 AM
Subject: Re: NEW Data type for certificate selection ?

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,
>> 
>> 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 ([e-mail])
>> >
>> >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: [e-mail]
>> >> To: [e-mail]; [e-mail];
>> >> [e-mail]
>> >> Sent: 9/29/98 1:01:30 PM
>> >> Subject: Re: NEW Data type for certificate selection ?
>> >>
>> >> 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:
>> >> "
>> >>  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.
>> >>
>> >> "
>> >> Oh well - that counts me out. I cannot do solutions - without the
>> >> solution :-)))
>> >> regards alan
>> >>
>> >> Peter.
>> >>
>> >
>> >
>> >----------------- SEIS mailing list ([e-mail])
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: [e-mail]
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. [phone]
>> 216 42  Malmö                   Fax. [phone]
>> Sweden                        Mobile [phone]
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03019 for ietf-pkix-bks; Wed, 30 Sep 1998 15:50:00 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03010 for <[e-mail]>; Wed, 30 Sep 1998 15:49:51 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id AAA07763; Thu, 1 Oct 1998 00:56:48 +0200 (CEST)
Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA28412; Thu, 1 Oct 1998 00:56:46 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 00:53:52 +0200
To: Dave Horvath <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Cc: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA03011
Sender: [e-mail]
Precedence: bulk

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,
>> 
>> 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 ([e-mail])
>> >
>> >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: [e-mail]
>> >> To: [e-mail]; [e-mail];
>> >> [e-mail]
>> >> Sent: 9/29/98 1:01:30 PM
>> >> Subject: Re: NEW Data type for certificate selection ?
>> >>
>> >> 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:
>> >> "
>> >>  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.
>> >>
>> >> "
>> >> Oh well - that counts me out. I cannot do solutions - without the
>> >> solution :-)))
>> >> regards alan
>> >>
>> >> Peter.
>> >>
>> >
>> >
>> >----------------- SEIS mailing list ([e-mail])
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: [e-mail]
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. [phone]
>> 216 42  Malmö                   Fax. [phone]
>> Sweden                        Mobile [phone]
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02842 for ietf-pkix-bks; Wed, 30 Sep 1998 15:31:06 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02838 for <[e-mail]>; Wed, 30 Sep 1998 15:31:04 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id AAA18769; Thu, 1 Oct 1998 00:37:58 +0200 (CEST)
Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA23766; Thu, 1 Oct 1998 00:37:55 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 00:35:02 +0200
To: Ed Gerck <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Cc: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA02839
Sender: [e-mail]
Precedence: bulk

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:
>
>>
>>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.
>
>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.
>
>>
>>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.
>
>
>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
>______________________________________________________________________
>Dr.rer.nat. E. Gerck                     [e-mail]
>http://novaware.cps.softex.br
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00464 for ietf-pkix-bks; Wed, 30 Sep 1998 11:04:46 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00443 for <[e-mail]>; Wed, 30 Sep 1998 11:02:19 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id PAA27526; Wed, 30 Sep 1998 15:08:28 -0300
Date: Wed, 30 Sep 1998 15:08:26 -0300 (EST)
From: Ed Gerck <[e-mail]>
To: Stefan Santesson <[e-mail]>
cc: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 30 Sep 1998, Stefan Santesson wrote:

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

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.

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


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
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [e-mail]
http://novaware.cps.softex.br





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00258 for ietf-pkix-bks; Wed, 30 Sep 1998 10:37:53 -0700 (PDT)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00254 for <[e-mail]>; Wed, 30 Sep 1998 10:37:44 -0700 (PDT)
Received: from klerer.basit.com (shiva120 [128.209.144.120]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id NAA06626 for <[e-mail]>; Wed, 30 Sep 1998 13:44:11 -0400 (EDT)
Message-ID: <008101bdec99$e9fa7a60$[e-mail]>
From: "Robert Klerer" <[e-mail]>
To: <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Date: Wed, 30 Sep 1998 13:44:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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 ([e-mail])
>>
>>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: [e-mail]
>>> To: [e-mail]; [e-mail];
>>> [e-mail]
>>> Sent: 9/29/98 1:01:30 PM
>>> Subject: Re: NEW Data type for certificate selection ?
>>>
>>> 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:
>>> "
>>>  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.
>>>
>>> "
>>> Oh well - that counts me out. I cannot do solutions - without the
>>> solution :-)))
>>> regards alan
>>>
>>> Peter.
>>>
>>
>>
>>----------------- SEIS mailing list ([e-mail])
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: [e-mail]
>>
>>
>>
>-------------------------------------------------------------------
>Stefan Santesson                <[e-mail]>
>Accurata Systemsäkerhet AB
>Lotsgatan 27 D                  Tel. [phone]
>216 42  Malmö                   Fax. [phone]
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29980 for ietf-pkix-bks; Wed, 30 Sep 1998 10:14:37 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29976 for <[e-mail]>; Wed, 30 Sep 1998 10:14:34 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id NAA08397; Wed, 30 Sep 1998 13:21:48 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 30 Sep 1998 13:20:43 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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,
> 
> 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 ([e-mail])
> >
> >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: [e-mail]
> >> To: [e-mail]; [e-mail];
> >> [e-mail]
> >> Sent: 9/29/98 1:01:30 PM
> >> Subject: Re: NEW Data type for certificate selection ?
> >>
> >> 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:
> >> "
> >>  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.
> >>
> >> "
> >> Oh well - that counts me out. I cannot do solutions - without the
> >> solution :-)))
> >> regards alan
> >>
> >> Peter.
> >>
> >
> >
> >----------------- SEIS mailing list ([e-mail])
> >Info about this list: http://www.nc-forum.com/seis
> >SEIS Contact: [e-mail]
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. [phone]
> 216 42  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28790 for ietf-pkix-bks; Wed, 30 Sep 1998 07:39:59 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28786 for <[e-mail]>; Wed, 30 Sep 1998 07:39:57 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id QAA02188; Wed, 30 Sep 1998 16:46:36 +0200 (CEST)
Received: from stefans (t3o68p79.telia.com [62.20.139.79]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA25183; Wed, 30 Sep 1998 16:46:29 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 30 Sep 1998 16:43:41 +0200
To: David Horvath <[e-mail]>, Alan Lloyd <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA28787
Sender: [e-mail]
Precedence: bulk

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 ([e-mail])
>
>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: [e-mail]
>> To: [e-mail]; [e-mail];
>> [e-mail]
>> Sent: 9/29/98 1:01:30 PM
>> Subject: Re: NEW Data type for certificate selection ?
>> 
>> 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:
>> "
>>  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.
>> 
>> "
>> Oh well - that counts me out. I cannot do solutions - without the
>> solution :-)))
>> regards alan
>> 
>> Peter.
>>
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [e-mail]
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA05527 for ietf-pkix-bks; Tue, 29 Sep 1998 20:00:40 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA05523 for <[e-mail]>; Tue, 29 Sep 1998 20:00:39 -0700 (PDT)
Received: from chromatix.com (cc1020663-a.hwrd1.md.home.com [24.3.62.220]) by chromatix.com (8.8.8/8.8.8) with ESMTP id XAA06421; Tue, 29 Sep 1998 23:07:34 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 30 Sep 1998 11:15:51 -0400
From: David Horvath <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.05 [en]C-AtHome0404  (Win95; U)
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
References: <D1A949D4508DD1119C8100400533BEDC07B96A@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
> To: [e-mail]; [e-mail];
> [e-mail]
> Sent: 9/29/98 1:01:30 PM
> Subject: Re: NEW Data type for certificate selection ?
> 
> 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:
> "
>  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.
> 
> "
> Oh well - that counts me out. I cannot do solutions - without the
> solution :-)))
> regards alan
> 
> Peter.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06015 for ietf-pkix-bks; Tue, 29 Sep 1998 10:32:40 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06011 for <[e-mail]>; Tue, 29 Sep 1998 10:32:39 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA18568; Tue, 29 Sep 1998 10:38:57 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.67 (Beta)
Date: Tue, 29 Sep 1998 13:30:03 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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, [e-mail] 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).
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA03135 for ietf-pkix-bks; Tue, 29 Sep 1998 05:01:19 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA03131 for <[e-mail]>; Tue, 29 Sep 1998 05:01:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA07388; Tue, 29 Sep 1998 08:06:01 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
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: [e-mail]
Precedence: bulk

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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25568 for ietf-pkix-bks; Tue, 29 Sep 1998 00:26:22 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA25564 for <[e-mail]>; Tue, 29 Sep 1998 00:26:14 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA18103; Tue, 29 Sep 1998 09:32:34 +0200
Received: by HYDRA with Microsoft Mail id <01BDEB8B.32948E60@HYDRA>; Tue, 29 Sep 1998 09:26:11 +0200
Message-ID: <01BDEB8B.32948E60@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 09:26:09 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Peter, see in-line comment below.

On Tue, 29 Sep 1998, Peter Gutmann wrote:

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

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA07285 for ietf-pkix-bks; Mon, 28 Sep 1998 15:25:34 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA07281 for <[e-mail]>; Mon, 28 Sep 1998 15:25:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Mon, 28 Sep 1998 15:31:45 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA07078 for ietf-pkix-bks; Mon, 28 Sep 1998 14:49:02 -0700 (PDT)
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07074 for <[e-mail]>; Mon, 28 Sep 1998 14:49:01 -0700 (PDT)
From: [e-mail]
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id OAA21156 for <[e-mail]>; Mon, 28 Sep 1998 14:55:57 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id OAA06803 for <[e-mail]>; Mon, 28 Sep 1998 14:55:56 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 8825668D.007878E7 ; Mon, 28 Sep 1998 14:55:52 -0700
X-Lotus-FromDomain: 3COM
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 28 Sep 1998 14:55:42 -0700
Subject: A question and comment about PKIX - Part 1, Version 11.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06782 for ietf-pkix-bks; Mon, 28 Sep 1998 14:07:46 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06778 for <[e-mail]>; Mon, 28 Sep 1998 14:07:43 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX3528L9>; Tue, 29 Sep 1998 07:11:57 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B96A@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 29 Sep 1998 07:11:56 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

 
Snip

----------
From: [e-mail]
To: [e-mail]; [e-mail];
[e-mail]
Sent: 9/29/98 1:01:30 PM
Subject: Re: NEW Data type for certificate selection ?

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: 
"
 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.

" 
Oh well - that counts me out. I cannot do solutions - without the
solution :-)))
regards alan
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06221 for ietf-pkix-bks; Mon, 28 Sep 1998 12:40:54 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06217 for <[e-mail]>; Mon, 28 Sep 1998 12:40:51 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id QAA25781; Mon, 28 Sep 1998 16:47:26 -0300
Date: Mon, 28 Sep 1998 16:47:25 -0300 (EST)
From: Ed Gerck <[e-mail]>
To: Peter Gutmann <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 29 Sep 1998, Peter Gutmann wrote:

>Stefan Santesson <[e-mail]> 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".

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                     [e-mail]
http://novaware.cps.softex.br









Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05133 for ietf-pkix-bks; Mon, 28 Sep 1998 10:36:01 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA05129 for <[e-mail]>; Mon, 28 Sep 1998 10:36:00 -0700 (PDT)
Received: 	id NAA23349; Mon, 28 Sep 1998 13:40:24 -0400
Received: by gateway id <TTXVY461>; Mon, 28 Sep 1998 13:36:56 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Time Stamp and Notary Drafts
Date: Mon, 28 Sep 1998 13:36:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA03570 for ietf-pkix-bks; Mon, 28 Sep 1998 07:54:56 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03564 for <[e-mail]>; Mon, 28 Sep 1998 07:54:54 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA31163; Tue, 29 Sep 1998 03:01:30 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90699489017466>; Tue, 29 Sep 1998 03:01:30 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: NEW Data type for certificate selection ?
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 29 Sep 1998 03:01:30 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Stefan Santesson <[e-mail]> 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.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA03363 for ietf-pkix-bks; Mon, 28 Sep 1998 07:26:38 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA03359 for <[e-mail]>; Mon, 28 Sep 1998 07:26:37 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Mon, 28 Sep 1998 07:32:49 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Questions about PKIX
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02828 for ietf-pkix-bks; Mon, 28 Sep 1998 06:08:00 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA02824 for <[e-mail]>; Mon, 28 Sep 1998 06:07:58 -0700 (PDT)
Received: 	id JAA14392; Mon, 28 Sep 1998 09:12:56 -0400
Received: by gateway id <TTXVYTLB>; Mon, 28 Sep 1998 09:09:28 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Alan Lloyd'" <[e-mail]>
Cc: "'Warwick Ford'" <[e-mail]>, "'Steve Kent'" <[e-mail]>
Subject: RE: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 09:07:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 27, 1998 6:24 PM
> To: 	'[e-mail]'
> 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
>    
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02819 for ietf-pkix-bks; Mon, 28 Sep 1998 06:07:45 -0700 (PDT)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02815 for <[e-mail]>; Mon, 28 Sep 1998 06:07:43 -0700 (PDT)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id WAA08964; Mon, 28 Sep 1998 22:03:40 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA04781; Mon, 28 Sep 98 22:08:15 JST
Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id WAA15195; Mon, 28 Sep 1998 22:20:13 +0900 (JST)
Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA27264; Mon, 28 Sep 98 22:14:03 JST
Received: from zaku by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA23057; Mon, 28 Sep 1998 22:14:02 +0900
Message-Id: <[e-mail]>
Date: Mon, 28 Sep 1998 22:11:42 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: NEW Data type for certificate selection ?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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 ?

> 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 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
Mitsubishi Electric Corp.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02371 for ietf-pkix-bks; Mon, 28 Sep 1998 05:12:10 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA02367 for <[e-mail]>; Mon, 28 Sep 1998 05:12:08 -0700 (PDT)
Received: 	id IAA05607; Mon, 28 Sep 1998 08:16:44 -0400
Received: by gateway id <TTXVYT12>; Mon, 28 Sep 1998 08:13:15 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Mon, 28 Sep 1998 08:13:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 27, 1998 12:32 PM
> To: 	'[e-mail]'
> Cc: 	[e-mail]
> 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:	[e-mail] [SMTP:[e-mail]]
> > Sent:	Thursday, September 24, 1998 10:27 AM
> > Cc:	[e-mail]
> > 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 [e-mail]
> > 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:	[e-mail].  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 >> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA29636 for ietf-pkix-bks; Mon, 28 Sep 1998 02:14:15 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA29632 for <[e-mail]>; Mon, 28 Sep 1998 02:14:11 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id LAA01066; Mon, 28 Sep 1998 11:20:25 +0200 (MET DST)
Received: from stefans (t4o68p93.telia.com [62.20.139.213]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id LAA29513; Mon, 28 Sep 1998 11:20:09 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Sep 1998 11:17:31 +0200
To: Alan Lloyd <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA29633
Sender: [e-mail]
Precedence: bulk

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






At 09:30 AM 9/27/98 +1000, Alan Lloyd wrote:
>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: [e-mail]; [e-mail]; [e-mail];
>[e-mail]
>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.
>
>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                <[e-mail]>
>Accurata Systemsäkerhet AB     
>Lotsgatan 27 D                  Tel. [phone]              
>216 42  Malmö                   Fax. [phone]              
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA29311 for ietf-pkix-bks; Mon, 28 Sep 1998 01:12:47 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA29307 for <[e-mail]>; Mon, 28 Sep 1998 01:12:40 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX3528J0>; Mon, 28 Sep 1998 18:16:46 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B94C@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'tyone '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 28 Sep 1998 18:16:45 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
Sent: 9/28/98 12:19:19 PM
Subject: Re: NEW Data type for certificate selection ?

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.


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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA28865 for ietf-pkix-bks; Mon, 28 Sep 1998 00:48:15 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA28861 for <[e-mail]>; Mon, 28 Sep 1998 00:48:14 -0700 (PDT)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id DAA10830 for <[e-mail]>; Mon, 28 Sep 1998 03:59:14 -0400 (EDT)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id DAA28532 for <[e-mail]>; Mon, 28 Sep 1998 03:53:32 -0400 (EDT)
Received: by mta2.lotus.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525668D.002BF5DA ; Mon, 28 Sep 1998 04:00:09 -0400
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
cc: Helmut_Speichermann/FRA/[e-mail], Boris_Baltzer/MUC1/[e-mail], Georg_Zyprian/FRA/[e-mail]
Message-ID: <[e-mail]>
Date: Mon, 28 Sep 1998 09:51:59 +0200
Subject: Questions about PKIX
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10325 for ietf-pkix-bks; Sun, 27 Sep 1998 19:17:09 -0700 (PDT)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10321 for <[e-mail]>; Sun, 27 Sep 1998 19:17:07 -0700 (PDT)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id LAA05603 for <[e-mail]>; Mon, 28 Sep 1998 11:13:31 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA27021; Mon, 28 Sep 98 11:18:05 JST
Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id LAA04167 for <[e-mail]>; Mon, 28 Sep 1998 11:30:03 +0900 (JST)
Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA15585; Mon, 28 Sep 98 11:23:54 JST
Received: from edberg by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA09263; Mon, 28 Sep 1998 11:23:53 +0900
Message-Id: <[e-mail]>
Date: Mon, 28 Sep 1998 11:19:19 +0900
From: tyone <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (WinNT; I)
Mime-Version: 1.0
To: [e-mail]
Subject: Re: NEW Data type for certificate selection ?
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09408 for ietf-pkix-bks; Sun, 27 Sep 1998 15:20:57 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09403 for <[e-mail]>; Sun, 27 Sep 1998 15:20:53 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX352825>; Mon, 28 Sep 1998 08:24:58 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B944@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: comments on draft-ietf-pkix-ipki2opp-08.txt
Date: Mon, 28 Sep 1998 08:24:56 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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
   


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA08414 for ietf-pkix-bks; Sun, 27 Sep 1998 09:26:54 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA08410 for <[e-mail]>; Sun, 27 Sep 1998 09:26:53 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDQFB>; Sun, 27 Sep 1998 12:32:13 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1ADC@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Sun, 27 Sep 1998 12:32:11 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:	[e-mail] [SMTP:[e-mail]]
> Sent:	Thursday, September 24, 1998 10:27 AM
> Cc:	[e-mail]
> 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 [e-mail]
> 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:	[e-mail].  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 >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21031 for ietf-pkix-bks; Sat, 26 Sep 1998 16:25:58 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21027 for <[e-mail]>; Sat, 26 Sep 1998 16:25:50 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TS1VBY1B>; Sun, 27 Sep 1998 09:30:03 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B92F@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'Stefan Santesson '" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Sun, 27 Sep 1998 09:30:02 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA21028
Sender: [e-mail]
Precedence: bulk

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: [e-mail]; [e-mail]; [e-mail];
[e-mail]
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.

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                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23104 for ietf-pkix-bks; Fri, 25 Sep 1998 09:18:29 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23100 for <[e-mail]>; Fri, 25 Sep 1998 09:18:29 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA27992; Fri, 25 Sep 1998 09:22:39 -0700 (PDT)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA00996; Fri, 25 Sep 1998 09:24:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Sep 1998 09:24:36 -0700
To: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
From: Michael Myers <[e-mail]>
Subject: Re: Archive cutoff & Retention period
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA23101
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22174 for ietf-pkix-bks; Fri, 25 Sep 1998 07:21:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22170 for <[e-mail]>; Fri, 25 Sep 1998 07:21:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06021; Fri, 25 Sep 1998 10:27:54 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-08.txt
Date: Fri, 25 Sep 1998 10:27:54 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail] 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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21217 for ietf-pkix-bks; Fri, 25 Sep 1998 04:31:00 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21213 for <[e-mail]>; Fri, 25 Sep 1998 04:30:59 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id NAA16726; Fri, 25 Sep 1998 13:37:15 +0200 (CEST)
Received: from stefans (t3o68p4.telia.com [62.20.139.4]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA10344; Fri, 25 Sep 1998 13:37:14 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Sep 1998 13:34:29 +0200
To: "Miklos, Sue A." <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA21214
Sender: [e-mail]
Precedence: bulk

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:
> 
>
>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:[e-mail]]
>>Sent: 	Thursday, September 24, 1998 8:41 AM
>>To: 	[e-mail]; [e-mail]; [e-mail];
>>[e-mail]
>>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                <[e-mail]>
>>Accurata Systemsäkerhet AB     
>>Lotsgatan 27 D                  Tel. [phone]              
>>216 42  Malmö                   Fax. [phone]              
>>Sweden                        Mobile [phone]
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>>
>
>Attachment Converted: "c:\internet\eudora\attach\MATCH2.DOC"
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18649 for ietf-pkix-bks; Fri, 25 Sep 1998 02:25:59 -0700 (PDT)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18645 for <[e-mail]>; Fri, 25 Sep 1998 02:25:52 -0700 (PDT)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id SAA24749; Fri, 25 Sep 1998 18:21:35 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA00363; Fri, 25 Sep 98 18:26:06 JST
Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id SAA08497; Fri, 25 Sep 1998 18:37:55 +0900 (JST)
Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA29300; Fri, 25 Sep 98 18:31:52 JST
Received: from zaku by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA19581; Fri, 25 Sep 1998 18:31:52 +0900
Message-Id: <[e-mail]>
Date: Fri, 25 Sep 1998 18:29:35 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: NEW Data type for certificate selection ?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
X-Mime-Autoconverted: from 8bit to quoted-printable by inetgw.melco.co.jp id SAA08497
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA18646
Sender: [e-mail]
Precedence: bulk

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
Mitsubishi Electric Corp.


Stefan Santesson wrote:

> 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                <[e-mail]>
> Accurata Systems$BgL(Berhet AB
> Lotsgatan 27 D                  Tel. [phone]
> 216 42  Malm$Bö (B                  Fax. [phone]
> Sweden                        Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22412 for ietf-pkix-bks; Thu, 24 Sep 1998 08:55:58 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22408 for <[e-mail]>; Thu, 24 Sep 1998 08:55:56 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA24293 for <[e-mail]>; Thu, 24 Sep 1998 12:02:10 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA24288 for <[e-mail]>; Thu, 24 Sep 1998 12:02:09 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA15598 for <[e-mail]>; Thu, 24 Sep 1998 12:01:26 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 24 Sep 1998 12:02:06 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Thu, 24 Sep 1998 12:02:06 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 24 Sep 1998 12:02:05 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDE7B3.26345CD0"
Sender: [e-mail]
Precedence: bulk

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

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:[e-mail]]
>Sent: 	Thursday, September 24, 1998 8:41 AM
>To: 	[e-mail]; [e-mail]; [e-mail];
>[e-mail]
>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                <[e-mail]>
>Accurata Systems=E4kerhet AB    =20
>Lotsgatan 27 D                  Tel. [phone]             =20
>216 42  Malm=F6                   Fax. [phone]             =20
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>

------ =_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/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////1IA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAWAAUA//////////8DAAAAAAkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAIZMlDsA6rwB
AwAAAIADAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAYgAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf////8EAAAA/////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAdTQAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv
AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEBAQAAAAIA
AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAACGTJQ7AOq8AYZMlDsA6rwBAAAAANQNNBRABNQNAQAA
AP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAP7/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////8BAP7/
AwoAAP////8ACQIAAAAAAMAAAAAAAABGHAAAAE1pY3Jvc29mdCBXb3JkIDYuMCBEb2N1bWVudAAK
AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYAAAAAADsAAwD+/wkABgAAAAAAAAAAAAAA
AQAAAAEAAAAAAP7/AAADCgAAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA
ALACAAAOAAAABwAAAJgAAAACAAAA3AAAAAQAAAAAAQAACAAAACQBAAAMAAAASAEAAAsAAABsAQAA
DQAAAJABAAAPAAAAtAEAABAAAADYAQAACgAAAPwBAAASAAAAIAIAAA4AAABEAgAACQAAAGgCAAAT
AAAAjAIAAP//////////////////////////////////////////HgAAACgAAABDOlxNU09GRklD
RVxXSU5XT1JEXFRFTVBMQVRFXE5PUk1BTC5ET1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAFAAA
ADEyLjcJTWF0Y2hpbmcgcnVsZXMAAAAAAAAAAAAeAAAADgAAAFN1ZSBBLiBNaWtsb3MAAAAAAAAA
AAAAAAAAAAAeAAAADgAAAFN1ZSBBLiBNaWtsb3MAAAAAAAAAAAAAAAAAAABAAAAAhn3TndylZQA9
wAkEAAAAAGUAAAAAAAAAAAAAAAADAAAHMwAAHU0AAAAAAAAAAAAAAAAAAAAAAAAHMAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAKAMAAABEAAAoAwAAKEcAAAAAAAAoRwAAAAAA
AChHAAAAAAAAKEcAAAAAAAAoRwAAFAAAAKJHAAA8AAAAokcAAAAAAADeRwAAAAAAAN5HAAAAAAAA
3kcAAAAAAADeRwAAFgAAAPRHAAAiAAAAokcAAAAAAAAjTAAAZQAAABZIAAAAAAAAFkgAAAAAAAAW
SAAAAAAAABZIAAAAAAAAFkgAAAAAAAAWSAAAAAAAABZIAAAAAAAAFkgAAAAAAAA4SAAAAgAAADpI
AAAAAAAAOkgAAAAAAAA6SAAAIwAAAF1IAADUAQAAMUoAANQBAAAFTAAAHgAAAIhMAABUAAAA3EwA
AEEAAAAjTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoRwAAAAAAABZIAAAAAAAAAAAaAB0AAwAFABZI
AAAAAAAAFkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkgAAAAAAAAWSAAAAAAAACNMAAAAAAAAFkgA
AAAAAAAoRwAAAAAAAChHAAAAAAAAFkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkgAAAAAAAAWSAAA
AAAAABZIAAAAAAAAFkgAAAAAAAAWSAAAAAAAAChHAAAAAAAAFkgAAAAAAAAoRwAAAAAAABZIAAAA
AAAAOEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPEcAACYAAABiRwAAQAAAAChHAAAAAAAAKEcAAAAA
AAAoRwAAAAAAAChHAAAAAAAAFkgAAAAAAAA4SAAAAAAAABZIAAAiAAAAFkgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEVYQ0VSUFRTIEZST00gVEhFIDE5OTcgWC41MDAgU2VyaWVz
IG9mIFJlY29tbWVuZGF0aW9ucyBmb3IgSW5mb3JtYXRpb25hbCBQdXJwb3NlcyBPbmx5Lg0NMTIu
NwlNYXRjaGluZyBydWxlcw1UaGlzIERpcmVjdG9yeSBTcGVjaWZpY2F0aW9uIGRlZmluZXMgbWF0
Y2hpbmcgcnVsZXMgZm9yIHVzZSB3aXRoIGF0dHJpYnV0ZXMgb2YgdHlwZSBDZXJ0aWZpY2F0ZSwg
Q2VydGlmaWNhdGVQYWlyLCBDZXJ0aWZpY2F0ZUxpc3QsIGFuZCBTdXBwb3J0ZWRBbGdvcml0aG0s
IHJlc3BlY3RpdmVseS4NMTIuNy4xCUNlcnRpZmljYXRlIGV4YWN0IG1hdGNoDVRoZSBjZXJ0aWZp
Y2F0ZSBleGFjdCBtYXRjaCBydWxlIGNvbXBhcmVzIGZvciBlcXVhbGl0eSBhIHByZXNlbnRlZCB2
YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1ZSBvZiB0eXBlIENlcnRpZmljYXRlLiBJdCB1bmlx
dWVseSBzZWxlY3RzIGEgc2luZ2xlIGNlcnRpZmljYXRlLg1jZXJ0aWZpY2F0ZUV4YWN0TWF0Y2gg
TUFUQ0hJTkctUlVMRSA6Oj0gewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZUV4YWN0QXNzZXJ0aW9uCwlJ
RAkJCWlkLW1yLWNlcnRpZmljYXRlRXhhY3RNYXRjaCB9DUNlcnRpZmljYXRlRXhhY3RBc3NlcnRp
b24gOjo9IFNFUVVFTkNFIHsLCXNlcmlhbE51bWJlcgkJQ2VydGlmaWNhdGVTZXJpYWxOdW1iZXIs
Cwlpc3N1ZXIJCQlOYW1lIH0NVGhpcyBtYXRjaGluZyBydWxlIHJldHVybnMgVFJVRSBpZiB0aGUg
Y29tcG9uZW50cyBpbiB0aGUgYXR0cmlidXRlIHZhbHVlIG1hdGNoIHRob3NlIGluIHRoZSBwcmVz
ZW50ZWQgdmFsdWUuDTEyLjcuMglDZXJ0aWZpY2F0ZSBtYXRjaA1UaGUgY2VydGlmaWNhdGUgbWF0
Y2ggcnVsZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1
ZSBvZiB0eXBlIENlcnRpZmljYXRlLiBJdCBzZWxlY3RzIG9uZSBvciBtb3JlIGNlcnRpZmljYXRl
cyBvbiB0aGUgYmFzaXMgb2YgdmFyaW91cyBjaGFyYWN0ZXJpc3RpY3MuDWNlcnRpZmljYXRlTWF0
Y2ggTUFUQ0hJTkctUlVMRSA6Oj0gewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZUFzc2VydGlvbgsJSUQJ
CQlpZC1tci1jZXJ0aWZpY2F0ZU1hdGNoIH0NQ2VydGlmaWNhdGVBc3NlcnRpb24gOjo9IFNFUVVF
TkNFIHsLCXNlcmlhbE51bWJlcgkJWzBdIENlcnRpZmljYXRlU2VyaWFsTnVtYmVyCQlPUFRJT05B
TCwLCWlzc3VlcgkJCQlbMV0gTmFtZSAJCQlPUFRJT05BTCwLCXN1YmplY3RLZXlJZGVudGlmaWVy
CVsyXSBTdWJqZWN0S2V5SWRlbnRpZmllcgkJT1BUSU9OQUwsCwlhdXRob3JpdHlLZXlJZGVudGlm
aWVyCVszXSBBdXRob3JpdHlLZXlJZGVudGlmaWVyIAkJT1BUSU9OQUwsCwljZXJ0aWZpY2F0ZVZh
bGlkCQlbNF0gVVRDVGltZQkJCU9QVElPTkFMLAsJcHJpdmF0ZUtleVZhbGlkCQlbNV0gR2VuZXJh
bGl6ZWRUaW1lCQlPUFRJT05BTCwLCXN1YmplY3RQdWJsaWNLZXlBbGdJRAlbNl0gT0JKRUNUIElE
RU5USUZJRVIJCU9QVElPTkFMLAsJa2V5VXNhZ2UJCQlbN10gS2V5VXNhZ2UJCQlPUFRJT05BTCwL
CXN1YmplY3RBbHROYW1lCQlbOF0gQWx0TmFtZVR5cGUJCU9QVElPTkFMLAsJcG9saWN5CQkJCVs5
XSBDZXJ0UG9saWN5U2V0CQlPUFRJT05BTCwLCXBhdGhUb05hbWUJCVsxMF0gTmFtZQkJCU9QVElP
TkFMIH0NQWx0TmFtZVR5cGUgOjo9IENIT0lDRSB7IAsJYnVpbHRpbk5hbWVGb3JtCUVOVU1FUkFU
RUQgewsJCQkJCXJmYzgyMk5hbWUJCSgxKSwLCQkJCQlkTlNOYW1lCQkoMiksCwkJCQkJeDQwMEFk
ZHJlc3MJCSgzKSwLCQkJCQlkaXJlY3RvcnlOYW1lCSg0KSwLCQkJCQllZGlQYXJ0eU5hbWUJCSg1
KSwLCQkJCQl1bmlmb3JtUmVzb3VyY2VJZGVudGlmaWVyICg2KSwLCQkJCQlpUEFkZHJlc3MJCSg3
KSwLCQkJCQlyZWdpc3RlcmVkSWQJCSg4KSB9LAsJb3RoZXJOYW1lRm9ybQlPQkpFQ1QgSURFTlRJ
RklFUiB9DVRoaXMgbWF0Y2hpbmcgcnVsZSByZXR1cm5zIFRSVUUgaWYgYWxsIG9mIHRoZSBjb21w
b25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZSBtYXRjaCB0aGUg
Y29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBhdHRyaWJ1dGUgdmFsdWUsIGFzIGZvbGxv
d3M6DWEpCXNlcmlhbE51bWJlciBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVu
dCBpbiB0aGUgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50ZWQgdmFs
dWU7DWIpCWlzc3VlciBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVudCBpbiB0
aGUgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50ZWQgdmFsdWU7DWMp
CXN1YmplY3RLZXlJZGVudGlmaWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVlIG9mIHRoaXMgY29tcG9u
ZW50IGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVz
ZW50ZWQgdmFsdWU7IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZh
bHVlIGNvbnRhaW5zIG5vIHN1YmplY3Qga2V5IGlkZW50aWZpZXIgZXh0ZW5zaW9uOw1kKQlhdXRo
b3JpdHlLZXlJZGVudGlmaWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVlIG9mIHRoaXMgY29tcG9uZW50
IGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50
ZWQgdmFsdWU7IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVl
IGNvbnRhaW5zIG5vIGF1dGhvcml0eSBrZXkgaWRlbnRpZmllciBleHRlbnNpb24gb3IgaWYgbm90
IGFsbCBjb21wb25lbnRzIGluIHRoZSBwcmVzZW50ZWQgdmFsdWUgYXJlIHByZXNlbnQgaW4gdGhl
IHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWU7DWUpCWNlcnRpZmljYXRlVmFsaWQgbWF0Y2hlcyBpZiB0
aGUgcHJlc2VudGVkIHZhbHVlIGZhbGxzIHdpdGhpbiB0aGUgdmFsaWRpdHkgcGVyaW9kIG9mIHRo
ZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOw1mKQlwcml2YXRlS2V5VmFsaWQgbWF0Y2hlcyBpZiB0
aGUgcHJlc2VudGVkIHZhbHVlIGZhbGxzIHdpdGhpbiB0aGUgcGVyaW9kIGluZGljYXRlZCBieSB0
aGUgcHJpdmF0ZSBrZXkgdXNhZ2UgcGVyaW9kIGV4dGVuc2lvbiBvZiB0aGUgc3RvcmVkIGF0dHJp
YnV0ZSB2YWx1ZSBvciBpZiB0aGVyZSBpcyBubyBwcml2YXRlIGtleSB1c2FnZSBwZXJpb2QgZXh0
ZW5zaW9uIGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOw1nKQlzdWJqZWN0UHVibGljS2V5
QWxnSUQgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUgYWxnb3JpdGhtIGNvbXBvbmVudCBv
ZiB0aGUgYWxnb3JpdGhtSWRlbnRpZmllciBvZiB0aGUgc3ViamVjdFB1YmxpY0tleUluZm9ybWF0
aW9uIGNvbXBvbmVudCBvZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNaCkJa2V5VXNhZ2Ug
bWF0Y2hlcyBpZiBhbGwgb2YgdGhlIGJpdHMgc2V0IGluIHRoZSBwcmVzZW50ZWQgdmFsdWUgYXJl
IGFsc28gc2V0IGluIHRoZSBrZXkgdXNhZ2UgZXh0ZW5zaW9uIGluIHRoZSBzdG9yZWQgYXR0cmli
dXRlIHZhbHVlLCBvciBpZiB0aGVyZSBpcyBubyBrZXkgdXNhZ2UgZXh0ZW5zaW9uIGluIHRoZSBz
dG9yZWQgYXR0cmlidXRlIHZhbHVlOw1pKQlzdWJqZWN0QWx0TmFtZSBtYXRjaGVzIGlmIHRoZSBz
dG9yZWQgYXR0cmlidXRlIHZhbHVlIGNvbnRhaW5zIHRoZSBzdWJqZWN0IGFsdGVybmF0aXZlIG5h
bWUgZXh0ZW5zaW9uIHdpdGggYW4gQWx0TmFtZXMgY29tcG9uZW50IG9mIHRoZSBzYW1lIG5hbWUg
dHlwZSBhcyBpbmRpY2F0ZWQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZTsNaikJcG9saWN5IG1hdGNo
ZXMgaWYgYWxsIG9mIHRoZSBwb2xpY3kgZWxlbWVudHMgaWRlbnRpZmllZCBpbiBvbmUgb2YgdGhl
IHByZXNlbnRlZCB2YWx1ZXMgYXJlIGNvbnRhaW5lZCBpbiB0aGUgc2V0IG9mIHBvbGljeUVsZW1l
bnRJZHMgaW4gYW55IG9mIHRoZSBwb2xpY3lJbmZvcm1hdGlvbiB2YWx1ZXMgaW4gdGhlIGNlcnRp
ZmljYXRlIHBvbGljaWVzIGV4dGVuc2lvbiBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsg
IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZXJlIGlzIG5vIGNlcnRpZmljYXRlIHBvbGljaWVzIGV4
dGVuc2lvbiBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNaykJcGF0aFRvTmFtZSBtYXRj
aGVzIHVubGVzcyB0aGUgY2VydGlmaWNhdGUgaGFzIGEgbmFtZSBjb25zdHJhaW50cyBleHRlbnNp
b24gd2hpY2ggaW5oaWJpdHMgdGhlIGNvbnN0cnVjdGlvbiBvZiBhIGNlcnRpZmljYXRpb24gcGF0
aCB0byB0aGUgcHJlc2VudGVkIG5hbWUgdmFsdWUuDTEyLjcuMwlDZXJ0aWZpY2F0ZSBwYWlyIGV4
YWN0IG1hdGNoDVRoZSBjZXJ0aWZpY2F0ZSBwYWlyIGV4YWN0IG1hdGNoIHJ1bGUgY29tcGFyZXMg
Zm9yIGVxdWFsaXR5IGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmlidXRlIHZhbHVlIG9m
IHR5cGUgQ2VydGlmaWNhdGVQYWlyLiBJdCB1bmlxdWVseSBzZWxlY3RzIGEgc2luZ2xlIGNyb3Nz
LWNlcnRpZmljYXRlIHBhaXIuDWNlcnRpZmljYXRlUGFpckV4YWN0TWF0Y2ggTUFUQ0hJTkctUlVM
RQk6Oj0JewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZVBhaXJFeGFjdEFzc2VydGlvbgsJSUQJCQlpZC1t
ci1jZXJ0aWZpY2F0ZVBhaXJFeGFjdE1hdGNoIH0NQ2VydGlmaWNhdGVQYWlyRXhhY3RBc3NlcnRp
b24gOjo9IFNFUVVFTkNFIHsNCWZvcndhcmRBc3NlcnRpb24gCVswXSBDZXJ0aWZpY2F0ZUV4YWN0
QXNzZXJ0aW9uIE9QVElPTkFMLA0JcmV2ZXJzZUFzc2VydGlvbiAJWzFdIENlcnRpZmljYXRlRXhh
Y3RBc3NlcnRpb24gT1BUSU9OQUwgfQ0JKCBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIGZvcndhcmRB
c3NlcnRpb24gUFJFU0VOVH0gfA0JICBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIHJldmVyc2VBc3Nl
cnRpb24gUFJFU0VOVH0gKQ1UaGlzIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlmIHRoZSBj
b21wb25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIGZvcndhcmRBc3NlcnRpb24gYW5kIHJl
dmVyc2VBc3NlcnRpb24gY29tcG9uZW50cyBvZiB0aGUgcHJlc2VudGVkIHZhbHVlIG1hdGNoIHRo
ZSBjb3JyZXNwb25kaW5nIGNvbXBvbmVudHMgb2YgdGhlIGZvcndhcmQgYW5kIHJldmVyc2UgY29t
cG9uZW50cywgcmVzcGVjdGl2ZWx5LCBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZS4NMTIu
Ny40CUNlcnRpZmljYXRlIHBhaXIgbWF0Y2gNVGhlIGNlcnRpZmljYXRlIHBhaXIgbWF0Y2ggcnVs
ZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1ZSBvZiB0
eXBlIENlcnRpZmljYXRlUGFpci4gSXQgc2VsZWN0cyBvbmUgb3IgbW9yZSBjcm9zcy1jZXJ0aWZp
Y2F0ZSBwYWlycyBvbiB0aGUgYmFzaXMgb2YgdmFyaW91cyBjaGFyYWN0ZXJpc3RpY3Mgb2YgZWl0
aGVyIHRoZSBmb3J3YXJkIG9yIHJldmVyc2UgY2VydGlmaWNhdGUgb2YgdGhlIHBhaXIuDWNlcnRp
ZmljYXRlUGFpck1hdGNoIE1BVENISU5HLVJVTEUgOjo9CXsLCVNZTlRBWAkJQ2VydGlmaWNhdGVQ
YWlyQXNzZXJ0aW9uCwlJRAkJCWlkLW1yLWNlcnRpZmljYXRlUGFpck1hdGNoIH0NQ2VydGlmaWNh
dGVQYWlyQXNzZXJ0aW9uIDo6PSBTRVFVRU5DRSB7DQlmb3J3YXJkQXNzZXJ0aW9uIAlbMF0gQ2Vy
dGlmaWNhdGVBc3NlcnRpb24gT1BUSU9OQUwsDQlyZXZlcnNlQXNzZXJ0aW9uIAlbMV0gQ2VydGlm
aWNhdGVBc3NlcnRpb24gT1BUSU9OQUwgfQ0JKCBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIGZvcndh
cmRBc3NlcnRpb24gUFJFU0VOVH0gfA0JICBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIHJldmVyc2VB
c3NlcnRpb24gUFJFU0VOVH0gKQ1UaGlzIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlmIGFs
bCBvZiB0aGUgY29tcG9uZW50cyB0aGF0IGFyZSBwcmVzZW50IGluIHRoZSBmb3J3YXJkQXNzZXJ0
aW9uIGFuZCByZXZlcnNlQXNzZXJ0aW9uIGNvbXBvbmVudHMgb2YgdGhlIHByZXNlbnRlZCB2YWx1
ZSBtYXRjaCB0aGUgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBmb3J3YXJkIGFuZCBy
ZXZlcnNlIGNvbXBvbmVudHMsIHJlc3BlY3RpdmVseSwgaW4gdGhlIHN0b3JlZCBhdHRyaWJ1dGUg
dmFsdWUsIHVzaW5nIHRoZSBydWxlcyBnaXZlbiBpbiAxMi43LjIuDTEyLjcuNQlDZXJ0aWZpY2F0
ZSBsaXN0IGV4YWN0IG1hdGNoDVRoZSBjZXJ0aWZpY2F0ZSBsaXN0IGV4YWN0IG1hdGNoIHJ1bGUg
Y29tcGFyZXMgZm9yIGVxdWFsaXR5IGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmlidXRl
IHZhbHVlIG9mIHR5cGUgQ2VydGlmaWNhdGVMaXN0LiBJdCB1bmlxdWVseSBzZWxlY3RzIGEgc2lu
Z2xlIENSTC4NY2VydGlmaWNhdGVMaXN0RXhhY3RNYXRjaCBNQVRDSElORy1SVUxFCTo6PQl7CwlT
WU5UQVgJCUNlcnRpZmljYXRlTGlzdEV4YWN0QXNzZXJ0aW9uCwlJRAkJCWlkLW1yLWNlcnRpZmlj
YXRlTGlzdEV4YWN0TWF0Y2ggfQ1DZXJ0aWZpY2F0ZUxpc3RFeGFjdEFzc2VydGlvbiA6Oj0gU0VR
VUVOQ0Ugew0JaXNzdWVyCQkJTmFtZSwNCXRoaXNVcGRhdGUJCVVUQ1RpbWUsDQlkaXN0cmlidXRp
b25Qb2ludAlEaXN0cmlidXRpb25Qb2ludE5hbWUgT1BUSU9OQUwgfQ1UaGUgcnVsZSByZXR1cm5z
IFRSVUUgaWYgdGhlIGNvbXBvbmVudHMgaW4gdGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUgbWF0
Y2ggdGhvc2UgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZS4gSWYgdGhlIGRpc3RyaWJ1dGlvblBvaW50
IGNvbXBvbmVudCBpcyBwcmVzZW50IHRoZW4gaXQgbXVzdCBtYXRjaCBpbiBhdCBsZWFzdCBvbmUg
bmFtZSBmb3JtLg0xMi43LjYJQ2VydGlmaWNhdGUgbGlzdCBtYXRjaA1UaGUgY2VydGlmaWNhdGUg
bGlzdCBtYXRjaCBydWxlIGNvbXBhcmVzIGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmli
dXRlIHZhbHVlIG9mIHR5cGUgQ2VydGlmaWNhdGVMaXN0LiBJdCBzZWxlY3RzIG9uZSBvciBtb3Jl
IENSTHMgb24gdGhlIGJhc2lzIG9mIHZhcmlvdXMgY2hhcmFjdGVyaXN0aWNzLg1jZXJ0aWZpY2F0
ZUxpc3RNYXRjaCBNQVRDSElORy1SVUxFIDo6PSB7DQlTWU5UQVgJQ2VydGlmaWNhdGVMaXN0QXNz
ZXJ0aW9uCwlJRAkJaWQtbXItY2VydGlmaWNhdGVMaXN0TWF0Y2ggfQ1DZXJ0aWZpY2F0ZUxpc3RB
c3NlcnRpb24gOjo9IFNFUVVFTkNFIHsNCWlzc3VlcgkJCU5hbWUJT1BUSU9OQUwsDQltaW5DUkxO
dW1iZXIJCVswXQlDUkxOdW1iZXIJT1BUSU9OQUwsCwltYXhDUkxOdW1iZXIJCVsxXQlDUkxOdW1i
ZXIJT1BUSU9OQUwsCwlyZWFzb25GbGFncwkJUmVhc29uRmxhZ3MJT1BUSU9OQUwsCwlkYXRlQW5k
VGltZQkJVVRDVGltZQlPUFRJT05BTCwNCWRpc3RyaWJ1dGlvblBvaW50CQlbMl0JRGlzdHJpYnV0
aW9uUG9pbnROYW1lIE9QVElPTkFMIH0NVGhlIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlm
IGFsbCBvZiB0aGUgY29tcG9uZW50cyB0aGF0IGFyZSBwcmVzZW50IGluIHRoZSBwcmVzZW50ZWQg
dmFsdWUgbWF0Y2ggdGhlIGNvcnJlc3BvbmRpbmcgY29tcG9uZW50cyBvZiB0aGUgc3RvcmVkIGF0
dHJpYnV0ZSB2YWx1ZSwgYXMgZm9sbG93czoNYSkJaXNzdWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVl
IG9mIHRoaXMgY29tcG9uZW50IGluIHRoZSBhdHRyaWJ1dGUgdmFsdWUgZXF1YWxzIHRoYXQgaW4g
dGhlIHByZXNlbnRlZCB2YWx1ZTsNYikJbWluQ1JMTnVtYmVyIG1hdGNoZXMgaWYgaXRzIHZhbHVl
IGlzIGxlc3MgdGhhbiBvciBlcXVhbCB0byB0aGUgdmFsdWUgaW4gdGhlIENSTCBudW1iZXIgZXh0
ZW5zaW9uIG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOyB0aGVyZSBpcyBubyBtYXRjaCBp
ZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBubyBDUkwgbnVtYmVyIGV4dGVu
c2lvbjsNYykJbWF4Q1JMTnVtYmVyIG1hdGNoZXMgaWYgaXRzIHZhbHVlIGlzIGdyZWF0ZXIgdGhh
biBvciBlcXVhbCB0byB0aGUgdmFsdWUgaW4gdGhlIENSTCBudW1iZXIgZXh0ZW5zaW9uIG9mIHRo
ZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOyB0aGVyZSBpcyBubyBtYXRjaCBpZiB0aGUgc3RvcmVk
IGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBubyBDUkwgbnVtYmVyIGV4dGVuc2lvbjsNZCkJcmVh
c29uRmxhZ3MgbWF0Y2hlcyBpZiBhbnkgb2YgdGhlIGJpdHMgdGhhdCBhcmUgYXJlIHNldCBpbiB0
aGUgcHJlc2VudGVkIHZhbHVlIGFyZSBhbHNvIHNldCBpbiB0aGUgb25seVNvbWVSZWFzb25zIGNv
bXBvbmVudHMgb2YgdGhlIGlzc3VpbmcgZGlzdHJpYnV0aW9uIHBvaW50IGV4dGVuc2lvbiBvZiB0
aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsgdGhlcmUgaXMgbm8gbWF0Y2ggaWYgdGhlIHN0b3Jl
ZCBhdHRyaWJ1dGUgdmFsdWUgY29udGFpbnMgbm8gaXNzdWluZyBkaXN0cmlidXRpb24gcG9pbnQg
ZXh0ZW5zaW9uOw1lKQlkYXRlQW5kVGltZSBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBpcyBlcXVhbCB0
byBvciBsYXRlciB0aGFuIHRoZSB2YWx1ZSBpbiB0aGUgdGhpc1VwZGF0ZSBjb21wb25lbnQgb2Yg
dGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUgYW5kIGlzIGVhcmxpZXIgdGhhbiB0aGUgdmFsdWUg
aW4gdGhlIG5leHRVcGRhdGUgY29tcG9uZW50IG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVl
OyB0aGVyZSBpcyBubyBtYXRjaCBpZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlu
cyBubyBuZXh0VXBkYXRlIGNvbXBvbmVudDsNZikJZGlzdHJpYnV0aW9uUG9pbnQgbWF0Y2hlcyBp
ZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBhbiBpc3N1aW5nIGRpc3RyaWJ1
dGlvbiBwb2ludCBleHRlbnNpb24gYW5kIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVudCBpbiB0
aGUgcHJlc2VudGVkIHZhbHVlIGVxdWFscyB0aGUgY29ycmVzcG9uZGluZyB2YWx1ZSwgaW4gYXQg
bGVhc3Qgb25lIG5hbWUgZm9ybSwgaW4gdGhhdCBleHRlbnNpb24uDTEyLjcuNwlBbGdvcml0aG0g
aWRlbnRpZmllciBtYXRjaA1UaGUgYWxnb3JpdGhtIGlkZW50aWZpZXIgbWF0Y2ggcnVsZSBjb21w
YXJlcyBmb3IgZXF1YWxpdHkgYSBwcmVzZW50ZWQgdmFsdWUgd2l0aCBhbiBhdHRyaWJ1dGUgdmFs
dWUgb2YgdHlwZSBTdXBwb3J0ZWRBbGdvcml0aG0uIA1hbGdvcml0aG1JZGVudGlmaWVyTWF0Y2gg
TUFUQ0hJTkctUlVMRQk6Oj0gICB7CwlTWU5UQVgJCUFsZ29yaXRobUlkZW50aWZpZXILCUlECQkJ
aWQtbXItYWxnb3JpdGhtSWRlbnRpZmllck1hdGNoIH0NVGhlIHJ1bGUgcmV0dXJucyBUUlVFIGlm
IHRoZSBwcmVzZW50ZWQgdmFsdWUgaXMgZXF1YWwgdG8gdGhlIGFsZ29yaXRobUlkZW50aWZpZXIg
Y29tcG9uZW50IG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlLg0xMy4zCUF0dHJpYnV0ZSBD
ZXJ0aWZpY2F0ZSBNYXRjaGluZyBSdWxlDVRoZSBhdHRyaWJ1dGUgY2VydGlmaWNhdGUgbWF0Y2hp
bmcgcnVsZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1
ZSBvZiB0eXBlIEF0dHJpYnV0ZUNlcnRpZmljYXRlLiBUaGlzIG1hdGNoaW5nIHJ1bGVzIGFsbG93
cyBtb3JlIGNvbXBsZXggbWF0Y2hpbmcgdGhhbiB0aGUgY2VydGlmaWNhdGVFeGFjdE1hdGNoLg1h
dHRyaWJ1dGVDZXJ0aWZpY2F0ZU1hdGNoICBNQVRDSElORy1SVUxFICA6Oj0gIHsLCVNZTlRBWAlB
dHRyaWJ1dGVDZXJ0aWZpY2F0ZUFzc2VydGlvbgsJSUQJCWlkLW1yLWF0dHJpYnV0ZUNlcnRpZmlj
YXRlTWF0Y2ggIH0NQXR0cmlidXRlQ2VydGlmaWNhdGVBc3NlcnRpb24gIDo6PSAgU0VRVUVOQ0Ug
IHsLCXN1YmplY3QJWzBdCUNIT0lDRSB7CwkJYmFzZUNlcnRpZmljYXRlSUQJWzBdICBJc3N1ZXJT
ZXJpYWwsCwkJc3ViamVjdE5hbWUJCVsxXSAgR2VuZXJhbE5hbWVzfSBPUFRJT05BTCwLCWlzc3Vl
cgkJWzFdCUdlbmVyYWxOYW1lcyBPUFRJT05BTCwLCWF0dENlcnRWYWxpZAlbMl0JR2VuZXJhbGl6
ZWRUaW1lIE9QVElPTkFMLA0JYXR0VHlwZQlbM10JU0VUIE9GIEF0dHJpYnV0ZVR5cGUgT1BUSU9O
QUx9DZUJQXQgbGVhc3Qgb25lIGNvbXBvbmVudCBvZiB0aGUgc2VxdWVuY2UgbXVzdCBiZSBwcmVz
ZW50DVRoZSBtYXRjaGluZyBydWxlIHJldHVybnMgVFJVRSBpZiBhbGwgb2YgdGhlIGNvbXBvbmVu
dHMgdGhhdCBhcmUgcHJlc2VudCBpbiB0aGUgcHJlc2VudGVkIHZhbHVlIG1hdGNoIHRoZSBjb3Jy
ZXNwb25kaW5nIGNvbXBvbmVudHMgb2YgdGhlIGF0dHJpYnV0ZSB2YWx1ZSwgYXMgZm9sbG93czoN
YSkJYmFzZUNlcnRpZmljYXRlSUQgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUgSXNzdWVy
U2VyaWFsIGNvbXBvbmVudCBvZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNYikJc3ViamVj
dE5hbWUgbWF0Y2hlcyBpZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyB0aGUg
bmFtZSBleHRlbnNpb24gd2l0aCB0aGUgc2FtZSBuYW1lIHR5cGUgYXMgaW5kaWNhdGVkIGluIHRo
ZSBwcmVzZW50ZWQgdmFsdWU7DWMpCWlzc3VlciBtYXRjaGVzIGlmIHRoZSBzdG9yZWQgYXR0cmli
dXRlIHZhbHVlIGNvbnRhaW5zIHRoZSBuYW1lIGNvbXBvbmVudCBvZiB0aGUgc2FtZSBuYW1lIHR5
cGUgYXMgaW5kaWNhdGVkIGluIHRoZSBwcmVzZW50ZWQgdmFsdWU7DWQpCWF0dENlcnRWYWxpZGQg
bWF0Y2hlcyBpZiBpdCBmYWxscyB3aXRoaW4gdGhlIHNwZWNpZmllZCB2YWxpZGl0eSBwZXJpb2Qg
b2YgdGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUuDWUpIAlmb3IgZWFjaCBhdHRUeXBlIGluIHRo
ZSBwcmVzZW50ZWQgdmFsdWUsIHRoZXJlIGlzIGFuIGF0dHJpYnV0ZSBvZiB0aGF0IHR5cGUgcHJl
c2VudCBpbiB0aGUgYXR0cmlidXRlcyBjb21wb25lbnQgb2YgdGhlIHN0b3JlZCB2YWx1ZS4NMTgu
Mi40CVJlYWRlciBhbmQgS2V5IElkZW50aWZpZXIgTWF0Y2hpbmcgUnVsZQ1BIG1hdGNoaW5nIHJ1
bGUgZm9yIGEgbGlzdCBvZiBhdXRob3JpemVkIHJlYWRlcnMgYW5kIHRoZWlyIGFzc29jaWF0ZWQg
a2V5cyBpcyBhcyBmb2xsb3dzOg1yZWFkZXJBbmRLZXlJRE1hdGNoIE1BVENISU5HLVJVTEUgIDo6
PSAgewsJU1lOVEFYCVJlYWRlckFuZEtleUlEQXNzZXJ0aW9uCwlJRAkJaWQtbXItcmVhZGVyQW5k
S2V5SURNYXRjaCAgfQ1SZWFkZXJBbmRLZXlJREFzc2VydGlvbiAgOjo9ICBTRVFVRU5DRSB7DQsJ
a2V5SWRlbnRpZmllcglLZXlJZGVudGlmaWVyLAsJYXV0aFJlYWRlcnMJQXV0aFJlYWRlcnMgT1BU
SU9OQUwgIH0NVGhlIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBhIFRSVUUgaWYgYWxsIG9mIHRoZSBj
b21wb25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZSBtYXRjaCB0
aGUgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBhdHRyaWJ1dGUgdmFsdWUsIGFzIGZv
bGxvd3M6DWEpCWtleUlkZW50aWZpZXIgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUga2V5
SWRlbnRpZmllciBjb21wb25lbnQgb2YgdGhlIFByb3RlY3RlZEtleSBpbiB0aGUgc3RvcmVkIGF0
dHJpYnV0ZSB2YWx1ZTsNYikJaWYgcHJlc2VudCB0aGUgYXV0aFJlYWRlcnMgbWF0Y2hlcyBpZiBp
dCBpcyBlcXVhbCB0byBvbmUgb2YgdGhlIG5hbWVzIGluIHRoZSBhdXRoUmVhZGVycyBjb21wb25l
bnQgb2YgdGhlIFByb3RlY3RlZEtleSBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZS4NDQ0N
DQ0NDQ0NDQ0NUmVmLg1uby4HTWF0Y2hpbmcgUnVsZQdEB0FDUCAxMzMHTm90ZXMNKG15IHJlY29t
bWVuZGVkIG9yZGVyIGZvciBzdXBwb3J0ICNuKQcHMS4HYWxnb3JpdGhtSWRlbnRpZmllck1hdGNo
B28HbQcjMQcHMi4HYXR0cmlidXRlQ2VydGlmaWNhdGVNYXRjaAdvB20HIzYHBzMuB2F0dHJpYnV0
ZUludGVncml0eU1hdGNoB28HbwcHBzQuB2NlcnRpZmljYXRlRXhhY3RNYXRjaAdvB28HBwc1Lgdj
ZXJ0aWZpY2F0ZUxpc3RFeGFjdE1hdGNoB28HbQcjNQcHNi4HY2VydGlmaWNhdGVMaXN0TWF0Y2gH
bwdtByM0Bwc3LgdjZXJ0aWZpY2F0ZU1hdGNoB28HbQcjMgcHOC4HY2VydGlmaWNhdGVQYWlyRXhh
Y3RNYXRjaAdvB28HBwc5LgdjZXJ0aWZpY2F0ZVBhaXJNYXRjaAdvB20HIzMHBzEwLgdyZWFkZXJB
bmRLZXlJRE1hdGNoB28HbQdDb25kaXRpb25hbCBvbiBzdXBwb3J0IG9mIHRoZSBlbmNyeXB0ZWQg
dmFyaWFudCBvZiBhdHRyaWJ1dGVzIGFzIGRlc2NyaWJlZCBpbiBQYXJhIDQwOCBvZiBBQ1AgMTMz
DSM3BwcNDQ0NVGFibGUgZnJvbSBBQ1AgMTMzLCBBbm5leCBEIC0gVGFibGUgRC0xNS4NDVBsZWFz
ZSBub3RlIHRoYXQgaXQgaXNuknQgdmFsaWQgZm9yIGEgRFNBIHRvIGJlIGFibGUgdG8gbWF0Y2gg
YXNzZXJ0aW9ucywgdW5sZXNzIHRoZSBjbGllbnRzIGNhbiBhc3NlcnQgdGhlIG1hdGNoIGNyaXRl
cmlhLg3QzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA7AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAABAAAA
AAAAAAAQAAACAAAAAQAAAP7///8AAAAAAAAAAP//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////8FAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0
AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAP///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADgAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPtsvAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAhjMCGQDqvAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAGKYxQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDYuMAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAAgAAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQzxHgobEa4QAAAAAAAAAAAAAAAAAA
AAA7AAMA/v8JAP//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////AAMAAFkDAADBAwAAzAMAAM4DAADdAwAA3wMAAO4DAAD0
AwAABgQAABUEAAAWBAAAngQAAKkEAADUBAAA1QQAABQGAAAVBgAAhAYAAI8GAADdBgAA3gYAAC4L
AAA6CwAAoAsAAKYLAAAMDAAAIAwAAOsMAAABDQAAKA4AADgOAACbDgAAqg4AAIsPAACgDwAAvw8A
AMgPAADaDwAA7g8AAPUPAAAQEAAAPRAAAEUQAAALEQAAGREAAHgRAACAEQAAyREAAM8RAAA8EgAA
TBIAAFsSAABsEgAAHBMAACYTAABOFAAAXRQAAJMUAACUFAAAaxYAAHsWAACAFgAAkBYAAN0WAADk
FgAA6RYAAPAWAAApFwAAKhcAAKMXAACyFwAARBgAAEUYAAAFGgAAFRoAABoaAAAqGgAAdxoAAH4a
AACDGgAAihoAAOQaAADlGgAAdxsAAIYbAACpGwAAqhsAAB8dAAAwHQAAcx0AAHQdAADtHQAA/B0A
AGggAABpIAAAAP328Pb99v32/QD99v0A/QD99v0A/fb99v32/fb99v32/fb99v32/fb99v32/fb9
9v32/fb99v32/QD99v32/fb99v0A/fb9AP32/fb99v32/QD99v0A/fb9AP32/QAACl0DAGMSAEkB
AAEADFWBXQMAYxIASQEAAQAESQEAAV9pIAAAbCAAAHIgAADYIAAA5CAAAK0hAAC5IQAAhSIAAJAi
AADoIgAA9yIAALMjAAC+IwAA/yMAAAkkAABXJAAAYSQAAMckAADRJAAA4CQAAPEkAABcJgAAbiYA
AHAmAABxJgAAIScAADQnAABdJwAAhycAAAAoAAA6KAAATygAAFEoAAABKQAACCkAAAkpAAANKQAA
LikAAC8pAABPKQAAUCkAAFEpAABYKQAAXCkAAF0pAABeKQAAZykAAHEpAAB9KQAAgSkAAIIpAACO
KQAA4ykAAOQpAADlKQAAHSoAAB4qAADEKgAAxSoAAMgqAADZKgAA+CoAAAQrAAAxKwAAPCsAAL8r
AADFKwAARiwAAFMsAABzLAAAfSwAAKssAAC5LAAAwCwAAAstAAAWLQAAvi0AAJcuAABDLwAAUC8A
AG8vAAB8LwAAji8AAJovAADMLwAA1i8AANcvAAAKMAAAFTAAACcwAAAzMAAA/fb99v32/fb99v32
/fb99v32/fb99v0A/fb9AP0A9AD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A8ez9AP32/fb99v32/ef9
AP0A9AD0AOUA5wDnAPQA9ucA5wD0AAAAAANQFgAIVYFdAwBjEgAACFWBVoFJAQABAARVgVaBAAJV
gQAMVYFdAwBjEgBJAQABAARJAQABWjMwAABfMAAAsDAAAMgwAADUMAAA7TAAADkxAABSMQAAXjEA
AHIxAACaMQAAszEAAL0xAADRMQAA2TEAANoxAABcMgAABzMAAAD9+v36/fr9+v36/fr99/0AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAABVAWAFWBBEkBAAEAA1AWAAARAAMAAFgDAABZAwAAbQMAABYEAAA1BAAA1QQAAEYFAACoBQAA
FQYAAC4GAADeBgAAQAcAAGUJAACDCgAAKwsAAJ0LAAAJDAAA6AwAACUOAACYDgAAiA8AADoQAAAI
EQAAxhEAABkTAAC8EwAA4BMAAJQUAAARFQAAPhUAAHkVAAC1FQAA6xUAACEWAAAqFwAASBcAAEUY
AACzGAAA2xgAABEZAABIGQAAfhkAAP0AAsAhCAH7AAHAIQgB+wABwCEIAfkAAsAh8AD3AAHAIfAA
+QACwCHwAPMAA8Ah2ADzAAPAIdgA+QACwCHwAPcAAcAh8AD5AALAIfAA8wADwCHYAPMADMAh2ADz
AAvAIdgA8QACwCHwAO8AAsAh8ADvAALAIfAA7wADwCHwAO8ABMAh8ADvAALAIfAA7wADwCHwAO8A
A8Ah8ADvAAPAIfAA7wADwCHwAO8ABMAh8ADvAALAIfAA9wABwCHwAPkAAsAh8ADzAAPAIdgA8wAB
wCHYAO0AAcAh2ADtAAHAIdgA7QABwCHYAO0AAcAh2AD5AAPAIfAA9wABwCHwAPkAA8Ah8ADzAAPA
IdgA8wABwCHYAO0AAcAh2ADtAAHAIdgA7QABwCHYAAAAAAAAAAAAAREAAAEPAAABAAAAAxAAEAoA
AAABBAAAARMAAAECAAACAgAFACp+GQAAtBkAAOUaAAAJGwAAqhsAACccAABUHAAAZBwAAHocAACu
HAAAdB0AAJIdAABDHgAAbB4AAK8eAADXHgAA8B4AAIIfAAC7HwAAaSAAANUgAACqIQAAgiIAALAj
AADdJAAAziUAAPAlAABxJgAA5CYAAF4nAACHJwAAUSgAANAoAAC5KQAA5SkAAB4qAADFKgAALisA
ALwrAABDLAAArCwAADUtAABkLQAA/gABwCHYAPwAA8Ah8AD6AAHAIfAA/AACwCHwAPYAA8Ah2AD2
AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/AACwCHwAPoAAcAh8AD0AALAIfAA9gABwCHYAP4A
AsAh2AD2AAHAIdgA/gABwCHYAP4ABMAh2AD+AAHAIdgA/AACwCHwAPIAAsAh8ADyAAPAIfAA8gAD
wCHwAPIABMAh8ADyAATAIfAA8gADwCHwAPoAAcAh8AD8AALAIfAA9gADwCHYAPwAAsAh8ADwAAHA
IQgB/AACwCHwAO4AA8Ah2ADuAAbAIdgA/gABwCHYAOwAAcAh3QD8AALAIfAA8gACwCHwAPIAAsAh
8ADyAALAIfAA8gACwCHwAPIAAsAh8ADpAAHAISABAgkABQAAARQAAAEQAAABAgAAAQ8AAAESAAAD
EAAQCgAAAAEEAAABEwAAAREAKmQtAAC+LQAAKi4AAFMuAACXLgAAQC8AALovAABTMAAAVDAAAFUw
AABWMAAAVzAAAFgwAABZMAAAWjAAAFswAABcMAAAXTAAAF4wAABfMAAAZDAAAGgwAAB2MAAAeDAA
AIAwAACGMAAArDAAAK0wAACwMAAAyTAAAMswAADNMAAA0DAAANEwAADUMAAA7jAAAPAwAADyMAAA
9TAAAPYwAAD5MAAA/gABwCHwAPwAA8Ah3QD8AAHAId0A/AADwCHdAP4AAsAh8AD6AALAIfAA+gAC
wCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPoAAcAh8AD6AAHA
IfAA+gABwCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPQAAYoB3QD0AAGKAd0A9AABSw3dAPQAAUQB
3QD0AAKsAt0A9AAByxHdAPQAAcsR3QDgAAHLEd0A9AABigHdAPQAAUsN3QD0AAFEAd0A9AABrALd
APQAAcsR3QDgAAHLEd0A9AABigHdAPQAAUsN3QD0AAFEAd0A9AABrALdAPQAAcsR3QDgAAHLEd0A
9AABigHdAAAAAAATAAAYARkBuGwAuwoACgAKAAoACQAJAL4OAAUU+3b9mgu2DToR3CMABRQAEAAA
EQAAGAEAARUAAAEUAAABEwAo+TAAABExAAATMQAAFTEAABYxAAAXMQAAGjEAADAxAAAyMQAANDEA
ADUxAAA2MQAAOTEAAFMxAABVMQAAVzEAAFoxAABbMQAAXjEAAHMxAAB1MQAAdzEAAHoxAAB7MQAA
fjEAAI8xAACRMQAAkzEAAJYxAACXMQAAmjEAALQxAAC2MQAAuDEAALkxAAC6MQAAvTEAANIxAADU
MQAA1jEAANkxAADaMQAA+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A
+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6
AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYA
AcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gAB
Sw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGs
At0A+gAByxHdAOYAAcsR3QAAAAAAABMAABgBGQG4bAC7CgAKAAoACgAJAAkAvg4ABRT7dv2aC7YN
OhHcIwAFFAAQAAARAAAYASnaMQAA3jEAAPIxAAD0MQAA9jEAAFgyAABbMgAAXDIAAF0yAABeMgAA
XzIAAGAyAACKMgAAizIAAAczAAD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gACyxHdAPoA
AcsR3QDmAAHLEd0A5AABwCHwAOQAAcAh8ADkAAHAIfAA5AABwCHwAOQAAcAh8ADkAAHAIfAA5AAC
wCHwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAAEwAAGAEZAbhsALsKAAoACgAKAAkACQC+DgAFFPt2/ZoLtg06
EdwjAAUUABAAABEAABgBDg4AFwAIAAEASwAPAAAAAAAaAABA8f8CABoABk5vcm1hbAACAAAAAwBh
CQQALgABQAEAAgAuAAlIZWFkaW5nIDEAAAoAAQAIARXwABY8AAsAVYFdAgBjHABrHAAASgACQAEA
AgBKAA5IZWFkaW5nIDIsMixsMQAhAAIABQMHAQgBERoDE+b8FTkBDw4ABBoDpwQ0BsEHAAAAAAAL
AFWBXQQAYQkIYxYAACgAA0ABAAIAKAAJSGVhZGluZyAzAAAKAAMACAEV8AAWPAAFAFWBYxgAAEgA
BEAxAAIASAAOSGVhZGluZyA0LDQsbDMAIgAEAAUDBwERGgMT5vwVtQAWAAAPDgAEGgOnBDQGwQcA
AAAACQBdBABhCQhjFAAAAAAAAAAAAAAwAAlAEQACADAACUhlYWRpbmcgOQAADAAJAAUBBwEV4AEW
AAAMAF0EAGEJCGMYAGsAACIAQUDy/6EAIgAWRGVmYXVsdCBQYXJhZ3JhcGggRm9udAAAAAAAAAAA
AAAAOgD+TwEA8gA6AAhlbnVtbGV2MQAdAA8ABQMRpwQTc/4VVgAPDgAEGgOnBDQGwQcAAAAAAAYA
XQQAYQkIRAD+TwEAEgFEAAVBU04uMQAAJAAQABWIAA8dAAn+Af0DpwQ0BmsIEwtKDQ8QYBQAAAAA
AAAAAAALAFWBXQMAYQkIYxIAACAA/k8BARIBIAALQVNOLjEgQ29udC4AAAUAEQAVAAAAAAAkAP5P
AQACACQAAmxiAA8AEgAFAwgBEA4AFYgAFngAAAMAXQQAADgAQkABADIBOAAJQm9keSBUZXh0AAAa
ABMABQMViAAWeAAPDgAEGgOnBDQGwQcAAAAABgBdBABhCQheAP5PAQBCAV4AA2FzbgAAQwAUAAcB
ECsAEWwCFCT/AAAWeAAPLwAPawKOBLIGHQmIC/MNXhDKEjUVoBcLGnYc4h5NIbgjQEBAQEBAQEBA
QEBAQEBAAAgAVYFdAwBjEgAkAP5PAQBSASQAAmxpAA0AFQAFAxHQAhOY/hZ4AAAFAF0EAGIBABoA
/k+iAGEBGgAKQVNOLjEgV29yZAADAGEABAAAAAAABzAAAAUA/////wAA/////wYABCH//wEAACH/
/wIABCH//wMAACH//wQABCH//wUAACD//wYAAAAAAEYHAAAhEwAAuxwAAB4nAABfLQAABzAAAAAA
PQAAAAEACQEAAAIArgAAAAMApwAAAAQABQAAAAUAAAAAAAAAAADQJQAAHicAAC4oAAC8KAAAQykA
AJcrAAAHMAAAmgAUAJoAFACaABMAmgATAJoAEwCaABQABgAAAAADAABpIAAAMzAAAAczAAAaABsA
HAAAAwAAfhkAAGQtAAD5MAAA2jEAAAczAAAdAB4AHwAgACEAIgANU3VlIEEuIE1pa2xvcxFDOlxY
NTAwXE1BVENILkRPQ/9ASFAgTGFzZXJKZXQgNVNpLzVTaSBNWABMUFQyOgBIUDVTSQBIUCBMYXNl
ckpldCA1U2kvNVNpIE1YAAAAAAAAAAAAAAoDNwJEAJABA/cAAAEAAQDAGMASZAABAAcAWAIBAAEA
WAICAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwIBAAAACAAAAAEAA1BYAlgCBgACAAAAAQAAEFdJ
TldPUkQAAAAAAAEAAAAAgAEAAQABAAAAAAAAAAAAAAAAAAABQ291cmllciBOZXcAAAAAAAAAAAAA
AAAAAAAAAAAAAACwBJABAAADACAABwAAACgAAAAIAAEAAgABAAYAAwABAFgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwlMUFQyAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQNVNJ
AAAAAABIUCBMYXNlckpldCA1U2kvNVNpIE1YAAAAAAAAAAAAAAoDNwJEAJABA/cAAAEAAQDAGMAS
ZAABAAcAWAIBAAEAWAICAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwIBAAAACAAAAAEAA1BYAlgC
BgACAAAAAQAAEFdJTldPUkQAAAAAAAEAAAAAgAEAAQABAAAAAAAAAAAAAAAAAAABQ291cmllciBO
ZXcAAAAAAAAAAAAAAAAAAAAAAAAAAACwBJABAAADACAABwAAACgAAAAIAAEAAgABAAYAAwABAFgC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwlMUFQyAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAEhQNVNJAAAAAAABgAEABjAAAAYwAAAJAACAAIAGMAAABQAAAFwvAABlABUWkAEAAFRp
bWVzIE5ldyBSb21hbgAMFpABAgBTeW1ib2wACyaQAQAAQXJpYWwAFiKQAQAKSGVsdmV0aWNhAEFy
aWFsAPIcEpABAAZUaW1lcwBUaW1lcyBOZXcgUm9tYW4AACIABAABCIgYAADQAgAAaAEAAAAAUPMV
puErG2YAAAAABAAbAAAAAAAAAAAAAAAAAAAAAAAEAIMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABZAkEAAAATMTIuNwlNYXRjaGluZyBydWxlcwAAAA1TdWUgQS4gTWlrbG9zDVN1ZSBBLiBNaWts
b3MAAAAAAAAAAAAA0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAAB
AAAAAQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8=

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21795 for ietf-pkix-bks; Thu, 24 Sep 1998 07:59:51 -0700 (PDT)
Received: from always.got.net ([e-mail] [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21791 for <[e-mail]>; Thu, 24 Sep 1998 07:59:50 -0700 (PDT)
Received: from got.net (SantaCruz-x2-3-133.got.net [209.66.100.133]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id IAA22427; Thu, 24 Sep 1998 08:05:37 -0700
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 08:05:20 -0700
From: Michael McNeil <[e-mail]>
Organization: GMT
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Stephen Kent <[e-mail]>, Warwick Ford <[e-mail]>, [e-mail], Jeffrey Schiller <[e-mail]>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
1-831-438-7811


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21579 for ietf-pkix-bks; Thu, 24 Sep 1998 07:25:27 -0700 (PDT)
Received: from bilbo.thawte.com (bilbo.thawte.com [196.25.207.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21575 for <[e-mail]>; Thu, 24 Sep 1998 07:25:14 -0700 (PDT)
Received: from thawte.com (really [196.25.207.2]) by thawte.com via in.smtpd with esmtp id <[e-mail]> (Debian Smail3.2.0.101) for <[e-mail]>; Thu, 24 Sep 1998 16:31:02 +0200 (SAST) 
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 16:26:50 +0200
From: Mark Shuttleworth <[e-mail]>
Reply-To: [e-mail]
Organization: Thawte Consulting
X-Mailer: Mozilla 4.5b2 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: NEW Data type for certificate selection ?
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms78C9DE34404C8A045EF33A31"
Sender: [e-mail]
Precedence: bulk

This is a cryptographically signed message in MIME format.

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

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

MIIH8AYJKoZIhvcNAQcCoIIH4TCCB90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BhMwggLSMIICO6ADAgECAgItQzANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx
Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2MB4XDTk4MDkxNjE4MzQ1NFoXDTk5MDkxNjE4MzQ1NFowczEVMBMGA1UEBBMMU2h1
dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy
ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq
hkiG9w0BAQEFAANLADBIAkEAw8CXH/zhGBuu9boNBAXbPp+77G8rFuuuzboLsKl5DkqfgmXf
/JOadF3bwNG1QetRQKuEQek4jTNQPqjxdiQo/QIDAQABo3IwcDARBglghkgBhvhCAQEEBAMC
BaAwDgYDVR0PAQH/BAQDAgWgMBwGBStlAQQBBBMwEQIBADAMMAoCAQEEBW1hcmtzMAwGA1Ud
EwEB/wQCMAAwHwYDVR0jBBgwFoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEE
BQADgYEATUOQ3uxrewGzaUVHZZgsul+T2PrBsQMe/Tw2CZO7jjj0EM4ajBLo334y5xJNBtjo
n9SoxhnEhfKo5GQsXgy+Ugb0FxFlrP3d1gMNHzDmg80gxw5JCPuzgN6IQGBXewnxdb2W2tse
Gbo5uJjquMwIggkVMd8Hz2O8uQvIBm1LdZowggM5MIICoqADAgECAgEKMA0GCSqGSIb3DQEB
BAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20w
HhcNOTgwOTE2MTc1NTM0WhcNMDAwOTE1MTc1NTM0WjCBuTELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0
ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1
NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45
LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpeXU1NBfCALuByF9JL+ra44e6yAH
AhWEa4/QkyQfG53uaLK5LE/pk2cXEBceoflDQSO5MKp2l7vz5/2BwLUxi/amUCZU8pUo6xmk
HpcesOK4m8EEmjLQPAlsT+Q1T/B2vwATA09FCGDz/LTQkAGKEsmcun9S6iqTNTY8POQ1LwID
AQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX53
9IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBACzHgh8BQz4Hj+5pXKlkgvjAlq2TK8ubUNdAmoHC
uqZ2nTyVQNxVweFVgnmrCimm1QzhVyg+j/m71d8Nk1iqWy2LjzPk3VgVNXZyFSm9QvRakgt3
X50n25otThuCBo7SjVa7ld7bDGUF3pWeAt1TF76+/GvDGiJ6FCthvcKfXnpaMYIBpTCCAaEC
AQEwgcAwgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcT
C0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhh
d3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNgICLUMwCQYFKw4DAhoFAKB9MBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDkyNDE0MjY1MFowHgYJ
KoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUdte0yJez9q3I
TJRb4V+uB9bopawwDQYJKoZIhvcNAQEBBQAEQDhgTnn8/oGeVEanel2njqWPQsFdd4BaZzO6
6aRt8q/LvBwyO+baEiC25qSgyfF6iOA8AV4l7WDZu5Y/2B6r6Eg=
--------------ms78C9DE34404C8A045EF33A31--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21513 for ietf-pkix-bks; Thu, 24 Sep 1998 07:21:25 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21509 for <[e-mail]>; Thu, 24 Sep 1998 07:21:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02163; Thu, 24 Sep 1998 10:27:24 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Thu, 24 Sep 1998 10:27:24 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail] 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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21495 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:40 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21491 for <[e-mail]>; Thu, 24 Sep 1998 07:20:39 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02093; Thu, 24 Sep 1998 10:26:39 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dcs-00.txt
Date: Thu, 24 Sep 1998 10:26:39 -0400
Sender: [e-mail]
Precedence: bulk

--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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21490 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:35 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21486 for <[e-mail]>; Thu, 24 Sep 1998 07:20:34 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02081; Thu, 24 Sep 1998 10:26:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-00.txt
Date: Thu, 24 Sep 1998 10:26:34 -0400
Sender: [e-mail]
Precedence: bulk

--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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21482 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:10 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21477 for <[e-mail]>; Thu, 24 Sep 1998 07:20:08 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02063; Thu, 24 Sep 1998 10:26:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-11.txt
Date: Thu, 24 Sep 1998 10:26:08 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail] 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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21425 for ietf-pkix-bks; Thu, 24 Sep 1998 07:06:55 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21421 for <[e-mail]>; Thu, 24 Sep 1998 07:06:54 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA09631; Thu, 24 Sep 1998 07:12:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Thu, 24 Sep 1998 09:56:50 -0400
To: "Todd S. Glassey" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Amending the PKIX-WG Charter to reflect the addition of timestamping
Cc: [e-mail]
In-Reply-To: <001c01bde698$615e7640$200ba8c0@tsg-laptop>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
>Warwick Ford <[e-mail]>
>
>Security Area Director(s):
>Jeffrey Schiller <[e-mail]>
>Marcus Leech <[e-mail]>
>
>Security Area Advisor:
>Jeffrey Schiller <[e-mail]>
>
>Mailing Lists:
>General Discussion:[e-mail]
>To Subscribe: [e-mail]
>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 ----
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20975 for ietf-pkix-bks; Thu, 24 Sep 1998 05:50:11 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20971 for <[e-mail]>; Thu, 24 Sep 1998 05:50:10 -0700 (PDT)
Received: 	id IAA22113; Thu, 24 Sep 1998 08:54:41 -0400
Received: by gateway id <S2S6ZMGZ>; Thu, 24 Sep 1998 08:51:16 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: X.509 Documentation
Date: Thu, 24 Sep 1998 08:51:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA20972
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 24, 1998 2:59 PM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	Re: X.509 Documentation
> 
> [e-mail] 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
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20857 for ietf-pkix-bks; Thu, 24 Sep 1998 05:38:06 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20853 for <[e-mail]>; Thu, 24 Sep 1998 05:38:04 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id OAA03085; Thu, 24 Sep 1998 14:44:08 +0200 (CEST)
Received: from stefans (t4o68p1.telia.com [62.20.139.121]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA25911; Thu, 24 Sep 1998 14:44:02 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 24 Sep 1998 14:41:23 +0200
To: [e-mail], [e-mail], [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA20854
Sender: [e-mail]
Precedence: bulk

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                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20658 for ietf-pkix-bks; Thu, 24 Sep 1998 04:54:03 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20654 for <[e-mail]>; Thu, 24 Sep 1998 04:54:02 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id XAA13067; Thu, 24 Sep 1998 23:59:34 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90663837419831>; Thu, 24 Sep 1998 23:59:34 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: basic constraint extension
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 24 Sep 1998 23:59:34 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18001 for ietf-pkix-bks; Thu, 24 Sep 1998 02:51:43 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17997 for <[e-mail]>; Thu, 24 Sep 1998 02:51:41 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA09608; Thu, 24 Sep 1998 11:59:00 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA15648; Thu, 24 Sep 1998 11:59:08 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 11:59:24 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: X.509 Documentation
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

[e-mail] 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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17852 for ietf-pkix-bks; Thu, 24 Sep 1998 02:21:50 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17848 for <[e-mail]>; Thu, 24 Sep 1998 02:21:47 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA12895; Thu, 24 Sep 1998 11:28:09 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA16688; Thu, 24 Sep 1998 11:27:58 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 11:28:15 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Michael McNeil <[e-mail]>
CC: Stephen Kent <[e-mail]>, Warwick Ford <[e-mail]>, [e-mail], Jeffrey Schiller <[e-mail]>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
> [e-mail]
> 1-831-438-7811





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17767 for ietf-pkix-bks; Thu, 24 Sep 1998 02:05:52 -0700 (PDT)
Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17763 for <[e-mail]>; Thu, 24 Sep 1998 02:05:50 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo26.mx.aol.com (IMOv16.10) id 7HBDa02301 for <[e-mail]>; Thu, 24 Sep 1998 05:11:36 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 24 Sep 1998 05:11:36 EDT
To: [e-mail]
Mime-Version: 1.0
Subject: X.509 Documentation
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 224
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29806 for ietf-pkix-bks; Wed, 23 Sep 1998 20:33:18 -0700 (PDT)
Received: from always.got.net ([e-mail] [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29799 for <[e-mail]>; Wed, 23 Sep 1998 20:33:17 -0700 (PDT)
Received: from got.net (SantaCruz-x2-3-133.got.net [209.66.100.133]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id UAA17148; Wed, 23 Sep 1998 20:39:22 -0700
Message-ID: <[e-mail]>
Date: Wed, 23 Sep 1998 20:39:10 -0700
From: Michael McNeil <[e-mail]>
Organization: GMT
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, Warwick Ford <[e-mail]>
CC: [e-mail], Jeffrey Schiller <[e-mail]>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
1-831-438-7811


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24408 for ietf-pkix-bks; Wed, 23 Sep 1998 11:00:10 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA24404 for <[e-mail]>; Wed, 23 Sep 1998 11:00:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Wed, 23 Sep 1998 11:05:32 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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

--Paul Hoffman, Director
--Internet Mail Consortium

>To: IETF-Announce: ;
>Cc: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
>Date: Wed, 23 Sep 1998 10:43:01 -0400
>Sender: [e-mail]
>
>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:	[e-mail].  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:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-tls-ac509prof-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22037 for ietf-pkix-bks; Wed, 23 Sep 1998 06:57:39 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22033 for <[e-mail]>; Wed, 23 Sep 1998 06:57:37 -0700 (PDT)
Received: 	id KAA28894; Wed, 23 Sep 1998 10:01:06 -0400
Received: by gateway id <S2S6Z20Q>; Wed, 23 Sep 1998 09:57:44 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Steve Kent'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>
Subject: Revised LDAPv2 specs have been submitted
Date: Wed, 23 Sep 1998 09:57:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21064 for ietf-pkix-bks; Wed, 23 Sep 1998 04:29:19 -0700 (PDT)
Received: from maila.telia.com ([e-mail] [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21060 for <[e-mail]>; Wed, 23 Sep 1998 04:29:00 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id NAA12330; Wed, 23 Sep 1998 13:35:13 +0200 (CEST)
Received: from stefans (t4o68p71.telia.com [62.20.139.191]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA26921; Wed, 23 Sep 1998 13:35:09 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 23 Sep 1998 13:32:27 +0200
To: Al Arsenault <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PKIX Roadmap
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA21061
Sender: [e-mail]
Precedence: bulk

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.
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17883 for ietf-pkix-bks; Wed, 23 Sep 1998 00:56:18 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17879 for <[e-mail]>; Wed, 23 Sep 1998 00:56:16 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA15024 for <[e-mail]>; Wed, 23 Sep 1998 10:03:30 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA17156 for <[e-mail]>; Wed, 23 Sep 1998 10:03:37 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 23 Sep 1998 10:03:55 -0700
From: Denis Pinkas <[e-mail]>
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Archive cutoff & Retention period
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17850 for ietf-pkix-bks; Wed, 23 Sep 1998 00:52:30 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17846 for <[e-mail]>; Wed, 23 Sep 1998 00:52:25 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA04146 for <[e-mail]>; Wed, 23 Sep 1998 09:59:15 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA12434 for <[e-mail]>; Wed, 23 Sep 1998 09:59:22 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 23 Sep 1998 09:59:40 -0700
From: Denis Pinkas <[e-mail]>
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Minor comments on OCSP-06
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02987 for ietf-pkix-bks; Tue, 22 Sep 1998 19:13:48 -0700 (PDT)
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.120.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02983 for <[e-mail]>; Tue, 22 Sep 1998 19:13:47 -0700 (PDT)
Received: from tsg-laptop (1Cust96.tnt4.sfo1.da.uu.net [208.250.191.96]) by avocet.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id TAA10448 for <[e-mail]>; Tue, 22 Sep 1998 19:20:08 -0700 (PDT)
From: "Todd S. Glassey" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: Amending the PKIX-WG Charter to reflect the addition of timestamping
Date: Tue, 22 Sep 1998 19:17:57 -0700
Message-ID: <001c01bde698$615e7640$200ba8c0@tsg-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
Warwick Ford <[e-mail]>

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

Security Area Advisor:
Jeffrey Schiller <[e-mail]>

Mailing Lists:
General Discussion:[e-mail]
To Subscribe: [e-mail]
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 ----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25907 for ietf-pkix-bks; Tue, 22 Sep 1998 05:29:18 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA25903 for <[e-mail]>; Tue, 22 Sep 1998 05:29:16 -0700 (PDT)
Received: 	id IAA16369; Tue, 22 Sep 1998 08:31:45 -0400
Received: by gateway id <S2S6Z1VK>; Tue, 22 Sep 1998 08:28:25 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Steve Kent'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Subject: text for attributes
Date: Tue, 22 Sep 1998 08:28:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25745 for ietf-pkix-bks; Tue, 22 Sep 1998 05:13:14 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA25741 for <[e-mail]>; Tue, 22 Sep 1998 05:13:13 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA15055; Tue, 22 Sep 1998 05:17:57 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 22 Sep 1998 08:15:43 -0400
To: Stefan Santesson <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: PKIX Roadmap
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA25513 for ietf-pkix-bks; Tue, 22 Sep 1998 04:31:33 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA25509 for <[e-mail]>; Tue, 22 Sep 1998 04:31:31 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA78840; Tue, 22 Sep 1998 13:36:57 +0200
Received: by HYDRA with Microsoft Mail id <01BDE62D.342F16E0@HYDRA>; Tue, 22 Sep 1998 13:30:45 +0200
Message-ID: <01BDE62D.342F16E0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: OCSP - Public Key Dstribution
Date: Tue, 22 Sep 1998 13:30:44 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA25221 for ietf-pkix-bks; Tue, 22 Sep 1998 03:35:04 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA25217 for <[e-mail]>; Tue, 22 Sep 1998 03:35:01 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA28659; Tue, 22 Sep 1998 11:28:34 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Tue, 22 Sep 1998 11:26:49 +0200
From: "Petra Glöckner" <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: basic constraint extension
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6C21A3596B2679A5F64C275F"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
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

MIIO7wYJKoZIhvcNAQcCoIIO4DCCDtwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DVcwggMFMIICbqADAgECAgIC8zANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJERTEMMAoG
A1UEChMDR01EMR8wHQYDVQQLExZDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTMTgwNgYDVQQLEy9U
cnVzdEZhY3RvcnkgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENlcnRpZmljYXRlczAeFw05ODA3
MTMxNzQ2NDlaFw0wMDAxMDEwMDAwMDBaMGYxCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNHTUQx
LzAtBgkqhkiG9w0BCQEWIFBldHJhLkdsb2Vja25lckBkYXJtc3RhZHQuZ21kLmRlMRgwFgYD
VQQDEw9QZXRyYSBHbG9lY2tuZXIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwgqVtX54BPIm
LAu+u8i7lnOV6lf+79amGCL9Ao5UOStKuLHC2dwH7MP5A8gPVeeiP1kk2tr9hXJmIVDYP7kS
cQIDAQABo4H1MIHyMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgCwMIHRBglghkgBhvhC
AQ0EgcMWgcBDQVVUSU9OOiBUaGUgRGlnaXRhbCBJRCBzdWJqZWN0cyBvZiBJQ0UtVEVMCkNs
YXNzIDAgVHJpYWwgU2VydmljZXMgYXJlIG5vdCBhdXRoZW50aWNhdGVkLgpJdCBtYXkgYmUg
dGhlIGhvbGRlcidzIHJlYWwgbmFtZSBvciBhbiBhbGlhcy4KVXNlIHRoaXMgRGlnaXRhbCBJ
RCBmb3IgdGVzdCBwdXJwb3NlZCBvbmx5LgooYykgR01EIDE5OTcwDQYJKoZIhvcNAQEEBQAD
gYEASgeR+7xR+g2YPSXpdAojcDD1jeo2sMa1hyspawERPfLgagUDcaX5MS/TjYZ8K3lz3Tve
G6U0pWPwRBtAnns/A8hoNApONSQEXupnhNgaRwljFEXm+shdanA33iZKfs6NVCnb1Mbs96pK
xUgpXw4TRe//afL0nNiaRCmSfXohytgwggOhMIIDCqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MGcxCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNHTUQxHzAdBgNVBAsTFkNMQVNTIDAgVFJJQUwg
U0VSVklDRVMxKTAnBgNVBAsTIFRydXN0RmFjdG9yeSBEaWdpdGFsIElEIFNlcnZpY2VzMB4X
DTk3MTIxNzA4MDMyNloXDTAwMDEwMTAwMDAwMFowdjELMAkGA1UEBhMCREUxDDAKBgNVBAoT
A0dNRDEfMB0GA1UECxMWQ0xBU1MgMCBUUklBTCBTRVJWSUNFUzE4MDYGA1UECxMvVHJ1c3RG
YWN0b3J5IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDZXJ0aWZpY2F0ZXMwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBANQJUsDpSSmA85HJLPHj4jDUTWXPUwYaqNvA3r3AdhFqIacLQwtn
FOoMR4CZqaewurOWI23kw2NK4/2I+GdTwkk5aEYAo4eA9FFwHBxq+b80xbO4ymTKxkah8DTv
acv+JkLwFnjc7DEzuJoK61ywR8UJP/FQjD53o8ATXhoGNIIDAgMBAAGjggFMMIIBSDAfBgNV
HSMEGDAWgBR43QkpxguDM6Uc3wFLHlNH8iD1SzAdBgNVHQ4EFgQUM47EbBv7+7Tjj2OaluUR
VEIj7fwwDgYDVR0PAQH/BAQDAgH2MA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQD
AgAHMIHRBglghkgBhvhCAQ0EgcMWgcBDQVVUSU9OOiBUaGUgRGlnaXRhbCBJRCBzdWJqZWN0
cyBvZiBJQ0UtVEVMCkNsYXNzIDAgVHJpYWwgU2VydmljZXMgYXJlIG5vdCBhdXRoZW50aWNh
dGVkLgpJdCBtYXkgYmUgdGhlIGhvbGRlcidzIHJlYWwgbmFtZSBvciBhbiBhbGlhcy4KVXNl
IHRoaXMgRGlnaXRhbCBJRCBmb3IgdGVzdCBwdXJwb3NlZCBvbmx5LgooYykgR01EIDE5OTcw
DQYJKoZIhvcNAQEEBQADgYEAXWnV7vH1s9e0opHh/Hk1nOgpxEbx7XaSAbnVzdUoOxxKvbkl
o0QaB79OV4oLkrFAscMU8iKWN9RkBmWuartRnq45DRsAWMur8DlgbrShlMBEC71OsE2I1FMP
xGe/rJwp2x5Or1M1mchKI808S7WblPyJxCBOMt3Q1in7F1Boz1wwggNgMIICyaADAgECAgEB
MA0GCSqGSIb3DQEBBAUAMEgxDzANBgNVBAcTBkV1cm9wZTEQMA4GA1UEChMHSUNFLVRFTDEj
MCEGA1UECxMaQ0xBU1MgMCBUUklBTCBTRVJWSUNFUyBQS0kwHhcNOTcxMjE3MDgwMzI0WhcN
MDAwMTAxMDAwMDAwWjBnMQswCQYDVQQGEwJERTEMMAoGA1UEChMDR01EMR8wHQYDVQQLExZD
TEFTUyAwIFRSSUFMIFNFUlZJQ0VTMSkwJwYDVQQLEyBUcnVzdEZhY3RvcnkgRGlnaXRhbCBJ
RCBTZXJ2aWNlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA7gWKqAf0MfIp/QL9wMe3
mzEt/+DYSUs6VqkgXehMSbLblwPV7v+QhzhH/JSUoQKVi85qQom7+tnXBJxylB4mfl4AsqyG
SE4IGZPnVcxI4rzW5vhrNVCSzeAkqe2PnoPpZrlh8IYYYKINeGzmZ5QMWEmnDp8+M13zzAUD
A/11ZFMCAwEAAaOCATkwggE1MB8GA1UdIwQYMBaAFLNK4JQgbBz8WKb6QycGs8Hxz6SyMB0G
A1UdDgQWBBR43QkpxguDM6Uc3wFLHlNH8iD1SzAOBgNVHQ8BAf8EBAMCAfYwDwYDVR0TAQH/
BAUwAwEB/zCB0QYJYIZIAYb4QgENBIHDFoHAQ0FVVElPTjogVGhlIERpZ2l0YWwgSUQgc3Vi
amVjdHMgb2YgSUNFLVRFTApDbGFzcyAwIFRyaWFsIFNlcnZpY2VzIGFyZSBub3QgYXV0aGVu
dGljYXRlZC4KSXQgbWF5IGJlIHRoZSBob2xkZXIncyByZWFsIG5hbWUgb3IgYW4gYWxpYXMu
ClVzZSB0aGlzIERpZ2l0YWwgSUQgZm9yIHRlc3QgcHVycG9zZWQgb25seS4KKGMpIEdNRCAx
OTk3MA0GCSqGSIb3DQEBBAUAA4GBAK+hyS6CuuCt2kH7FlvTgpYf39q4sji5JytL3KCExfLe
b4H+YPNbO7cy08KTGa9qSQyodh5+KwXFH9lUct5//bFkm4WfKHH7O2u4+rjWGfGZV6VB1ZCD
dX5CdvVu8O3qNPoQThw60WowKJIS8FkW5BKLP7SB4VJetNrKMz9zwWnJMIIDQTCCAqqgAwIB
AgIBADANBgkqhkiG9w0BAQQFADBIMQ8wDQYDVQQHEwZFdXJvcGUxEDAOBgNVBAoTB0lDRS1U
RUwxIzAhBgNVBAsTGkNMQVNTIDAgVFJJQUwgU0VSVklDRVMgUEtJMB4XDTk3MTIxNzA3NTg0
NVoXDTAwMDEwMTAwMDAwMFowSDEPMA0GA1UEBxMGRXVyb3BlMRAwDgYDVQQKEwdJQ0UtVEVM
MSMwIQYDVQQLExpDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTIFBLSTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEA9jNYTNZLLl7MxMhg1dSc0wq+PiSq4LkPwDL9J+dQk1EJdLWaopkd/NNR
uM37r03RVbSHeI0FPQoylnJpu0Kj6KNWxVwIeGeWGrIdhRShUSh3n2bFSD/0T5uHWvsN1U9f
d6uxDaYHcnfLLCtTi76Piu2GCJK4eH3W76Oo3Ei4VoMCAwEAAaOCATkwggE1MB8GA1UdIwQY
MBaAFLNK4JQgbBz8WKb6QycGs8Hxz6SyMB0GA1UdDgQWBBSzSuCUIGwc/Fim+kMnBrPB8c+k
sjAOBgNVHQ8BAf8EBAMCAfYwDwYDVR0TAQH/BAUwAwEB/zCB0QYJYIZIAYb4QgENBIHDFoHA
Q0FVVElPTjogVGhlIERpZ2l0YWwgSUQgc3ViamVjdHMgb2YgSUNFLVRFTApDbGFzcyAwIFRy
aWFsIFNlcnZpY2VzIGFyZSBub3QgYXV0aGVudGljYXRlZC4KSXQgbWF5IGJlIHRoZSBob2xk
ZXIncyByZWFsIG5hbWUgb3IgYW4gYWxpYXMuClVzZSB0aGlzIERpZ2l0YWwgSUQgZm9yIHRl
c3QgcHVycG9zZWQgb25seS4KKGMpIEdNRCAxOTk3MA0GCSqGSIb3DQEBBAUAA4GBALkKsGZG
E5ckTCE0F7hTF2eZgnDZYgm709UJeozPRB/3KjuyjdxlbVj2eiCWVB9HpH0KK2kEqnhgiHWL
xwQGuycFD7Px7SDIwjEC/7c9YERIw1GmGWe2g6EatOP3oS/4tCy72TODDhD5WeYAMFcpKihR
Skp0N+zOhEuDvxyXGauuMYIBYDCCAVwCAQEwfDB2MQswCQYDVQQGEwJERTEMMAoGA1UEChMD
R01EMR8wHQYDVQQLExZDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTMTgwNgYDVQQLEy9UcnVzdEZh
Y3RvcnkgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENlcnRpZmljYXRlcwICAvMwCQYFKw4DAhoF
AKB9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDkyMjA5
MjY0OVowHgYJKoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQU
Ypl1kQvQEkbLfHbDhyuczu2HatYwDQYJKoZIhvcNAQEBBQAEQCWTOZQScCOMbV6jt7j/IN+M
XcHMcvD2wgOSKEb1Sqr48Aof6oFV3oeBQseB8SJqpl93ZiCRYZBl+1T3SVMCdZc=
--------------ms6C21A3596B2679A5F64C275F--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA03834 for ietf-pkix-bks; Mon, 21 Sep 1998 21:22:03 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03830 for <[e-mail]>; Mon, 21 Sep 1998 21:22:01 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id GAA05716; Tue, 22 Sep 1998 06:28:20 +0200 (CEST)
Received: from stefans (t2o68p111.telia.com [62.20.138.231]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id GAA27141; Tue, 22 Sep 1998 06:28:18 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 22 Sep 1998 06:25:35 +0200
To: Al Arsenault <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PKIX Roadmap
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id VAA03831
Sender: [e-mail]
Precedence: bulk

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.
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29811 for ietf-pkix-bks; Mon, 21 Sep 1998 10:30:40 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29807 for <[e-mail]>; Mon, 21 Sep 1998 10:30:39 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA06046; Mon, 21 Sep 1998 10:35:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Mon, 21 Sep 1998 13:32:57 -0400
To: Stefan Santesson <[e-mail]>, Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: PKIX Roadmap
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29336 for ietf-pkix-bks; Mon, 21 Sep 1998 09:17:24 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29332 for <[e-mail]>; Mon, 21 Sep 1998 09:17:22 -0700 (PDT)
Received: from [128.33.238.151] (TC151.BBN.COM [128.33.238.151]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA05250 for <[e-mail]>; Mon, 21 Sep 1998 12:23:14 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1305727475==_ma============"
X-Sender: [e-mail]
Message-Id: <v04011701b22c2cbc4e8e@[128.33.238.151]>
Date: Mon, 21 Sep 1998 12:20:00 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: meeting minutes
Sender: [e-mail]
Precedence: bulk

--============_-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:
[e-mail].



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:
[e-mail].




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============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28710 for ietf-pkix-bks; Mon, 21 Sep 1998 07:34:25 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28706 for <[e-mail]>; Mon, 21 Sep 1998 07:34:21 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id QAA11344; Mon, 21 Sep 1998 16:40:31 +0200 (CEST)
Received: from stefans (t4o68p96.telia.com [62.20.139.216]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA06265; Mon, 21 Sep 1998 16:22:11 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 21 Sep 1998 16:19:49 +0200
To: Sean Turner <[e-mail]>, PKIX <[e-mail]>, "Arsenault, Al W." <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PKIX Roadmap
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA28707
Sender: [e-mail]
Precedence: bulk

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
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22403 for ietf-pkix-bks; Mon, 21 Sep 1998 00:38:25 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22390 for <[e-mail]>; Mon, 21 Sep 1998 00:36:58 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA17478; Mon, 21 Sep 1998 09:18:26 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA16740; Mon, 21 Sep 1998 09:18:25 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Mon, 21 Sep 1998 09:18:44 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: OCSP - Public Key Dstribution
References: <01BDE484.F1DA1820@HYDRA>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:  Saturday, September 19, 1998 02:15
> To:  Andreas Berger
> Cc:  Peter Sylvester; [e-mail]; [e-mail]
> 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:[e-mail]
>  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:[e-mail]
 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22389 for ietf-pkix-bks; Mon, 21 Sep 1998 00:36:51 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22383 for <[e-mail]>; Mon, 21 Sep 1998 00:36:11 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA09835; Mon, 21 Sep 1998 09:29:18 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA15096; Mon, 21 Sep 1998 09:29:22 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Mon, 21 Sep 1998 09:29:41 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04797 for ietf-pkix-bks; Sun, 20 Sep 1998 17:02:12 -0700 (PDT)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04793 for <[e-mail]>; Sun, 20 Sep 1998 17:02:06 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id KAA06232 for <[e-mail]>; Mon, 21 Sep 1998 10:08:18 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: Testing the ASN.1 in Part 1
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 Sep 1998 10:08:16 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


-- 
Dean Povey,         | e-m: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02905 for ietf-pkix-bks; Sun, 20 Sep 1998 10:35:53 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02901 for <[e-mail]>; Sun, 20 Sep 1998 10:35:51 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id TAA10451; Sun, 20 Sep 1998 19:41:59 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA02115; Sun, 20 Sep 1998 19:41:58 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA18646; Sun, 20 Sep 1998 19:41:58 +0200
Date: Sun, 20 Sep 1998 19:41:58 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: OCSP - Public Key Dstribution
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

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.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02899 for ietf-pkix-bks; Sun, 20 Sep 1998 10:35:23 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02895 for <[e-mail]>; Sun, 20 Sep 1998 10:35:21 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id TAA10447; Sun, 20 Sep 1998 19:41:29 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA02111; Sun, 20 Sep 1998 19:41:28 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA18643; Sun, 20 Sep 1998 19:41:28 +0200
Date: Sun, 20 Sep 1998 19:41:28 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [e-mail]
Precedence: bulk

> 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 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA29413 for ietf-pkix-bks; Sun, 20 Sep 1998 01:54:00 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA29409 for <[e-mail]>; Sun, 20 Sep 1998 01:53:57 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA59705; Sun, 20 Sep 1998 10:59:56 +0200
Received: by HYDRA with Microsoft Mail id <01BDE484.F1DA1820@HYDRA>; Sun, 20 Sep 1998 10:53:48 +0200
Message-ID: <01BDE484.F1DA1820@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: OCSP - Public Key Dstribution
Date: Sun, 20 Sep 1998 10:53:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA29410
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent:  Saturday, September 19, 1998 02:15
To:  Andreas Berger
Cc:  Peter Sylvester; [e-mail]; [e-mail]
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:[e-mail]
 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21235 for ietf-pkix-bks; Sat, 19 Sep 1998 13:51:03 -0700 (PDT)
Received: from cylink.com ([204.160.108.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21231 for <[e-mail]>; Sat, 19 Sep 1998 13:51:02 -0700 (PDT)
Received: by  cylink.com (8.8.8/SMI-SVR4) id OAA07962; Sat, 19 Sep 1998 14:01:17 -0700 (PDT)
Received: from cylink252.cylink.com(205.226.82.252) by enforcer.cylink.com via smap (V2.0) id xma007960; Sat, 19 Sep 98 14:00:57 -0700
Reply-To: <[e-mail]>
From: "Amit Kapoor" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: Testing the ASN.1 in Part 1
Date: Sat, 19 Sep 1998 13:58:24 -0700
Message-ID: <001a01bde410$3dbd7cc0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

	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


 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26882 for ietf-pkix-bks; Fri, 18 Sep 1998 17:54:41 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26878 for <[e-mail]>; Fri, 18 Sep 1998 17:54:40 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id RAA13604; Fri, 18 Sep 1998 17:58:14 -0700 (PDT)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA11253; Fri, 18 Sep 1998 18:00:07 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 18 Sep 1998 18:00:08 -0700
To: [e-mail]
From: Michael Myers <[e-mail]>
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25592 for ietf-pkix-bks; Fri, 18 Sep 1998 14:33:09 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25586 for <[e-mail]>; Fri, 18 Sep 1998 14:33:07 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id OAA19912; Fri, 18 Sep 1998 14:39:10 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 18 Sep 1998 14:38:11 -0700
To: "Flanigan, Bill" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: proposed text for attributes
In-Reply-To: <5F21F6A15446D211B0730020484016A34A8DED@RBMAIL103>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25057 for ietf-pkix-bks; Fri, 18 Sep 1998 13:29:40 -0700 (PDT)
Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25053 for <[e-mail]>; Fri, 18 Sep 1998 13:29:39 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <TDQTCBB7>; Fri, 18 Sep 1998 16:34:34 -0400
Message-ID: <5F21F6A15446D211B0730020484016A34A8DED@RBMAIL103>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: proposed text for attributes
Date: Fri, 18 Sep 1998 16:39:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Engineering       DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[e-mail]]
> Sent:	Friday, September 18, 1998 12:39 PM
> To:	[e-mail]
> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23955 for ietf-pkix-bks; Fri, 18 Sep 1998 11:09:14 -0700 (PDT)
Received: from romulus.cs.ut.ee ([e-mail] [193.40.5.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23951 for <[e-mail]>; Fri, 18 Sep 1998 11:09:12 -0700 (PDT)
Received: from localhost (jan@localhost) by romulus.cs.ut.ee (8.9.1/8.9.1/romulus-1.4) with SMTP id VAA13259 for <[e-mail]>; Fri, 18 Sep 1998 21:15:08 +0300 (EET DST)
Date: Fri, 18 Sep 1998 21:15:06 +0300 (   )
From: Jan Willemson <[e-mail]>
To: [e-mail]
Subject: Who uses what?
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23493 for ietf-pkix-bks; Fri, 18 Sep 1998 10:23:23 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23488; Fri, 18 Sep 1998 10:23:22 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA15812; Fri, 18 Sep 1998 10:28:13 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Fri, 18 Sep 1998 13:29:49 -0400
To: Dean Povey <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Testing the ASN.1 in Part 1 
Cc: Paul Hoffman / IMC <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 15 Sep 1998 14:29:01 +1000."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<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:
[e-mail]&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: [phone]
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>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23017 for ietf-pkix-bks; Fri, 18 Sep 1998 09:33:46 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23013 for <[e-mail]>; Fri, 18 Sep 1998 09:33:45 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Fri, 18 Sep 1998 09:39:16 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: proposed text for attributes
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22573 for ietf-pkix-bks; Fri, 18 Sep 1998 08:40:12 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22569 for <[e-mail]>; Fri, 18 Sep 1998 08:40:10 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id RAA21236; Fri, 18 Sep 1998 17:41:08 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id RAA21071; Fri, 18 Sep 1998 17:41:07 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id RAA17885; Fri, 18 Sep 1998 17:41:07 +0200
Date: Fri, 18 Sep 1998 17:41:07 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

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.

   }



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22288 for ietf-pkix-bks; Fri, 18 Sep 1998 08:08:01 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22284 for <[e-mail]>; Fri, 18 Sep 1998 08:07:56 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id RAA16372; Fri, 18 Sep 1998 17:14:34 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA17286; Fri, 18 Sep 1998 17:14:27 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 17:14:48 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Andreas Berger <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21046 for ietf-pkix-bks; Fri, 18 Sep 1998 05:00:00 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA21042 for <[e-mail]>; Fri, 18 Sep 1998 04:59:58 -0700 (PDT)
Received: 	id IAA04558; Fri, 18 Sep 1998 08:03:06 -0400
Received: by gateway id <S2S6Y5Z8>; Fri, 18 Sep 1998 07:59:50 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: proposed text for attributes
Date: Fri, 18 Sep 1998 07:59:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA18545 for ietf-pkix-bks; Fri, 18 Sep 1998 03:02:10 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA18541 for <[e-mail]>; Fri, 18 Sep 1998 03:02:07 -0700 (PDT)
Received: from darmstadt.gmd.de (aberger@pc-turin [141.12.33.71]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA27586; Fri, 18 Sep 1998 12:06:18 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 12:06:44 +0200
From: Andreas Berger <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18216 for ietf-pkix-bks; Fri, 18 Sep 1998 01:56:54 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18212 for <[e-mail]>; Fri, 18 Sep 1998 01:56:53 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id LAA08690; Fri, 18 Sep 1998 11:02:54 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA17532; Fri, 18 Sep 1998 11:02:54 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA17802; Fri, 18 Sep 1998 11:02:53 +0200
Date: Fri, 18 Sep 1998 11:02:53 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [e-mail]
Precedence: bulk

> 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18176 for ietf-pkix-bks; Fri, 18 Sep 1998 01:50:30 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18171 for <[e-mail]>; Fri, 18 Sep 1998 01:50:27 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id KAA08440; Fri, 18 Sep 1998 10:56:25 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id KAA17394; Fri, 18 Sep 1998 10:56:24 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id KAA17797; Fri, 18 Sep 1998 10:56:24 +0200
Date: Fri, 18 Sep 1998 10:56:24 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18121 for ietf-pkix-bks; Fri, 18 Sep 1998 01:43:45 -0700 (PDT)
Received: from mail-gw.pacbell.net (mail-gw.pacbell.net [206.13.28.25]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18117 for <[e-mail]>; Fri, 18 Sep 1998 01:43:44 -0700 (PDT)
Received: from pacbell.net (ppp-206-170-3-162.okld03.pacbell.net [206.170.3.162]) by mail-gw.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id BAA19674; Fri, 18 Sep 1998 01:49:45 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 01:41:01 -0700
From: Dan Weinstein <[e-mail]>
X-Mailer: Mozilla 4.5b2 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

>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
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07834 for ietf-pkix-bks; Thu, 17 Sep 1998 22:42:05 -0700 (PDT)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07821; Thu, 17 Sep 1998 22:42:01 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id PAA24765; Fri, 18 Sep 1998 15:48:00 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
cc: Paul Hoffman / IMC <[e-mail]>, [e-mail]
Subject: Re: Testing the ASN.1 in Part 1 
In-reply-to: Your message of "Tue, 15 Sep 1998 14:29:01 +1000." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Sep 1998 15:47:57 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>
>
>>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: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26263 for ietf-pkix-bks; Thu, 17 Sep 1998 14:47:40 -0700 (PDT)
Received: from atlantic.valicert.com ([e-mail] [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26259 for <[e-mail]>; Thu, 17 Sep 1998 14:47:39 -0700 (PDT)
Received: (qmail 2737 invoked from network); 17 Sep 1998 21:53:34 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by 209.185.6.162 with SMTP; 17 Sep 1998 21:53:34 -0000
Message-ID: <[e-mail]>
Date: Thu, 17 Sep 1998 14:53:31 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b2 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23625 for ietf-pkix-bks; Thu, 17 Sep 1998 09:30:23 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23621 for <[e-mail]>; Thu, 17 Sep 1998 09:30:22 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id SAA27290 for <[e-mail]>; Thu, 17 Sep 1998 18:36:02 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA11058 for <[e-mail]>; Thu, 17 Sep 1998 18:36:02 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA17487 for [e-mail]; Thu, 17 Sep 1998 18:36:01 +0200
Date: Thu, 17 Sep 1998 18:36:01 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: [e-mail]
Precedence: bulk

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.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23589 for ietf-pkix-bks; Thu, 17 Sep 1998 09:22:26 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23585 for <[e-mail]>; Thu, 17 Sep 1998 09:22:25 -0700 (PDT)
Received: 	id MAA26121; Thu, 17 Sep 1998 12:26:32 -0400
Received: by gateway id <S2S6YV9W>; Thu, 17 Sep 1998 12:23:18 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 12:23:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 16, 1998 10:26 PM
> To: 	[e-mail]
> 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"?
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23104 for ietf-pkix-bks; Thu, 17 Sep 1998 08:38:23 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23100 for <[e-mail]>; Thu, 17 Sep 1998 08:38:22 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA17795; Thu, 17 Sep 1998 08:44:19 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <SW42KV8H>; Thu, 17 Sep 1998 08:43:56 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Thu, 17 Sep 1998 08:43:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Wednesday, September 16, 1998 7:27 PM
To: [e-mail]
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"?


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22458 for ietf-pkix-bks; Thu, 17 Sep 1998 07:04:25 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22454 for <[e-mail]>; Thu, 17 Sep 1998 07:04:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA14218; Thu, 17 Sep 1998 10:09:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-06.txt
Date: Thu, 17 Sep 1998 10:09:49 -0400
Sender: [e-mail]
Precedence: bulk

--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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA29190 for ietf-pkix-bks; Wed, 16 Sep 1998 19:24:20 -0700 (PDT)
Received: from dc.jones.com (dc.jones.com [206.156.0.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA29186 for <[e-mail]>; Wed, 16 Sep 1998 19:24:18 -0700 (PDT)
Received: from dc.jones.com (cm0714h.jones.com [208.159.209.173]) by dc.jones.com (8.8.8/8.8.8) with ESMTP id WAA19170 for <[e-mail]>; Wed, 16 Sep 1998 22:27:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 16 Sep 1998 22:26:37 -0400
From: bgmiller <[e-mail]>
Reply-To: [e-mail]
Organization: Jones Internet Channel
X-Mailer: Mozilla 4.05 [en]C-JIC-DC  (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory Attributes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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"?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27832 for ietf-pkix-bks; Wed, 16 Sep 1998 15:43:37 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27828 for <[e-mail]>; Wed, 16 Sep 1998 15:43:36 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 16 Sep 1998 15:49:01 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attributes
In-Reply-To: <[e-mail] ndem.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27652 for ietf-pkix-bks; Wed, 16 Sep 1998 15:16:39 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27648 for <[e-mail]>; Wed, 16 Sep 1998 15:16:38 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA23758; Wed, 16 Sep 1998 15:22:29 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <SW42KM98>; Wed, 16 Sep 1998 15:22:04 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes
Date: Wed, 16 Sep 1998 15:22:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, September 16, 1998 2:23 PM
To: [e-mail]
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
[phone] (voice)
[phone] (fax)
[e-mail]
http://www.cygnacom.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27294 for ietf-pkix-bks; Wed, 16 Sep 1998 14:18:03 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27290 for <[e-mail]>; Wed, 16 Sep 1998 14:18:00 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7T51TK>; Wed, 16 Sep 1998 17:22:56 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1AAE@WUHER>
From: Santosh Chokhani <[e-mail]>
To: [e-mail]
Subject: Storage of CA Certificates in LDAP and X.500 Directory Attributes
Date: Wed, 16 Sep 1998 17:22:55 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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
[phone] (voice)
[phone] (fax)
[e-mail]
http://www.cygnacom.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12601 for ietf-pkix-bks; Tue, 15 Sep 1998 10:46:56 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12597 for <[e-mail]>; Tue, 15 Sep 1998 10:46:55 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA01587; Tue, 15 Sep 1998 10:50:19 -0700 (PDT)
Received: from wford-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA14084; Tue, 15 Sep 1998 10:52:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 15 Sep 1998 13:52:32 -0700
To: [e-mail]
From: Warwick Ford <[e-mail]>
Subject: Schema Straw Poll Closure
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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 [phone] x225; Fax [phone]
[e-mail];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11380 for ietf-pkix-bks; Tue, 15 Sep 1998 08:56:25 -0700 (PDT)
Received: from firewall.globeset.com ([e-mail] [207.239.133.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11376 for <[e-mail]>; Tue, 15 Sep 1998 08:56:24 -0700 (PDT)
Received: from drought.globeset.com ([e-mail] [10.1.192.39]) by firewall.globeset.com (8.9.0/8.9.0) with ESMTP id LAA26296 for <[e-mail]>; Tue, 15 Sep 1998 11:02:08 -0500 (CDT)
Received: (from trevor@localhost) by drought.globeset.com (8.7.6/8.7.3) id LAA27450; Tue, 15 Sep 1998 11:02:03 -0500
From: Trevor Sosebee <[e-mail]>
Date: Tue, 15 Sep 1998 11:02:01 -0500 (CDT)
To: [e-mail]
Subject: UTF8String definition in PKIX-3
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13822.36613.678919.467432@drought>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA14487 for ietf-pkix-bks; Mon, 14 Sep 1998 21:23:34 -0700 (PDT)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA14482; Mon, 14 Sep 1998 21:23:30 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id OAA08287; Tue, 15 Sep 1998 14:29:04 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: Paul Hoffman / IMC <[e-mail]>
cc: [e-mail]
Subject: Re: Testing the ASN.1 in Part 1 
In-reply-to: Your message of "Mon, 14 Sep 1998 08:36:12 MST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 15 Sep 1998 14:29:01 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>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: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09835 for ietf-pkix-bks; Mon, 14 Sep 1998 10:17:45 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09830; Mon, 14 Sep 1998 10:17:43 -0700 (PDT)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA43924; Mon, 14 Sep 1998 10:19:03 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 14 Sep 1998 10:18:56 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA10684; Mon, 14 Sep 1998 10:18:55 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) 
Date: Mon, 14 Sep 1998 10:18:54 -0700
Subject: Re: Testing the ASN.1 in Part 1
From: "Aram Perez" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09714 for ietf-pkix-bks; Mon, 14 Sep 1998 10:03:42 -0700 (PDT)
Received: from atlantic.valicert.com ([e-mail] [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA09709 for <[e-mail]>; Mon, 14 Sep 1998 10:03:41 -0700 (PDT)
Received: (qmail 6298 invoked from network); 14 Sep 1998 17:09:19 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 14 Sep 1998 17:09:19 -0000
Message-ID: <[e-mail]>
Date: Mon, 14 Sep 1998 10:09:39 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Andreas Berger <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: OCSP ASN.1 comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08894 for ietf-pkix-bks; Mon, 14 Sep 1998 08:30:53 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA08890 for <[e-mail]>; Mon, 14 Sep 1998 08:30:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 14 Sep 1998 08:36:12 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Testing the ASN.1 in Part 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA07863 for ietf-pkix-bks; Mon, 14 Sep 1998 05:56:23 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA07859 for <[e-mail]>; Mon, 14 Sep 1998 05:56:15 -0700 (PDT)
Received: from darmstadt.gmd.de (aberger@pc-turin [141.12.33.71]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA27331 for <[e-mail]>; Mon, 14 Sep 1998 15:01:21 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 14 Sep 1998 15:01:43 +0200
From: Andreas Berger <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: OCSP ASN.1 comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA06297 for ietf-pkix-bks; Sat, 12 Sep 1998 15:22:49 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06293 for <[e-mail]>; Sat, 12 Sep 1998 15:22:48 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id AAA01228; Sun, 13 Sep 1998 00:28:21 +0200 (CEST)
Received: from stefans (t1o68p15.telia.com [62.20.138.15]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA03222; Sun, 13 Sep 1998 00:28:10 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 13 Sep 1998 00:25:48 +0200
To: Mike Smith <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA06294
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 8:44 AM >>>
>******************  InterScan Message (on zbc2)
>
>noname is scanned and no virus found
>*********************************************************
>












    !
>!
>


                                                           
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06115 for ietf-pkix-bks; Sat, 12 Sep 1998 14:23:54 -0700 (PDT)
Received: from mail.spyrus.com.au (fwuser@[203.37.128.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06111 for <[e-mail]>; Sat, 12 Sep 1998 14:23:47 -0700 (PDT)
Message-ID: <A1019E9C2D34D211A501006008C2045001BF66@MAIL>
From: Charles Moore <[e-mail]>
To: "'Peter Lipp'" <[e-mail]>, Paul Koning <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Sun, 13 Sep 1998 07:31:56 +1000
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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: [phone], Extension 101




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA23955 for ietf-pkix-bks; Fri, 11 Sep 1998 12:52:46 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (archimedes.iaik.tu-graz.ac.at [129.27.234.31]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA23951 for <[e-mail]>; Fri, 11 Sep 1998 12:52:44 -0700 (PDT)
Received: from plipp [129.27.239.102] by iaik.tu-graz.ac.at (SMTPD32-4.06) id A0D22800C6; Fri, 11 Sep 1998 21:58:10 +03d00
From: "Peter Lipp" <[e-mail]>
To: "Paul Koning" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Fri, 11 Sep 1998 21:59:08 +0200
Message-ID: <000001bdddbe$a311f630$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23179 for ietf-pkix-bks; Fri, 11 Sep 1998 11:32:59 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA23175 for <[e-mail]>; Fri, 11 Sep 1998 11:32:58 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 12:33:29 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 12:33:22 -0600
From: Mike Smith <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 12:07 PM >>>
>>>>> "Mike" == Mike Smith <[e-mail]> 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
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22902 for ietf-pkix-bks; Fri, 11 Sep 1998 11:03:49 -0700 (PDT)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22898 for <[e-mail]>; Fri, 11 Sep 1998 11:03:48 -0700 (PDT)
Received: from xedia.com by relay3.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgke24932; Fri, 11 Sep 1998 14:07:44 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26501; Fri, 11 Sep 98 14:06:53 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA28256; Fri, 11 Sep 1998 14:07:42 -0400
Date: Fri, 11 Sep 1998 14:07:42 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Mike" == Mike Smith <[e-mail]> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22010 for ietf-pkix-bks; Fri, 11 Sep 1998 09:16:19 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22006 for <[e-mail]>; Fri, 11 Sep 1998 09:16:18 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 10:16:48 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 10:16:37 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21953 for ietf-pkix-bks; Fri, 11 Sep 1998 09:10:26 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA21948 for <[e-mail]>; Fri, 11 Sep 1998 09:10:25 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 10:11:17 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 10:11:04 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21226 for ietf-pkix-bks; Fri, 11 Sep 1998 08:01:51 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21222 for <[e-mail]>; Fri, 11 Sep 1998 08:01:49 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id LAA27778; Fri, 11 Sep 1998 11:05:58 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 11 Sep 1998 11:06:33 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: [e-mail]
CC: Santosh Chokhani <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > > Sent: Wednesday, September 09, 1998 8:44 PM
> > > To:   Santosh Chokhani
> > > Cc:   'Sharon Boeyen'; '[e-mail]'
> > > 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:[e-mail]]
> > > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > > To:   '[e-mail]'; 'Santosh Chokhani'
> > > > > Subject:      RE: forward & reverse elements - population
> > > > >
> > > > >
> > > > >
> > > > > > ----------
> > > > > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > > > > Sent:       September 8, 1998 10:05 AM
> > > > > > To:         'Sharon Boeyen'; '[e-mail]'
> > > > > > 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:[e-mail]
> > >       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:[e-mail]
>       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. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21102 for ietf-pkix-bks; Fri, 11 Sep 1998 07:41:23 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21098 for <[e-mail]>; Fri, 11 Sep 1998 07:41:22 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id QAA00126 for <[e-mail]>; Fri, 11 Sep 1998 16:46:47 +0200 (MET DST)
Received: from stefans (t2o68p33.telia.com [62.20.138.153]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA11065 for <[e-mail]>; Fri, 11 Sep 1998 16:46:46 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 11 Sep 1998 16:44:21 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA21099
Sender: [e-mail]
Precedence: bulk

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
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16901 for ietf-pkix-bks; Fri, 11 Sep 1998 02:16:50 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16896 for <[e-mail]>; Fri, 11 Sep 1998 02:16:46 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA13435; Fri, 11 Sep 1998 11:23:50 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id LAA15724; Fri, 11 Sep 1998 11:23:51 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 11 Sep 1998 11:23:10 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > Sent: Wednesday, September 09, 1998 8:44 PM
> > To:   Santosh Chokhani
> > Cc:   'Sharon Boeyen'; '[e-mail]'
> > 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:[e-mail]]
> > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > To:   '[e-mail]'; 'Santosh Chokhani'
> > > > Subject:      RE: forward & reverse elements - population
> > > >
> > > >
> > > >
> > > > > ----------
> > > > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > > > Sent:       September 8, 1998 10:05 AM
> > > > > To:         'Sharon Boeyen'; '[e-mail]'
> > > > > 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:[e-mail]
> >       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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA15497 for ietf-pkix-bks; Fri, 11 Sep 1998 00:54:12 -0700 (PDT)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA15489 for <[e-mail]>; Fri, 11 Sep 1998 00:54:09 -0700 (PDT)
Message-Id: <[e-mail]>
Received: forwarded by SMTP 3.0.6.
From: Graham Bland <[e-mail]>
Date: Fri, 11 Sep 1998 8:49:49 +0000
To: [e-mail]
Subject: RE: RE: New Extension Proposed: Method O
MIME-version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA15493
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
> Sent: 10 September 1998 18:06
> To: Ian Roberts; Graham Bland; Chris Wright; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> 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 <[e-mail]> 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:[e-mail]]
> > Sent: Wednesday, September 09, 1998 3:12 PM
> > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> > [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > >> Sent: Wednesday, September 09, 1998 1:16 PM
> > >> To: Mike Smith; [e-mail]; [e-mail]
> > >> Cc: [e-mail]
> > >> 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: [e-mail]   phone: [phone]             LLLLLLLL
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: [phone]
Website:  http://www.zergo.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA24782 for ietf-pkix-bks; Thu, 10 Sep 1998 12:16:00 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA24777 for <[e-mail]>; Thu, 10 Sep 1998 12:15:55 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA27185 for <[e-mail]>; Thu, 10 Sep 1998 15:21:19 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA27171 for <[e-mail]>; Thu, 10 Sep 1998 15:21:17 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA00818 for <[e-mail]>; Thu, 10 Sep 1998 15:20:38 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 10 Sep 1998 15:21:10 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Thu, 10 Sep 1998 15:21:09 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Mike Smith'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 15:21:09 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Thursday, September 10, 1998 1:48 PM
>To: 	Mike Smith; [e-mail]; [e-mail]; [e-mail];
>[e-mail]
>Cc: 	[e-mail]
>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
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24098 for ietf-pkix-bks; Thu, 10 Sep 1998 10:43:18 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24094 for <[e-mail]>; Thu, 10 Sep 1998 10:43:17 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA16666; Thu, 10 Sep 1998 10:46:17 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA12380; Thu, 10 Sep 1998 10:48:02 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 13:48:20 -0400
Message-ID: <002001bddce3$3318eb80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23067 for ietf-pkix-bks; Thu, 10 Sep 1998 08:58:52 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23063 for <[e-mail]>; Thu, 10 Sep 1998 08:58:51 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Thu, 10 Sep 1998 09:59:31 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 10 Sep 1998 09:59:21 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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:[e-mail]] 
> Sent: Wednesday, September 09, 1998 3:12 PM
> To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [e-mail]; [e-mail] 
> Cc: [e-mail] 
> 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:[e-mail]] 
> >> Sent: Wednesday, September 09, 1998 1:16 PM
> >> To: Mike Smith; [e-mail]; [e-mail] 
> >> Cc: [e-mail] 
> >> 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: [e-mail]   phone: [phone]             LLLLLLLL
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22915 for ietf-pkix-bks; Thu, 10 Sep 1998 08:43:51 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22911 for <[e-mail]>; Thu, 10 Sep 1998 08:43:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 10 Sep 1998 08:49:00 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
>Date: Thu, 10 Sep 1998 10:34:19 -0400
>Sender: [e-mail]
>
>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 [e-mail]
>          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:	[e-mail].  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:	<[e-mail]>
>
>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>
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22538 for ietf-pkix-bks; Thu, 10 Sep 1998 08:14:28 -0700 (PDT)
Received: from slack.lne.com ([e-mail] [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22534 for <[e-mail]>; Thu, 10 Sep 1998 08:14:26 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id IAA12666; Thu, 10 Sep 1998 08:19:50 -0700
From: Eric Murray <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [e-mail] (Paul Koning)
Date: Thu, 10 Sep 1998 08:19:49 -0700 (PDT)
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]> from "Paul Koning" at Sep 10, 98 09:21:30 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21461 for ietf-pkix-bks; Thu, 10 Sep 1998 06:17:21 -0700 (PDT)
Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21457 for <[e-mail]>; Thu, 10 Sep 1998 06:17:20 -0700 (PDT)
Received: from xedia.com by relay5.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgft03924; Thu, 10 Sep 1998 09:21:34 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09439; Thu, 10 Sep 98 09:20:42 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA14290; Thu, 10 Sep 1998 09:21:30 -0400
Date: Thu, 10 Sep 1998 09:21:30 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <000701bddc29$99814e40$[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Tony" == Tony Bartoletti <[e-mail]> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21325 for ietf-pkix-bks; Thu, 10 Sep 1998 06:02:10 -0700 (PDT)
Received: from getafix.fcpl.co.in (Getafix.fcpl.co.in [196.1.104.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21320 for <[e-mail]>; Thu, 10 Sep 1998 06:02:03 -0700 (PDT)
Received: from TinTins.fcpl.co.in ([196.1.104.84]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA135 for <[e-mail]>; Thu, 10 Sep 1998 18:38:00 +0530
Message-ID: <000b01bddcbc$29a0ac40$[e-mail]>
From: "Shailesh" <[e-mail]>
To: <[e-mail]>
Subject: PKIX transports using HTTP
Date: Thu, 10 Sep 1998 18:38:54 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21056 for ietf-pkix-bks; Thu, 10 Sep 1998 05:47:22 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21051 for <[e-mail]>; Thu, 10 Sep 1998 05:47:17 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id OAA01964; Thu, 10 Sep 1998 14:54:13 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id OAA19716; Thu, 10 Sep 1998 14:54:06 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 10 Sep 1998 14:53:26 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Eric Murray <[e-mail]>
CC: [e-mail]
Subject: Re: New Extension Proposed: Method Of Authentication
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20901 for ietf-pkix-bks; Thu, 10 Sep 1998 05:19:37 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20897 for <[e-mail]>; Thu, 10 Sep 1998 05:19:34 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id OAA22350; Thu, 10 Sep 1998 14:26:25 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id OAA19816; Thu, 10 Sep 1998 14:26:20 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 10 Sep 1998 14:25:40 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Mike Smith <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: New Extension Proposed: Method Of Authentication
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20886 for ietf-pkix-bks; Thu, 10 Sep 1998 05:16:33 -0700 (PDT)
Received: from getafix.fcpl.co.in (Getafix.fcpl.co.in [196.1.104.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20879 for <[e-mail]>; Thu, 10 Sep 1998 05:16:12 -0700 (PDT)
Received: from dynamo ([196.1.104.100]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA142 for <[e-mail]>; Thu, 10 Sep 1998 17:52:05 +0530
Message-ID: <002b01bddcb6$078be850$[e-mail]>
From: "Abhay Kulkarni" <[e-mail]>
To: <[e-mail]>
Subject: PKIX Certificate Management Protocols
Date: Thu, 10 Sep 1998 17:54:53 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BDDCE4.1D99E100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2110.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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:  [e-mail]
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:[e-mail]">[e-mail]</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--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20830 for ietf-pkix-bks; Thu, 10 Sep 1998 05:10:30 -0700 (PDT)
Received: from gatekeeper.domus.com ([198.166.58.193]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20826 for <[e-mail]>; Thu, 10 Sep 1998 05:10:28 -0700 (PDT)
Received: from dns_int.domus.com by gatekeeper1.domus.com (8.6.13/200.19.1.1) id IAA27690; Thu, 10 Sep 1998 08:07:14 -0400
Received: (from smap@localhost) by dns_int.domus.com (8.6.8/8.6.6) id HAA24702 for <[e-mail]>; Thu, 10 Sep 1998 07:35:30 -0400
Received: from wpgate.domus.com(198.166.59.10) by dns_int.domus.com via smap (V1.3) id sma024700; Thu Sep 10 07:35:22 1998
Received: from DOMUS-Message_Server by wpgate.domus.com with Novell_GroupWise; Thu, 10 Sep 1998 08:07:25 -0400
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 10 Sep 1998 08:07:16 -0400
From: William Dziadyk <[e-mail]>
To: [e-mail]
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

      
---------------------------------------------------------------------------------
   William Dziadyk, PEng
   IT Security Services, DOMUS Software, Ottawa, Ontario, Canada 
   [phone]  ext 342  ----   [e-mail] 
 ---------------------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12866 for ietf-pkix-bks; Wed, 9 Sep 1998 23:54:28 -0700 (PDT)
Received: from genius.tisl.soft.net (genius.tisl.soft.net [164.164.20.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA12861; Wed, 9 Sep 1998 23:54:22 -0700 (PDT)
Received: from narayan ([32.97.253.98]) by genius.tisl.soft.net (AIX4.3/UCB 8.7/8.7) with ESMTP id MAA20198; Thu, 10 Sep 1998 12:25:52 -0530 (ist)
Message-ID: <[e-mail]>
Date: Thu, 10 Sep 1998 12:27:57 +0530
From: Narayan Raghu <[e-mail]>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail]
Subject: Re: New Extension Proposed: Method Of Authentication
X-Priority: 3 (Normal)
References: <000701bddc29$99814e40$[e-mail]> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27613 for ietf-pkix-bks; Wed, 9 Sep 1998 16:56:28 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27609 for <[e-mail]>; Wed, 9 Sep 1998 16:56:27 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ879>; Wed, 9 Sep 1998 20:00:03 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A6C@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Santosh Chokhani <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail], Eric Murray <[e-mail]>
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 20:00:00 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 7:20 PM
> To:	Phillip M Hallam-Baker; Santosh Chokhani; Mike Smith;
> [e-mail]; [e-mail]; Eric Murray
> Cc:	[e-mail]
> 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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27585 for ietf-pkix-bks; Wed, 9 Sep 1998 16:53:54 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA27581 for <[e-mail]>; Wed, 9 Sep 1998 16:53:53 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 09 Sep 1998 16:58:57 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
In-Reply-To: <[e-mail]>
References: <000701bddc29$99814e40$[e-mail]> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27403 for ietf-pkix-bks; Wed, 9 Sep 1998 16:16:15 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27399 for <[e-mail]>; Wed, 9 Sep 1998 16:16:14 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id QAA10253; Wed, 9 Sep 1998 16:21:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 09 Sep 1998 16:20:25 -0700
To: "Phillip M Hallam-Baker" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>, Eric Murray <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: <[e-mail]>
In-Reply-To: <000701bddc29$99814e40$[e-mail]>
References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26368 for ietf-pkix-bks; Wed, 9 Sep 1998 14:15:07 -0700 (PDT)
Received: from relay1.eds.com (relay1.eds.com [199.228.142.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26364 for <[e-mail]>; Wed, 9 Sep 1998 14:15:05 -0700 (PDT)
Received: from nnsa.eds.com (nnsa.eds.com [192.85.154.30] (may be forged)) by relay1.eds.com (8.8.8/8.8.8) with ESMTP id RAA03200 for <[e-mail]>; Wed, 9 Sep 1998 17:20:25 -0400 (EDT)
Received: from usahm007.exmi01.exch.eds.com ([207.37.138.147]) by nnsa.eds.com (8.8.8/8.8.8) with ESMTP id RAA10704 for <[e-mail]>; Wed, 9 Sep 1998 17:19:54 -0400 (EDT)
Received: by USAHM007 with Internet Mail Service (5.5.2232.9) id <S1N8LKJ3>; Wed, 9 Sep 1998 17:19:50 -0400
Message-ID: <92D60A12331ED2119F5300A02461F047B20386@USAHM009>
From: "Corcoran, Dan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 9 Sep 1998 17:19:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25592 for ietf-pkix-bks; Wed, 9 Sep 1998 12:38:45 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25588 for <[e-mail]>; Wed, 9 Sep 1998 12:38:32 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA20000 for <[e-mail]>; Wed, 9 Sep 1998 15:43:40 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA19994 for <[e-mail]>; Wed, 9 Sep 1998 15:43:39 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA09823 for <[e-mail]>; Wed, 9 Sep 1998 15:42:59 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 09 Sep 1998 15:43:23 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Wed, 9 Sep 1998 15:44:33 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, "'Mike Smith'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:44:32 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Wednesday, September 09, 1998 3:12 PM
>To: 	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
>[e-mail]; [e-mail]
>Cc: 	[e-mail]
>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:[e-mail]]
>>> Sent:	Wednesday, September 09, 1998 1:16 PM
>>> To:	Mike Smith; [e-mail]; [e-mail]
>>> Cc:	[e-mail]
>>> 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: [e-mail]   phone: [phone]             LLLLLLLL
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25538 for ietf-pkix-bks; Wed, 9 Sep 1998 12:34:48 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25534 for <[e-mail]>; Wed, 9 Sep 1998 12:34:47 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id MAA29427; Wed, 9 Sep 1998 12:37:44 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA16381; Wed, 9 Sep 1998 12:39:30 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:39:46 -0400
Message-ID: <000701bddc29$99814e40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Sender: [e-mail]
Precedence: bulk

> 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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25446 for ietf-pkix-bks; Wed, 9 Sep 1998 12:20:41 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25442 for <[e-mail]>; Wed, 9 Sep 1998 12:20:40 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ8LG>; Wed, 9 Sep 1998 15:25:49 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A67@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:25:47 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 3:12 PM
> To:	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> [e-mail]; [e-mail]
> Cc:	[e-mail]
> 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:[e-mail]]
> >> Sent:	Wednesday, September 09, 1998 1:16 PM
> >> To:	Mike Smith; [e-mail]; [e-mail]
> >> Cc:	[e-mail]
> >> 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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25432 for ietf-pkix-bks; Wed, 9 Sep 1998 12:19:09 -0700 (PDT)
Received: from slack.lne.com ([e-mail] [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25428 for <[e-mail]>; Wed, 9 Sep 1998 12:19:07 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id MAA11040; Wed, 9 Sep 1998 12:24:19 -0700
From: Eric Murray <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: New Extension Proposed: Method Of Authentication
To: [e-mail] (Santosh Chokhani)
Date: Wed, 9 Sep 1998 12:24:18 -0700 (PDT)
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> from "Santosh Chokhani" at Sep 9, 98 01:44:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25299 for ietf-pkix-bks; Wed, 9 Sep 1998 12:07:59 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25295 for <[e-mail]>; Wed, 9 Sep 1998 12:07:58 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id MAA14051; Wed, 9 Sep 1998 12:13:05 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 09 Sep 1998 12:12:19 -0700
To: Santosh Chokhani <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Wednesday, September 09, 1998 1:16 PM
>> To:	Mike Smith; [e-mail]; [e-mail]
>> Cc:	[e-mail]
>> 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: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25087 for ietf-pkix-bks; Wed, 9 Sep 1998 11:49:37 -0700 (PDT)
Received: from relay1.eds.com (relay1.eds.com [199.228.142.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25082 for <[e-mail]>; Wed, 9 Sep 1998 11:49:36 -0700 (PDT)
From: [e-mail]
Received: from nnsa.eds.com (nnsa.eds.com [192.85.154.30] (may be forged)) by relay1.eds.com (8.8.8/8.8.8) with ESMTP id OAA19121 for <[e-mail]>; Wed, 9 Sep 1998 14:54:51 -0400 (EDT)
Received: from usabhmg01.mail.gm.com ([207.37.138.86]) by nnsa.eds.com (8.8.8/8.8.8) with SMTP id OAA04446 for <[e-mail]>; Wed, 9 Sep 1998 14:54:20 -0400 (EDT)
Received: by usabhmg01.mail.gm.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 0525667A.006D0EAA ; Wed, 9 Sep 1998 14:51:11 -0500
X-Lotus-FromDomain: GM
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 14:51:15 -0500
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

For Option 2




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24576 for ietf-pkix-bks; Wed, 9 Sep 1998 10:59:45 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24572 for <[e-mail]>; Wed, 9 Sep 1998 10:59:44 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ8JL>; Wed, 9 Sep 1998 14:04:53 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A65@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Kurn, David'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 14:04:50 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 1:51 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 10:32 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> '[e-mail]'
> > 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>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24448 for ietf-pkix-bks; Wed, 9 Sep 1998 10:45:42 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24444 for <[e-mail]>; Wed, 9 Sep 1998 10:45:41 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA01170; Wed, 9 Sep 1998 10:50:49 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M2FMK>; Wed, 9 Sep 1998 10:50:45 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:50:42 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 10:32 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; '[e-mail]'
> 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>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24302 for ietf-pkix-bks; Wed, 9 Sep 1998 10:39:26 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24298 for <[e-mail]>; Wed, 9 Sep 1998 10:39:24 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ820>; Wed, 9 Sep 1998 13:44:33 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Phillip M Hallam-Baker'" <[e-mail]>, Mike Smith <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:44:32 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 1:16 PM
> To:	Mike Smith; [e-mail]; [e-mail]
> Cc:	[e-mail]
> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24200 for ietf-pkix-bks; Wed, 9 Sep 1998 10:27:25 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24196 for <[e-mail]>; Wed, 9 Sep 1998 10:27:22 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ82Z>; Wed, 9 Sep 1998 13:32:31 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A62@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Kurn, David'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 13:32:28 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 1:12 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 9:53 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> '[e-mail]'
> > 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:[e-mail]]
> > > Sent:	Wednesday, September 09, 1998 12:16 PM
> > > To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> > > 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:[e-mail]]
> > > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > > To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > > To:	'[e-mail]'; '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:[e-mail]]
> > > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > ----------
> > > > > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > > > > 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.
> > > > > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23916 for ietf-pkix-bks; Wed, 9 Sep 1998 10:11:15 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23912 for <[e-mail]>; Wed, 9 Sep 1998 10:11:01 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA26409; Wed, 9 Sep 1998 10:13:52 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA05799; Wed, 9 Sep 1998 10:15:38 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:15:46 -0400
Message-ID: <001f01bddc15$7bf63980$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23875 for ietf-pkix-bks; Wed, 9 Sep 1998 10:07:22 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23871 for <[e-mail]>; Wed, 9 Sep 1998 10:07:21 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA25223; Wed, 9 Sep 1998 10:12:27 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M21Q3>; Wed, 9 Sep 1998 10:12:23 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 10:12:22 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 9:53 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 12:16 PM
> > To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> > 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:[e-mail]]
> > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > To:	'[e-mail]'; '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:[e-mail]]
> > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > ----------
> > > > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > > > 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.
> > > > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23614 for ietf-pkix-bks; Wed, 9 Sep 1998 09:48:09 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23601 for <[e-mail]>; Wed, 9 Sep 1998 09:48:05 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ81N>; Wed, 9 Sep 1998 12:53:13 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A61@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Kurn, David'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:53:12 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 12:16 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 8:27 AM
> > To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > To:	'[e-mail]'; '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:[e-mail]]
> > > > Sent: 	September 9, 1998 9:08 AM
> > > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > > Subject:	RE: forward & reverse elements - population
> > > > > 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > > 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.
> > > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23427 for ietf-pkix-bks; Wed, 9 Sep 1998 09:34:54 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23423 for <[e-mail]>; Wed, 9 Sep 1998 09:34:53 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Wed, 9 Sep 1998 17:38:36 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 09 Sep 1998 17:38:35 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23385 for ietf-pkix-bks; Wed, 9 Sep 1998 09:31:49 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23381 for <[e-mail]>; Wed, 9 Sep 1998 09:31:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 09 Sep 1998 09:36:53 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: New Extension Proposed: Method Of Authentication
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23254 for ietf-pkix-bks; Wed, 9 Sep 1998 09:18:59 -0700 (PDT)
Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23250 for <[e-mail]>; Wed, 9 Sep 1998 09:18:58 -0700 (PDT)
From: [e-mail]
Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id MAA10130 for <[e-mail]>; Wed, 9 Sep 1998 12:23:46 -0400 (EDT)
Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id MAA21732 for <[e-mail]>; Wed, 9 Sep 1998 12:23:44 -0400 (EDT)
Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 8525667A.005A117D ; Wed, 9 Sep 1998 12:23:47 -0400
X-Lotus-FromDomain: HWC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 12:23:30 -0400
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Alan Buffett
09/09/98 12:23 PM





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23155 for ietf-pkix-bks; Wed, 9 Sep 1998 09:10:39 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23151 for <[e-mail]>; Wed, 9 Sep 1998 09:10:38 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA17200; Wed, 9 Sep 1998 09:15:41 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M2DH3>; Wed, 9 Sep 1998 09:15:37 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:15:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 8:27 AM
> To:	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > Sent:	Wednesday, September 09, 1998 11:02 AM
> > To:	'[e-mail]'; '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:[e-mail]]
> > > Sent: 	September 9, 1998 9:08 AM
> > > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > > 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.
> > > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23089 for ietf-pkix-bks; Wed, 9 Sep 1998 09:03:17 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23085 for <[e-mail]>; Wed, 9 Sep 1998 09:03:16 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 09 Sep 1998 10:03:43 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 09 Sep 1998 10:03:36 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23032 for ietf-pkix-bks; Wed, 9 Sep 1998 09:00:26 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23028 for <[e-mail]>; Wed, 9 Sep 1998 09:00:24 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ75P>; Wed, 9 Sep 1998 12:05:31 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 12:05:30 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 8:44 PM
> To:	Santosh Chokhani
> Cc:	'Sharon Boeyen'; '[e-mail]'
> 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:[e-mail]]
> > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > To:   '[e-mail]'; 'Santosh Chokhani'
> > > Subject:      RE: forward & reverse elements - population
> > >
> > >
> > >
> > > > ----------
> > > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > > Sent:       September 8, 1998 10:05 AM
> > > > To:         'Sharon Boeyen'; '[e-mail]'
> > > > 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:[e-mail]
>       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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22846 for ietf-pkix-bks; Wed, 9 Sep 1998 08:41:31 -0700 (PDT)
Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22842 for <[e-mail]>; Wed, 9 Sep 1998 08:41:28 -0700 (PDT)
From: [e-mail]
Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id LAA05879 for <[e-mail]>; Wed, 9 Sep 1998 11:46:15 -0400 (EDT)
Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id LAA17566 for <[e-mail]>; Wed, 9 Sep 1998 11:46:13 -0400 (EDT)
Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 8525667A.0056A364 ; Wed, 9 Sep 1998 11:46:19 -0400
X-Lotus-FromDomain: HWC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 11:46:08 -0400
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

09/09/98 11:46 AM
Ross Smith
Ross Smith
Ross Smith
09/09/98 11:46 AM
09/09/98 11:46 AM





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22806 for ietf-pkix-bks; Wed, 9 Sep 1998 08:38:00 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22800 for <[e-mail]>; Wed, 9 Sep 1998 08:37:57 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id RAA29000; Wed, 9 Sep 1998 17:44:48 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id RAA21158; Wed, 9 Sep 1998 17:44:51 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 09 Sep 1998 17:44:12 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A5C@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > Sent: Tuesday, September 08, 1998 5:46 PM
> > To:   '[e-mail]'; 'Santosh Chokhani'
> > Subject:      RE: forward & reverse elements - population
> >
> >
> >
> > > ----------
> > > From:       Santosh Chokhani[SMTP:[e-mail]]
> > > Sent:       September 8, 1998 10:05 AM
> > > To:         'Sharon Boeyen'; '[e-mail]'
> > > 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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22663 for ietf-pkix-bks; Wed, 9 Sep 1998 08:21:38 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22659 for <[e-mail]>; Wed, 9 Sep 1998 08:21:36 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ7VA>; Wed, 9 Sep 1998 11:26:44 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A5F@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:26:42 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 09, 1998 11:02 AM
> To:	'[e-mail]'; '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:[e-mail]]
> > Sent: 	September 9, 1998 9:08 AM
> > To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > To:	'[e-mail]'; 'Santosh Chokhani'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > 
> > > 
> > > > ----------
> > > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > > Sent: 	September 8, 1998 10:05 AM
> > > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > > 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.
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22485 for ietf-pkix-bks; Wed, 9 Sep 1998 08:01:33 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22479 for <[e-mail]>; Wed, 9 Sep 1998 08:01:31 -0700 (PDT)
Received: 	id LAA08881; Wed, 9 Sep 1998 11:04:43 -0400
Received: by gateway id <S2S6XZC1>; Wed, 9 Sep 1998 11:01:41 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 11:01:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 9, 1998 9:08 AM
> To: 	'Sharon Boeyen'; '[e-mail]'; 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:[e-mail]]
> > Sent:	Tuesday, September 08, 1998 5:46 PM
> > To:	'[e-mail]'; 'Santosh Chokhani'
> > Subject:	RE: forward & reverse elements - population
> > 
> > 
> > 
> > > ----------
> > > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > > Sent: 	September 8, 1998 10:05 AM
> > > To: 	'Sharon Boeyen'; '[e-mail]'
> > > 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.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21587 for ietf-pkix-bks; Wed, 9 Sep 1998 06:34:38 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21583 for <[e-mail]>; Wed, 9 Sep 1998 06:34:36 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id PAA17200 for <[e-mail]>; Wed, 9 Sep 1998 15:41:24 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id PAA20994 for <[e-mail]>; Wed, 9 Sep 1998 15:41:28 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 09 Sep 1998 15:40:49 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: For Option none
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21260 for ietf-pkix-bks; Wed, 9 Sep 1998 06:03:20 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21256 for <[e-mail]>; Wed, 9 Sep 1998 06:03:19 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ7R4>; Wed, 9 Sep 1998 09:08:26 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A5C@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Wed, 9 Sep 1998 09:08:23 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Tuesday, September 08, 1998 5:46 PM
> To:	'[e-mail]'; 'Santosh Chokhani'
> Subject:	RE: forward & reverse elements - population
> 
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > Sent: 	September 8, 1998 10:05 AM
> > To: 	'Sharon Boeyen'; '[e-mail]'
> > 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18469 for ietf-pkix-bks; Wed, 9 Sep 1998 02:18:24 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18465 for <[e-mail]>; Wed, 9 Sep 1998 02:18:12 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFPT>; Wed, 9 Sep 1998 19:22:05 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC073861@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Mike Smith '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Phillip M Hallam-Baker '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OFF TOPIC ???? RE: Relational vs Directory Repository Models  (was RE: pathdevelopment complexity s)
Date: Wed, 9 Sep 1998 19:22:02 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thanks for the reply - comments in line. 

----------
From: Phillip M Hallam-Baker
To: Mike Smith; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02151 for ietf-pkix-bks; Tue, 8 Sep 1998 22:11:59 -0700 (PDT)
Received: from atlantic.valicert.com ([e-mail] [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA02147 for <[e-mail]>; Tue, 8 Sep 1998 22:11:57 -0700 (PDT)
Received: (qmail 8338 invoked from network); 9 Sep 1998 05:17:13 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 9 Sep 1998 05:17:13 -0000
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 22:17:20 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Posnak <[e-mail]>
CC: IETF PKIX <[e-mail]>
Subject: Re: OCSP in Chicago
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29394 for ietf-pkix-bks; Tue, 8 Sep 1998 20:42:56 -0700 (PDT)
Received: from 2gn.com (insectivora.unids.com [208.196.212.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29390 for <[e-mail]>; Tue, 8 Sep 1998 20:42:55 -0700 (PDT)
Received: from rodney (perm16-180.ij.net [209.4.16.180]) by 2gn.com (8.8.5/8.8.5) with SMTP id WAA25675; Tue, 8 Sep 1998 22:45:09 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 08 Sep 1998 23:44:10 -0400
To: Pavel Krylov <[e-mail]>
From: Rodney Thayer <[e-mail]>
Subject: Re: depth
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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          [e-mail]
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28554 for ietf-pkix-bks; Tue, 8 Sep 1998 18:18:59 -0700 (PDT)
Received: from ns1.auntmimi.net ([209.19.106.141]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28550 for <[e-mail]>; Tue, 8 Sep 1998 18:18:58 -0700 (PDT)
Received: from mail.xetex.com (1Cust101.tnt2.sfo3.da.uu.net [153.37.7.101]) by ns1.auntmimi.net (8.8.6/8.7.3) with SMTP id TAA21059; Tue, 8 Sep 1998 19:55:22 -0700 (PDT)
Received: from xetex.com by mail.xetex.com (SMI-8.6/SMI-SVR4) id SAA08850; Tue, 8 Sep 1998 18:20:05 -0700
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 18:27:51 -0700
From: Ed Posnak <[e-mail]>
Organization: Xetex Corporation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: IETF PKIX <[e-mail]>
Subject: Re: OCSP in Chicago
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26952 for ietf-pkix-bks; Tue, 8 Sep 1998 15:01:14 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26948 for <[e-mail]>; Tue, 8 Sep 1998 15:01:13 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id PAA24508 for <[e-mail]>; Tue, 8 Sep 1998 15:05:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Tue, 08 Sep 1998 18:07:20 -0400
To: "'[e-mail]'" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: For Option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26881 for ietf-pkix-bks; Tue, 8 Sep 1998 14:57:32 -0700 (PDT)
Received: from atlantic.valicert.com (atlantic.valicert.com [209.185.6.135] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26871 for <[e-mail]>; Tue, 8 Sep 1998 14:57:31 -0700 (PDT)
Received: (qmail 1104 invoked from network); 8 Sep 1998 22:02:24 -0000
Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 8 Sep 1998 22:02:24 -0000
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 15:02:30 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF PKIX <[e-mail]>
Subject: OCSP in Chicago
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26782 for ietf-pkix-bks; Tue, 8 Sep 1998 14:46:42 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26778 for <[e-mail]>; Tue, 8 Sep 1998 14:46:40 -0700 (PDT)
Received: 	id RAA25638; Tue, 8 Sep 1998 17:49:05 -0400
Received: by gateway id <S2S6XV8N>; Tue, 8 Sep 1998 17:46:02 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 17:46:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 8, 1998 10:05 AM
> To: 	'Sharon Boeyen'; '[e-mail]'
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25829 for ietf-pkix-bks; Tue, 8 Sep 1998 13:02:56 -0700 (PDT)
Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA25825 for <[e-mail]>; Tue, 8 Sep 1998 13:02:55 -0700 (PDT)
Received: from mailext02.compaq.com by mailext02.compaq.com via smail with esmtp id <[e-mail]> for <[e-mail]>; Tue, 8 Sep 98 12:28:31 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.9 built 21-jan-98)
Received: from mail.compaq.com([207.18.199.32]) by mailext02.compaq.com with SMTP (peer mailint02.compaq.com[207.18.199.35]) id rcv009876; Tue, 8 Sep 1998 12:28:31 -0500 (CDT)
Received: from exchou-conn01.im.hou.compaq.com(really [172.18.22.253]) by mail.compaq.com via sendmail with esmtp id <[e-mail]> for <[e-mail]>; Tue, 8 Sep 98 12:28:04 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97)
Received: by EXCHOU-CONN01.im.hou.compaq.com with Internet Mail Service (5.5.1960.3) id <SQ38VL6L>; Tue, 8 Sep 1998 12:29:54 -0500
Message-ID: <[e-mail]>
From: "Fuerst, Neal" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FOR Option 2
Date: Tue, 8 Sep 1998 11:05:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thanks.

Neal Fuerst
Information Security Analyst
Compaq Computer Corporation
E-Mail: [e-mail]
Phone: [phone]
Pager: 713.509.4586

Entrust validation string: OMCO-KGMF-KQZN
"No matter how paranoid you are, you're not paranoid enough."



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25472 for ietf-pkix-bks; Tue, 8 Sep 1998 12:31:56 -0700 (PDT)
Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25468 for <[e-mail]>; Tue, 8 Sep 1998 12:31:55 -0700 (PDT)
Received: from napmsnoc02.shl.com (napmsnoc02.shl.com [159.249.47.179]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id OAA10756 for <[e-mail]>; Tue, 8 Sep 1998 14:21:38 -0500
Received: by napmsnoc02.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Tue, 8 Sep 1998 12:37:25 -0700
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'David Boyce'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population 
Date: Tue, 8 Sep 1998 12:37:04 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

in response to:
>From: 	David Boyce[SMTP:[e-mail]]
>"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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25463 for ietf-pkix-bks; Tue, 8 Sep 1998 12:31:26 -0700 (PDT)
Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25459 for <[e-mail]>; Tue, 8 Sep 1998 12:31:25 -0700 (PDT)
Received: from mrohub2.mro.dec.com (mrohub2.mro.dec.com [16.34.192.32]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with ESMTP id PAA00906 for <[e-mail]>; Tue, 8 Sep 1998 15:36:08 -0400 (EDT)
Received: by mrohub2.mro.dec.com with Internet Mail Service (5.5.1960.3) id <SQZT8L16>; Tue, 8 Sep 1998 15:36:09 -0400
Message-ID: <[e-mail]>
From: Daya Puls <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 15:36:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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: [phone], Eml: [e-mail]





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25403 for ietf-pkix-bks; Tue, 8 Sep 1998 12:22:07 -0700 (PDT)
Received: from 2keys.ca (cr318128-a.rchrd1.on.wave.home.com [24.112.92.155]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25399 for <[e-mail]>; Tue, 8 Sep 1998 12:22:06 -0700 (PDT)
From: [e-mail]
Received: (from rpierce@localhost) by 2keys.ca (8.8.7/8.8.7) id LAA16441 for [e-mail]; Tue, 8 Sep 1998 11:23:54 -0400
Message-Id: <[e-mail]>
Subject: For Option 2
To: [e-mail] (IETF PKIX)
Date: Tue, 8 Sep 1998 15:23:54 +0000 ()
Content-Type: text
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24057 for ietf-pkix-bks; Tue, 8 Sep 1998 10:11:58 -0700 (PDT)
Received: from lion.harrisbank.com (lion.harrisbank.com [204.148.73.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24053 for <[e-mail]>; Tue, 8 Sep 1998 10:11:54 -0700 (PDT)
From: [e-mail]
Received: by lion.harrisbank.com id AA24091 (SMTP Gateway 3.0 for [e-mail]); Tue, 8 Sep 1998 12:17:07 -0500
Received: by lion.harrisbank.com (Internal Mail Agent-1); Tue, 8 Sep 1998 12:17:07 -0500
To: ietf-pkiximcorg <[e-mail]>
Subject: For Option 2
Message-Id: <0056090002874024000002L942*@MHS>
Date: Tue, 8 Sep 1998 12:09:50 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23614 for ietf-pkix-bks; Tue, 8 Sep 1998 09:16:50 -0700 (PDT)
Received: from smtp-gw.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23610 for <[e-mail]>; Tue, 8 Sep 1998 09:16:49 -0700 (PDT)
Received: from mailhost.BayNetworks.COM ([141.251.211.49]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id MAA11637 for <[e-mail]>; Tue, 8 Sep 1998 12:21:27 -0400 (EDT)
Received: from ns2.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id SAA01073 for <[e-mail]>; Tue, 8 Sep 1998 18:20:50 +0200 (MET DST)
Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-nf0)  by ns2.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA00939; Tue, 8 Sep 98 12:20:50 EDT for [e-mail]
Received: from dgiglio.corpeast.baynetworks.com (bne-cnc-126.corpeast.baynetworks.com [132.245.134.126]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com for <[e-mail]>; Tue, 8 Sep 1998 12:20:46 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 08 Sep 1998 12:20:47 -0400
To: [e-mail]
From: [e-mail] (David Giglio)
Subject: For option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

___________________________________________________________________
David Giglio - Senior Product Manager 
Bay Networks, Inc.                Access Server Div.
M/S BL8-05                        [e-mail]
5 Federal Street                  978-916-4234 Office
Billerica, MA 01821               978-916-4782 Fax		

				


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23274 for ietf-pkix-bks; Tue, 8 Sep 1998 08:46:11 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23270 for <[e-mail]>; Tue, 8 Sep 1998 08:46:10 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA04410; Tue, 8 Sep 1998 08:49:02 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA13627; Tue, 8 Sep 1998 08:50:48 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Mike Smith" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Date: Tue, 8 Sep 1998 11:50:46 -0400
Message-ID: <004d01bddb40$7194a9c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk

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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23228 for ietf-pkix-bks; Tue, 8 Sep 1998 08:43:19 -0700 (PDT)
Received: from lion.harrisbank.com (lion.harrisbank.com [204.148.73.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23224 for <[e-mail]>; Tue, 8 Sep 1998 08:43:17 -0700 (PDT)
From: [e-mail]
Received: by lion.harrisbank.com id AA18645 (SMTP Gateway 3.0 for [e-mail]); Tue, 8 Sep 1998 10:48:27 -0500
Received: by lion.harrisbank.com (Internal Mail Agent-1); Tue, 8 Sep 1998 10:48:27 -0500
To: ietf-pkiximcorg <[e-mail]>
Subject: For Option 2
Message-Id: <0056090002871633000002L932*@MHS>
Date: Tue, 8 Sep 1998 10:41:10 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23117 for ietf-pkix-bks; Tue, 8 Sep 1998 08:34:16 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23113 for <[e-mail]>; Tue, 8 Sep 1998 08:34:14 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Tue, 8 Sep 1998 16:38:15 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: "PACHL, Jan" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: forward & reverse elements - population 
In-reply-to: Your message of "Tue, 08 Sep 1998 08:58:19 CDT." <c=US%a=MCI%p=SHL%l=[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Sep 1998 16:38:15 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk

"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:	[phone]		Richmond, Surrey, ENGLAND
I'net:	[e-mail]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23093 for ietf-pkix-bks; Tue, 8 Sep 1998 08:32:20 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23089 for <[e-mail]>; Tue, 8 Sep 1998 08:32:18 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Tue, 8 Sep 1998 16:36:44 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: Sharon Boeyen <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: forward & reverse elements - population 
In-reply-to: Your message of "Mon, 07 Sep 1998 20:01:30 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Sep 1998 16:36:43 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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:	[phone]		Richmond, Surrey, ENGLAND
I'net:	[e-mail]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22703 for ietf-pkix-bks; Tue, 8 Sep 1998 07:57:32 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22699 for <[e-mail]>; Tue, 8 Sep 1998 07:57:31 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04610; Tue, 8 Sep 1998 11:02:10 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-10.txt
Date: Tue, 08 Sep 1998 11:02:09 -0400
Sender: [e-mail]
Precedence: bulk

--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 [e-mail]
   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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22660 for ietf-pkix-bks; Tue, 8 Sep 1998 07:50:40 -0700 (PDT)
Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22656 for <[e-mail]>; Tue, 8 Sep 1998 07:50:38 -0700 (PDT)
From: [e-mail]
Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id KAA05514 for <[e-mail]>; Tue, 8 Sep 1998 10:55:00 -0400 (EDT)
Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id KAA11820 for <[e-mail]>; Tue, 8 Sep 1998 10:54:45 -0400 (EDT)
Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 85256679.0051E875 ; Tue, 8 Sep 1998 10:54:39 -0400
X-Lotus-FromDomain: HWC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 8 Sep 1998 10:55:28 -0400
Subject: For Option 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Jean Bernatchez
09/08/98 10:55 AM





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22068 for ietf-pkix-bks; Tue, 8 Sep 1998 07:00:36 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22063 for <[e-mail]>; Tue, 8 Sep 1998 07:00:32 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ5Q8>; Tue, 8 Sep 1998 10:05:31 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D248@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 10:05:30 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

comments in-line.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[e-mail]]
> Sent:	Monday, September 07, 1998 8:02 PM
> To:	'[e-mail]'
> 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:[e-mail]  Tel: [phone] 
> http://www.entrust.com            Fax: [phone] 
>        


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22025 for ietf-pkix-bks; Tue, 8 Sep 1998 06:55:51 -0700 (PDT)
Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22020 for <[e-mail]>; Tue, 8 Sep 1998 06:55:50 -0700 (PDT)
From: [e-mail]
Received: 	id JAA06138; Tue, 8 Sep 1998 09:57:04 -0400
Received: by gateway id <NWL91ZG3>; Tue, 8 Sep 1998 09:54:53 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Tue, 8 Sep 1998 10:03:01 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

To whom it may concern, 

For Option 2. 

Regards, 






J.P. Lachance 
Senior Systems Engineer 
PMO GOC PKI 
Communications Security Establishement 
Tel: [phone] 
Fax: [phone] 
Internet: [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22008 for ietf-pkix-bks; Tue, 8 Sep 1998 06:53:13 -0700 (PDT)
Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22004 for <[e-mail]>; Tue, 8 Sep 1998 06:53:11 -0700 (PDT)
Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id IAA57036 for <[e-mail]>; Tue, 8 Sep 1998 08:42:50 -0500
Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Tue, 8 Sep 1998 08:58:25 -0500
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>
Subject: RE: forward & reverse elements - population
Date: Tue, 8 Sep 1998 08:58:19 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>[ ... ]
>
>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?
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21745 for ietf-pkix-bks; Tue, 8 Sep 1998 06:07:58 -0700 (PDT)
Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA21741 for <[e-mail]>; Tue, 8 Sep 1998 06:07:57 -0700 (PDT)
From: [e-mail]
Received: 	id JAA05475; Tue, 8 Sep 1998 09:09:56 -0400
Received: by gateway id <NWL91ZFR>; Tue, 8 Sep 1998 09:07:45 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Tue, 8 Sep 1998 09:07:44 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21325 for ietf-pkix-bks; Tue, 8 Sep 1998 05:17:25 -0700 (PDT)
Received: from fin.gc.ca (cis-pec.fin.gc.ca [198.103.32.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21321 for <[e-mail]>; Tue, 8 Sep 1998 05:17:23 -0700 (PDT)
From: [e-mail]
Received: from connfax.fin.gc.ca ([172.17.22.10]) by sonic.fin.gc.ca with ESMTP id <19735>; Tue, 8 Sep 1998 08:20:39 -0400
Received: by CONNFAX with Internet Mail Service (5.5.1960.3) id <SQ2M0LBH>; Tue, 8 Sep 1998 08:22:19 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For option 2
Date: Mon, 7 Sep 1998 09:34:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20854 for ietf-pkix-bks; Tue, 8 Sep 1998 04:13:26 -0700 (PDT)
Received: from apollo.fedworld.gov (apollo.fedworld.gov [192.239.92.203]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20850 for <[e-mail]>; Tue, 8 Sep 1998 04:13:24 -0700 (PDT)
Received: from jdiduro.fedworld.gov ([208.232.200.69] (may be forged)) by apollo.fedworld.gov (8.8.6 (PHNE_14041)/8.8.6) with SMTP id HAA01052 for <[e-mail]>; Tue, 8 Sep 1998 07:17:43 -0400 (EDT)
Message-Id: <4.0.2.19980908072326.0443e530@192.239.92.203>
X-Sender: jdiduro@192.239.92.203
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 08 Sep 1998 07:23:34 -0400
To: [e-mail]
From: "John A. DiDuro" <[e-mail]>
Subject: for Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20761 for ietf-pkix-bks; Tue, 8 Sep 1998 04:07:11 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20755 for <[e-mail]>; Tue, 8 Sep 1998 04:07:09 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ537>; Tue, 8 Sep 1998 07:12:08 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E186603@WUHER>
From: Jeremy Bingham <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:12:07 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA08715 for ietf-pkix-bks; Tue, 8 Sep 1998 01:20:27 -0700 (PDT)
Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA08709 for <[e-mail]>; Tue, 8 Sep 1998 01:20:26 -0700 (PDT)
Received: from ben ([195.121.86.74]) by smtp03.wxs.nl (Netscape Messaging Server 3.54)  with SMTP id AAA16EA for <[e-mail]>; Tue, 8 Sep 1998 10:25:05 +0200
Message-ID: <[e-mail]>
Date: Tue, 08 Sep 1998 10:26:20 +0200
From: Ton van Lieshout <[e-mail]>
Reply-To: [e-mail]
Organization: Point Information Systems B.V.
X-Mailer: Mozilla 3.01C-WXS-16  (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: FOR OPTION 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

As an Entrust prtner, we vote for option 2.

Ton van Lieshout
Technical Director


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA29595 for ietf-pkix-bks; Mon, 7 Sep 1998 23:01:20 -0700 (PDT)
Received: from security.no ([193.71.64.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA29591 for <[e-mail]>; Mon, 7 Sep 1998 23:01:17 -0700 (PDT)
Received: by gateway.security.no id <26882>; Tue, 8 Sep 1998 07:01:48 +0100
Message-Id: <[e-mail]>
From: =?iso-8859-1?Q?Svein_L=F8seth?= <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 8 Sep 1998 07:05:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA29592
Sender: [e-mail]
Precedence: bulk

---------------------------------------------------------------------------------------------------------------------------
Svein Løseth						Tlf.:    [phone]
Network Security AS					Fax:    [phone]
Gaustadalléen 21				    Dir. Line:    [phone]
N-0371 OSLO						GSM: [phone]
NORWAY						http://www.security.no




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26304 for ietf-pkix-bks; Mon, 7 Sep 1998 17:02:27 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA26299 for <[e-mail]>; Mon, 7 Sep 1998 17:02:26 -0700 (PDT)
Received: 	id UAA07858; Mon, 7 Sep 1998 20:04:33 -0400
Received: by gateway id <S2S6XSHF>; Mon, 7 Sep 1998 20:01:31 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: forward & reverse elements - population
Date: Mon, 7 Sep 1998 20:01:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA25807 for ietf-pkix-bks; Mon, 7 Sep 1998 15:26:02 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA25803 for <[e-mail]>; Mon, 7 Sep 1998 15:26:01 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 07 Sep 1998 15:30:57 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: PKIX freeware library coming soon (fwd)
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16002 for ietf-pkix-bks; Mon, 7 Sep 1998 11:55:40 -0700 (PDT)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15998 for <[e-mail]>; Mon, 7 Sep 1998 11:55:39 -0700 (PDT)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id PAA27888; Mon, 7 Sep 1998 15:00:41 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id PAA11891; Mon, 7 Sep 1998 15:00:39 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 85256678.006834C0 ; Mon, 7 Sep 1998 14:58:12 -0400
X-Lotus-FromDomain: FDC
To: Mike Smith <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 7 Sep 1998 11:59:43 -0700
Subject: Re: Relational vs Directory Repository Models (was RE: path development complexity s)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07642 for ietf-pkix-bks; Mon, 7 Sep 1998 10:30:30 -0700 (PDT)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07638 for <[e-mail]>; Mon, 7 Sep 1998 10:30:28 -0700 (PDT)
Received: by relay2.elvis.ru (8.8.5/1.25) id VAA29408; Mon, 7 Sep 1998 21:35:28 +0400 (MSK DST)
Message-ID: <[e-mail]>
X-Mailer: XFMail 1.3 [p0] on Solaris
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Mon, 07 Sep 1998 21:35:28 +0400 (MSK DST)
From: Pavel Krylov <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: depth
Sender: [e-mail]
Precedence: bulk

My question:
        What depth of certificate tree is exist now?? Average value?

Sharon, Santosh? 

---------------------------------------
Pavel V.Krylov          [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07055 for ietf-pkix-bks; Mon, 7 Sep 1998 10:23:19 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA07051 for <[e-mail]>; Mon, 7 Sep 1998 10:23:18 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 11:23:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 11:23:32 -0600
From: Mike Smith <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Re relational - and Dirs and all that
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06891 for ietf-pkix-bks; Mon, 7 Sep 1998 09:57:29 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06886 for <[e-mail]>; Mon, 7 Sep 1998 09:57:20 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFKM>; Tue, 8 Sep 1998 03:01:18 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07380E@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re relational - and Dirs and all that
Date: Tue, 8 Sep 1998 03:01:12 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA06888
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06469 for ietf-pkix-bks; Mon, 7 Sep 1998 09:01:23 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA06465 for <[e-mail]>; Mon, 7 Sep 1998 09:01:21 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 10:01:30 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 10:01:25 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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: [e-mail]; [e-mail] 
Cc: [e-mail]; [e-mail] 
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 <[e-mail]> 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; [e-mail] 
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.


                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06115 for ietf-pkix-bks; Mon, 7 Sep 1998 08:12:09 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06109 for <[e-mail]>; Mon, 7 Sep 1998 08:12:02 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFKB>; Tue, 8 Sep 1998 01:16:00 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC073803@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'Mike Smith '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Relational vs Directory Repository Models (was RE: pathdevelo pment complexity s)
Date: Tue, 8 Sep 1998 01:15:58 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 Mike - I am not sure if I understand your response as it mixes
technology statements.
So comments in line.

----------
From: Mike Smith
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
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 <[e-mail]> 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; [e-mail] 
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.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05809 for ietf-pkix-bks; Mon, 7 Sep 1998 07:27:40 -0700 (PDT)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA05805 for <[e-mail]>; Mon, 7 Sep 1998 07:27:39 -0700 (PDT)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 08:27:27 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 08:27:08 -0600
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Relational vs Directory Repository Models (was RE: path development complexity s)
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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; [e-mail] 
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.

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05623 for ietf-pkix-bks; Mon, 7 Sep 1998 06:56:10 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05618 for <[e-mail]>; Mon, 7 Sep 1998 06:56:06 -0700 (PDT)
Received: from d1o65.telia.com ([e-mail] [62.20.132.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id QAA03923; Mon, 7 Sep 1998 16:01:01 +0200 (CEST)
Received: from stefans (t2o65p95.telia.com [62.20.132.215]) by d1o65.telia.com (8.8.8/8.8.5) with SMTP id QAA03606; Mon, 7 Sep 1998 16:00:42 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 07 Sep 1998 15:58:39 +0200
To: "Aram Perez" <[e-mail]>, bob jueneman <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA05620
Sender: [e-mail]
Precedence: bulk

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
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05609 for ietf-pkix-bks; Mon, 7 Sep 1998 06:51:36 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05605 for <[e-mail]>; Mon, 7 Sep 1998 06:51:29 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFJX>; Mon, 7 Sep 1998 23:55:10 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0737F9@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Frank O'Dwyer '" <[e-mail]>
Cc: "'Dave Horvath '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Mon, 7 Sep 1998 23:55:08 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

 
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; [e-mail]
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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05308 for ietf-pkix-bks; Mon, 7 Sep 1998 05:51:16 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05304 for <[e-mail]>; Mon, 7 Sep 1998 05:50:53 -0700 (PDT)
Received: from d1o68.telia.com ([e-mail] [62.20.138.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id OAA00330; Mon, 7 Sep 1998 14:55:39 +0200 (CEST)
Received: from stefans (t3o68p29.telia.com [62.20.139.29]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA28463; Mon, 7 Sep 1998 14:55:35 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 07 Sep 1998 14:53:16 +0200
To: Bill Brice <[e-mail]>, pkix <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Defining Non-Repudiation
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA05305
Sender: [e-mail]
Precedence: bulk

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. :)
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA01907 for ietf-pkix-bks; Mon, 7 Sep 1998 01:23:43 -0700 (PDT)
Received: from mailhost.dircon.co.uk (mailhost.dircon.co.uk [194.112.32.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA01902 for <[e-mail]>; Mon, 7 Sep 1998 01:23:41 -0700 (PDT)
Received: from dircon.co.uk (th-en133-079.pool.dircon.co.uk [194.112.53.79]) by mailhost.dircon.co.uk (8.9.1/8.8.7) with ESMTP id JAA13359 for <[e-mail]>; Mon, 7 Sep 1998 09:28:29 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 07 Sep 1998 09:35:36 +0100
From: Jorgen Moller <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.02 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27936 for ietf-pkix-bks; Sun, 6 Sep 1998 09:51:13 -0700 (PDT)
Received: from out5.ibm.net (out5.ibm.net [165.87.194.243]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27932 for <[e-mail]>; Sun, 6 Sep 1998 09:51:11 -0700 (PDT)
Received: from 730xcdt (slip139-92-24-251.por.uk.ibm.net [139.92.24.251]) by out5.ibm.net (8.8.5/8.6.9) with SMTP id QAA26578 for <[e-mail]>; Sun, 6 Sep 1998 16:56:09 GMT
From: "CliveBetteridge" <[e-mail]>
To: <[e-mail]>
Subject: Internet Directory Consortium call for participation in DirConnect3
Date: Sun, 6 Sep 1998 17:48:12 +0100
Message-ID: <01bdd9b6$22a8b940$LocalHost@730xcdt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01BDD9BE.846D2140"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

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:[e-mail] Ph: [phone]

http://www.opengroup.org/idc/ Fx: [phone]=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:[e-mail]</U></FONT><FONT color=3D#000000=20
face=3DArial>&nbsp;Ph: [phone]</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: [phone] =
</FONT></P></DIV></DIV></BODY></HTML>

------=_NextPart_000_00D9_01BDD9BE.846D2140--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA22327 for ietf-pkix-bks; Sat, 5 Sep 1998 13:17:35 -0700 (PDT)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA22323 for <[e-mail]>; Sat, 5 Sep 1998 13:17:33 -0700 (PDT)
Received: from [158.152.104.114] (helo=brd.ie) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zFOqt-0007Cf-00 for [e-mail]; Sat, 5 Sep 1998 20:22:31 +0000
Message-ID: <[e-mail]>
Date: Sat, 05 Sep 1998 21:20:16 +0100
From: "Frank O'Dwyer" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: path development complexity
References: <001201bdd8d7$6a2f60a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21055 for ietf-pkix-bks; Sat, 5 Sep 1998 07:09:49 -0700 (PDT)
Received: from mailsvr.basit.com (mailsvr.basit.com [128.209.2.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21051 for <[e-mail]>; Sat, 5 Sep 1998 07:09:43 -0700 (PDT)
Received: from klerer.basit.com (shiva119 [128.209.144.119]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id KAA28073 for <[e-mail]>; Sat, 5 Sep 1998 10:13:15 -0400 (EDT)
Message-ID: <001201bdd8d7$6a2f60a0$[e-mail]>
From: "Robert Klerer" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: path development complexity 
Date: Sat, 5 Sep 1998 10:13:36 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
To: Alan Lloyd <[e-mail]>
Cc: Dave Horvath <[e-mail]>; [e-mail] <[e-mail]>
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.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA17401 for ietf-pkix-bks; Sat, 5 Sep 1998 04:41:03 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA17397 for <[e-mail]>; Sat, 5 Sep 1998 04:41:02 -0700 (PDT)
Received: from [158.152.104.114] (helo=brd.ie) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zFGmh-0007jD-00; Sat, 5 Sep 1998 11:45:40 +0000
Message-ID: <[e-mail]>
Date: Sat, 05 Sep 1998 12:44:06 +0100
From: "Frank O'Dwyer" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: Dave Horvath <[e-mail]>, [e-mail]
Subject: Re: path development complexity (was Re: What the straw poll mean s)
References: <D1A949D4508DD1119C8100400533BEDC05D489@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA16384 for ietf-pkix-bks; Sat, 5 Sep 1998 04:27:42 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA16371 for <[e-mail]>; Sat, 5 Sep 1998 04:27:35 -0700 (PDT)
Received: from patrik (dialup185-1-22.swipnet.se [130.244.185.22])  by mb05.swip.net (8.8.8/8.8.8) with SMTP  id NAA10743;  Sat, 5 Sep 1998 13:32:17 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: Patrik [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.44 (Beta)
Date: Sat, 05 Sep 1998 13:32:45 +0200
To: WHenry <[e-mail]>
From: Patrik Nilsson <[e-mail]>
Subject: RE: Heads Up - Historic digital signing ceremony
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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:	[e-mail]
>> 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:[e-mail]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[e-mail]
>> > 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.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA11433 for ietf-pkix-bks; Fri, 4 Sep 1998 17:15:01 -0700 (PDT)
Received: from nick.arc.nasa.gov (nick.arc.nasa.gov [143.232.48.121]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA11426 for <[e-mail]>; Fri, 4 Sep 1998 17:15:00 -0700 (PDT)
Received: from [128.102.131.45] (hotdog.arc.nasa.gov [128.102.131.45]) by nick.arc.nasa.gov (8.8.7/8.8.7) with ESMTP id RAA16856 for <[e-mail]>; Fri, 4 Sep 1998 17:19:49 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011726b216213153a7@[128.102.131.45]>
Date: Fri, 4 Sep 1998 17:21:49 -0800
To: [e-mail]
From: Paul Ma <[e-mail]>
Subject: FOR Option2
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10422 for ietf-pkix-bks; Fri, 4 Sep 1998 14:44:40 -0700 (PDT)
Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10418 for <[e-mail]>; Fri, 4 Sep 1998 14:44:39 -0700 (PDT)
Received: from mailtst1 (mailtst1.us.oracle.com [144.25.88.179]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id OAA16968 for <[e-mail]>; Fri, 4 Sep 1998 14:49:32 -0700 (PDT)
Received:  from inferno by mailtst1 with SMTP (SMI-8.6/37.9) id OAA09210; Fri, 4 Sep 1998 14:47:47 -0700
From: "Surendra Reddy" <[e-mail]>
To: <[e-mail]>
Subject:  For option 2
Date: Fri, 4 Sep 1998 14:49:11 +0100
Message-ID: <001101bdd80a$cb797850$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10255 for ietf-pkix-bks; Fri, 4 Sep 1998 14:17:50 -0700 (PDT)
Received: from docws007.shl.com (docws007.shl.com [159.249.56.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10251 for <[e-mail]>; Fri, 4 Sep 1998 14:17:49 -0700 (PDT)
Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws007.shl.com (8.9.1/8.9.1) with SMTP id QAA03170 for <[e-mail]>; Fri, 4 Sep 1998 16:28:37 -0500
Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Fri, 4 Sep 1998 16:22:39 -0500
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'WHenry'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 16:22:33 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA10252
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Friday, September 04, 1998 1:48 PM
>To: 	'Kurn, David'
>Cc: 	'[e-mail]'
>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:	[e-mail]
>> 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:[e-mail]]
>> > Sent:	Friday, September 04, 1998 9:12 AM
>> > To:	[e-mail]
>> > 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.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA10107 for ietf-pkix-bks; Fri, 4 Sep 1998 13:58:54 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA10103 for <[e-mail]>; Fri, 4 Sep 1998 13:58:54 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA23121 for <[e-mail]>; Fri, 4 Sep 1998 14:03:48 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04MGZZ7>; Fri, 4 Sep 1998 14:03:01 -0700
Message-ID: <[e-mail]>
From: "Salmond, Kent" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:57 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA10021 for ietf-pkix-bks; Fri, 4 Sep 1998 13:52:28 -0700 (PDT)
Received: from portal.visa.com (portal.visa.com [198.80.42.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA10017 for <[e-mail]>; Fri, 4 Sep 1998 13:52:26 -0700 (PDT)
Received: by portal.visa.com id NAA11445 (InterLock SMTP Gateway 3.0 for [e-mail]); Fri, 4 Sep 1998 13:57:19 -0700
Received: by portal.visa.com (Protected-side Proxy Mail Agent-1); Fri, 4 Sep 1998 13:57:19 -0700
Message-Id: <[e-mail]>
From: "Smith, David" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 13:56:51 -0700 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08871 for ietf-pkix-bks; Fri, 4 Sep 1998 12:18:09 -0700 (PDT)
Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA08867 for <[e-mail]>; Fri, 4 Sep 1998 12:18:07 -0700 (PDT)
Received: from m5pqp [195.99.53.190]  by tungsten.btinternet.com with smtp (Exim 1.70 #1) id 0zF1Ox-0001O7-00; Fri, 4 Sep 1998 20:20:07 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 04 Sep 1998 20:24:15 +0100
To: "[e-mail]" <[e-mail]>
From: John Hughes <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

 -------------------------------------------------------------------
| John Hughes             [e-mail]                 |
| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
|                         Home Fax No:           [phone]  |
|                         Main Office Tel:       [phone] |
| www.entegrity.com       Mobile:                [phone]   |
 ------------------------------------------------------------------- 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08796 for ietf-pkix-bks; Fri, 4 Sep 1998 12:10:32 -0700 (PDT)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08791 for <[e-mail]>; Fri, 4 Sep 1998 12:10:30 -0700 (PDT)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.1960.3) id <RDRTQCTS>; Fri, 4 Sep 1998 14:16:49 -0500
Message-ID: <[e-mail]>
From: Bill Brice <[e-mail]>
To: "'Kurn, David'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 14:16:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: Friday, September 04, 1998 11:43 AM
> To: [e-mail]
> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA08431 for ietf-pkix-bks; Fri, 4 Sep 1998 11:27:08 -0700 (PDT)
Received: from labcalserver.labcal.qc.ca (labcal.qc.ca [199.45.69.189]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA08423 for <[e-mail]>; Fri, 4 Sep 1998 11:26:57 -0700 (PDT)
Received: from jfsauriol (ott-on3-07.netcom.ca [207.181.90.135]) by labcalserver.labcal.qc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id S1MV02KP; Fri, 4 Sep 1998 14:37:38 -0400
Reply-To: <[e-mail]>
From: "JF Sauriol" <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:31:02 -0400
Message-ID: <001101bdd832$2bb357a0$0500a8c0@jfsauriol>
MIME-Version: 1.0
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="winmail.dat"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
X-MS-TNEF-Correlator: 00000000EE66A839D9EFBB118ED2727702A12BC664302300
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

eJ8+IgISAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAAM4HCQAEAA4AHgAAAAUAEwEB
A5AGAAAEAAAmAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAADQAAAEZvciBPcHRpb24gMgAAAAACAXEAAQAAABYAAAABvdgyJWrd9tAMRAAR0qKdAAAAAADe
AAACAR0MAQAAABwAAABTTVRQOkpGU0FVUklPTEBMQUJDQUwuUUMuQ0EACwABDgAAAABAAAYOAMQv
BjLYvQECAQoOAQAAABgAAAAAAAAA7maoOdnvuxGO0nJ3AqErxsKAAAALAB8OAQAAAAMABhAAAAAA
AwAHEAAAAAAeAAgQAQAAAAUAAADYIwR4AAAAAAMAEBAAAgAAAwAREDERAHgLAACACCAGAAAAAADA
AAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAgg
BgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAA
AAQAAAA4LjUAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAA
AAAARgAAAAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAA
AAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEA
AAAAAAAAHgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAA
AMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAMaACyAGAAAAAADAAAAAAAAARgAAAAAAiAAA
AAAAAAsAyIALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAACwDugAggBgAAAAAAwAAAAAAAAEYA
AAAABoUAAAAAAAALAPKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAIB+A8BAAAAEAAAAO5m
qDnZ77sRjtJydwKhK8YCAfoPAQAAABAAAADuZqg52e+7EY7ScncCoSvGAgH7DwEAAABkAAAAAAAA
ADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAARDpc
V09SS1xPdXRsb29rIEZpbGVzXGpmc2F1cmlvbC1sYWJjYWwucHN0AAMA/g8FAAAAAwANNP03AAAC
AX8AAQAAADEAAAAwMDAwMDAwMEVFNjZBODM5RDlFRkJCMTE4RUQyNzI3NzAyQTEyQkM2NjQzMDIz
MDAAAAAAXJI=



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08215 for ietf-pkix-bks; Fri, 4 Sep 1998 10:58:33 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08211 for <[e-mail]>; Fri, 4 Sep 1998 10:58:32 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZX7Z>; Fri, 4 Sep 1998 14:02:54 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E0D95CF@WUHER>
From: Larry Shomo <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 14:02:52 -0400
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Lawrence P. Shomo
Vice President

********************************
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia, 22102-3305
[phone], x202 (Phone)
[phone] (Fax)
[e-mail] (Email)

********************************



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08085 for ietf-pkix-bks; Fri, 4 Sep 1998 10:41:07 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08080 for <[e-mail]>; Fri, 4 Sep 1998 10:41:06 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQffkh26911; Fri, 4 Sep 1998 13:45:50 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRBN14>; Fri, 4 Sep 1998 13:48:02 -0400
Message-ID: <[e-mail]>
From: WHenry <[e-mail]>
To: "'Kurn, David'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 13:48:00 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA08082
Sender: [e-mail]
Precedence: bulk

 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:	[e-mail]
> 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:[e-mail]]
> > Sent:	Friday, September 04, 1998 9:12 AM
> > To:	[e-mail]
> > 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07931 for ietf-pkix-bks; Fri, 4 Sep 1998 10:27:06 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07927 for <[e-mail]>; Fri, 4 Sep 1998 10:27:05 -0700 (PDT)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA19928 for <[e-mail]>; Fri, 4 Sep 1998 10:19:27 -0700
Received: from scv1.apple.com (scv1.apple.com [17.128.100.139]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id <[e-mail]>; Fri, 04 Sep 1998 10:17:29 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA43944; Fri, 4 Sep 1998 10:17:28 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) 
Date: Fri, 04 Sep 1998 10:17:26 -0700
Subject: Re: Digital signature and non-repudiation key usage bits
From: "Aram Perez" <[e-mail]>
To: Stefan Santesson <[e-mail]>, bob jueneman <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07483 for ietf-pkix-bks; Fri, 4 Sep 1998 09:39:19 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07479 for <[e-mail]>; Fri, 4 Sep 1998 09:39:17 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA18402 for <[e-mail]>; Fri, 4 Sep 1998 09:44:09 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04MG4T0>; Fri, 4 Sep 1998 09:43:22 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: [e-mail]
Subject: RE: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 09:43:21 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA07480
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, September 04, 1998 9:12 AM
> To:	[e-mail]
> 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07475 for ietf-pkix-bks; Fri, 4 Sep 1998 09:38:56 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07471 for <[e-mail]>; Fri, 4 Sep 1998 09:38:55 -0700 (PDT)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id SAA19894; Fri, 4 Sep 1998 18:43:31 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA00279; Fri, 4 Sep 1998 18:43:30 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA12254; Fri, 4 Sep 1998 18:43:29 +0200
Date: Fri, 4 Sep 1998 18:43:29 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: What the straw poll means
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

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?
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07312 for ietf-pkix-bks; Fri, 4 Sep 1998 09:17:45 -0700 (PDT)
Received: from ewa-canada.com (ewa-canada.com [209.146.131.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07308 for <[e-mail]>; Fri, 4 Sep 1998 09:17:41 -0700 (PDT)
Received: by ewa-canada.com from localhost (router,SLMail V2.6); Fri, 04 Sep 1998 12:21:59 -0400
Received: by ewa-canada.com from def23.ewa-canada.com (209.146.131.23::mail daemon,SLMail V2.6); Fri, 04 Sep 1998 12:21:58 -0400
Message-Id: <[e-mail]>
X-Sender: "Erin Connor" <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 04 Sep 1998 12:18:06 -0400
To: [e-mail]
From: "Erin Connor" <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

--------------------------------------------------------------------------
Erin Connor                             EWA-Canada Ltd.
Voice:  [phone] Ext 234       Suite 1600 - 275 Slater Street
Fax:    [phone]               Ottawa, Ontario, Canada  K1P 5H9
mailto:[e-mail]         	http://www.ewa-canada.com

** Visit the CanCERT website at  http://cancert.ca ***
--------------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07186 for ietf-pkix-bks; Fri, 4 Sep 1998 09:05:35 -0700 (PDT)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07182 for <[e-mail]>; Fri, 4 Sep 1998 09:05:33 -0700 (PDT)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.1960.3) id <RDRTQCSX>; Fri, 4 Sep 1998 11:11:53 -0500
Message-ID: <[e-mail]>
From: Bill Brice <[e-mail]>
To: [e-mail]
Subject: Heads Up - Historic digital signing ceremony
Date: Fri, 4 Sep 1998 11:11:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA07183
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07000 for ietf-pkix-bks; Fri, 4 Sep 1998 08:48:15 -0700 (PDT)
Received: from mailsvr.basit.com (mailsvr.basit.com [128.209.2.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06996 for <[e-mail]>; Fri, 4 Sep 1998 08:48:13 -0700 (PDT)
Received: from klerer.basit.com (shiva118 [128.209.144.118]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id LAA18007 for <[e-mail]>; Fri, 4 Sep 1998 11:51:49 -0400 (EDT)
Message-ID: <008c01bdd81b$faa3d740$[e-mail]>
From: "Robert Klerer" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: path development complexity (was Re: What the straw poll means)
Date: Fri, 4 Sep 1998 11:52:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
To: Dave Horvath <[e-mail]>
Cc: [e-mail] <[e-mail]>
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.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06761 for ietf-pkix-bks; Fri, 4 Sep 1998 08:25:50 -0700 (PDT)
Received: from nad.ic.gc.ca (nad.ic.gc.ca [192.197.184.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06757 for <[e-mail]>; Fri, 4 Sep 1998 08:25:47 -0700 (PDT)
Message-Id: <[e-mail]>
Received: by nad.ic.gc.ca with Internet Mail Service (5.5.1960.3) id <SGCYYQ51>; Fri, 4 Sep 1998 11:26:42 -0400
From: "Power, Michael: LEG" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:24:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06565 for ietf-pkix-bks; Fri, 4 Sep 1998 08:10:35 -0700 (PDT)
Received: from gatekeeper.domus.com (gatekeeper.domus.com [198.166.58.193]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA06561 for <[e-mail]>; Fri, 4 Sep 1998 08:10:32 -0700 (PDT)
Received: from dns_int.domus.com by gatekeeper1.domus.com (8.6.13/200.19.1.1) id LAA13793; Fri, 4 Sep 1998 11:03:44 -0400
Received: (from smap@localhost) by dns_int.domus.com (8.6.8/8.6.6) id KAA05253 for <[e-mail]>; Fri, 4 Sep 1998 10:31:52 -0400
Received: from wpgate.domus.com(198.166.59.10) by dns_int.domus.com via smap (V1.3) id sma005251; Fri Sep  4 10:31:44 1998
Received: from DOMUS-Message_Server by wpgate.domus.com with Novell_GroupWise; Fri, 04 Sep 1998 11:03:54 -0400
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 04 Sep 1998 11:03:15 -0400
From: Pamela Grannum <[e-mail]>
To: [e-mail]
Subject: For Option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06518 for ietf-pkix-bks; Fri, 4 Sep 1998 08:07:16 -0700 (PDT)
Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA06514 for <[e-mail]>; Fri, 4 Sep 1998 08:07:14 -0700 (PDT)
From: [e-mail]
Received: 	id LAA03483; Fri, 4 Sep 1998 11:08:05 -0400
Received: by gateway id <NWL91YVT>; Fri, 4 Sep 1998 11:05:15 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Fri, 4 Sep 1998 11:13:27 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

My vote is for Option 2 of the LDAP schema companion paper.


Edmond P. van Hees
GOC PKI Security Engineer
telephone: [phone] 
Fax: [phone]
E-Mail:  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06435 for ietf-pkix-bks; Fri, 4 Sep 1998 07:55:22 -0700 (PDT)
Received: from us.checkpoint.com (oak.us.checkpoint.com [206.86.35.94]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06431 for <[e-mail]>; Fri, 4 Sep 1998 07:55:21 -0700 (PDT)
Received: from 101.101.101.103 ([207.245.220.71]) by us.checkpoint.com (8.9.1/8.9.1/CPoak/1.3.3) with SMTP id IAA06119 for <[e-mail]>; Fri, 4 Sep 1998 08:00:05 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 04 Sep 1998 10:37:54 -0700
To: [e-mail]
From: "Steve O'Neil" <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06318 for ietf-pkix-bks; Fri, 4 Sep 1998 07:32:22 -0700 (PDT)
Received: from mail.storm.ca ([e-mail] [207.245.225.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06314 for <[e-mail]>; Fri, 4 Sep 1998 07:32:20 -0700 (PDT)
Received: from treebeard (dial02p48.ottawa.storm.ca [207.245.246.112]) by mail.storm.ca (8.8.8/8.8.8) with SMTP id KAA04568 for <[e-mail]>; Fri, 4 Sep 1998 10:36:18 -0400 (EDT)
Message-ID: <00cf01bdd811$0b0a25e0$70f6f5cf@treebeard>
Reply-To: "Mark Scherling" <[e-mail]>
From: "Mark Scherling" <[e-mail]>
To: <[e-mail]>
Subject: option 2
Date: Fri, 4 Sep 1998 10:33:53 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06293 for ietf-pkix-bks; Fri, 4 Sep 1998 07:30:01 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06286 for <[e-mail]>; Fri, 4 Sep 1998 07:29:59 -0700 (PDT)
Received: by gateway.r3.ch id <6806>; Fri, 4 Sep 1998 16:36:05 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Sharon Boeyen <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:30:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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.





>  
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06081 for ietf-pkix-bks; Fri, 4 Sep 1998 07:03:55 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06075 for <[e-mail]>; Fri, 4 Sep 1998 07:03:52 -0700 (PDT)
Received: by gateway.r3.ch id <6813>; Fri, 4 Sep 1998 16:10:03 +0100
Message-Id: <[e-mail]>
From: Rene Eberhard <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Fri, 4 Sep 1998 15:06:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Best regards Rene



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06072 for ietf-pkix-bks; Fri, 4 Sep 1998 07:02:43 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06068 for <[e-mail]>; Fri, 4 Sep 1998 07:02:41 -0700 (PDT)
Received: by gateway.r3.ch id <6814>; Fri, 4 Sep 1998 16:08:52 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 15:02:50 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	September 4, 1998 9:19 AM
> To: 	'Bill Burr'; Santosh Chokhani
> Cc: 	[e-mail]
> 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
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05948 for ietf-pkix-bks; Fri, 4 Sep 1998 06:41:14 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05944 for <[e-mail]>; Fri, 4 Sep 1998 06:41:12 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZXT1>; Fri, 4 Sep 1998 09:45:37 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D230@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: [e-mail], Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:45:36 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Comments in line.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[e-mail]]
> Sent:	Friday, September 04, 1998 1:03 PM
> To:	Sharon Boeyen
> Cc:	[e-mail]; '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:[e-mail]
>       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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05674 for ietf-pkix-bks; Fri, 4 Sep 1998 06:18:54 -0700 (PDT)
Received: from att.com (kcgw2.att.com [192.128.133.152]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA05670 for <[e-mail]>; Fri, 4 Sep 1998 06:18:53 -0700 (PDT)
Received: from kcig2.fw.att.com by kcgw2.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-pkix sender att.com!jayhawk (att.com!jayhawk); Fri Sep  4 08:02 CDT 1998
Received: from qsun.ho.att.com (qsunn.ho.att.com [135.16.30.2]) by kcig2.fw.att.com (AT&T/IPNS/GW-1.0) with SMTP id IAA12147 for <[e-mail]>; Fri, 4 Sep 1998 08:23:37 -0500 (CDT)
Received: from sloop.local.windrose.omaha.ne.us by qsun.ho.att.com (SMI-8.6/EMS-1.2 sol2) id JAA18228; Fri, 4 Sep 1998 09:23:33 -0400
From: "Ryan Moats" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <002201bdd807$903c8d20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05652 for ietf-pkix-bks; Fri, 4 Sep 1998 06:15:08 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05648 for <[e-mail]>; Fri, 4 Sep 1998 06:15:06 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZXSN>; Fri, 4 Sep 1998 09:19:30 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D22E@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 09:19:29 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA05649
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, September 04, 1998 9:21 AM
> To:	Santosh Chokhani
> Cc:	[e-mail]
> 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:[e-mail]]
> >> Sent:	Friday, September 04, 1998 7:20 AM
> >> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
> >> 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
> >> 
> >> 
> >> 
> >> 
> >> 
> >> -------------------------------------------------------------------
> >> Stefan Santesson                <[e-mail]>
> >> Accurata Systemsäkerhet AB     
> >> Lotsgatan 27 D                  Tel. [phone]              
> >> 216 42  Malmö                   Fax. [phone]              
> >> Sweden                        Mobile [phone]
> >> 
> >> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> >> -------------------------------------------------------------------
> >
> >
> Regards,
> 
> Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05612 for ietf-pkix-bks; Fri, 4 Sep 1998 06:12:19 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA05608 for <[e-mail]>; Fri, 4 Sep 1998 06:12:17 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id JAA11951; Fri, 4 Sep 1998 09:16:57 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 04 Sep 1998 09:20:36 -0400
To: Santosh Chokhani <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: RE: What the straw poll means
Cc: [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E16D22D@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA05609
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Friday, September 04, 1998 7:20 AM
>> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
>> 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
>> 
>> 
>> 
>> 
>> 
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB     
>> Lotsgatan 27 D                  Tel. [phone]              
>> 216 42  Malmö                   Fax. [phone]              
>> Sweden                        Mobile [phone]
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>
Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05206 for ietf-pkix-bks; Fri, 4 Sep 1998 05:53:27 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05201 for <[e-mail]>; Fri, 4 Sep 1998 05:53:26 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA12341 for <[e-mail]>; Fri, 4 Sep 1998 08:58:18 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA12333 for <[e-mail]>; Fri, 4 Sep 1998 08:58:17 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA14842 for <[e-mail]>; Fri, 4 Sep 1998 08:57:41 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 04 Sep 1998 08:58:32 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Fri, 4 Sep 1998 08:58:26 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
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
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>Sent: 	Thursday, September 03, 1998 4:41 PM
>To: 	Carlisle Adams
>Cc: 	[e-mail]
>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:[e-mail]]
>> > Sent:         Thursday, September 03, 1998 12:14 PM
>> > To:   [e-mail]
>> > Cc:   [e-mail]
>> > 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.				        [e-mail]
>1215 Terra Bella Ave.		              http://www.valicert.com
>Mountain View, CA 94043-1833
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA04409 for ietf-pkix-bks; Fri, 4 Sep 1998 05:07:00 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04405 for <[e-mail]>; Fri, 4 Sep 1998 05:06:58 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZXQV>; Fri, 4 Sep 1998 08:11:21 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D22D@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 08:11:19 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA04406
Sender: [e-mail]
Precedence: bulk

Stefan:

I agree with every thing you say in this mail message,

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[e-mail]]
> Sent:	Friday, September 04, 1998 7:20 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
> 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
> 
> 
> 
> 
> 
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB     
> Lotsgatan 27 D                  Tel. [phone]              
> 216 42  Malmö                   Fax. [phone]              
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04107 for ietf-pkix-bks; Fri, 4 Sep 1998 04:21:09 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04103 for <[e-mail]>; Fri, 4 Sep 1998 04:21:07 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Fri, 4 Sep 1998 12:24:48 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
cc: Sharon Boeyen <[e-mail]>, [e-mail], "'Santosh Chokhani'" <[e-mail]>
Subject: Re: What the straw poll means 
In-reply-to: Your message of "Fri, 04 Sep 1998 10:03:20 PDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 04 Sep 1998 12:24:47 +0100
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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:	[phone]		Richmond, Surrey, ENGLAND
I'net:	[e-mail]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04089 for ietf-pkix-bks; Fri, 4 Sep 1998 04:17:27 -0700 (PDT)
Received: from maila.telia.com ([e-mail] [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04085 for <[e-mail]>; Fri, 4 Sep 1998 04:17:24 -0700 (PDT)
Received: from stefans (t3o68p109.telia.com [62.20.139.109]) by maila.telia.com (8.8.8/8.8.8) with SMTP id NAA11442; Fri, 4 Sep 1998 13:22:05 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 04 Sep 1998 13:19:51 +0200
To: Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA04086
Sender: [e-mail]
Precedence: bulk

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





-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA02805 for ietf-pkix-bks; Fri, 4 Sep 1998 03:18:52 -0700 (PDT)
Received: from maila.telia.com ([e-mail] [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA02801 for <[e-mail]>; Fri, 4 Sep 1998 03:18:50 -0700 (PDT)
Received: from stefans (t4o68p88.telia.com [62.20.139.208]) by maila.telia.com (8.8.8/8.8.8) with SMTP id MAA14602; Fri, 4 Sep 1998 12:22:18 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 04 Sep 1998 12:20:04 +0200
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA02802
Sender: [e-mail]
Precedence: bulk

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


-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA29009 for ietf-pkix-bks; Fri, 4 Sep 1998 02:49:39 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA29005 for <[e-mail]>; Fri, 4 Sep 1998 02:49:37 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090405534560:1457  for <[e-mail]> ; Fri, 4 Sep 1998 05:53:45 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090405534560:1457  for <[e-mail]> ; Fri, 4 Sep 1998 05:53:45 -0400 
X-Lotus-FromDomain: IRIS
Message-ID: <[e-mail]>
Date: Fri, 4 Sep 1998 05:56:52 -0400
Mime-Version: 1.0
x-notes-Form: Memo
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: [e-mail]
Precedence: bulk

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Dave Horvath <[e-mail]> 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

UmVjZWl2ZWQ6IGZyb20gYXJpc3RhLmlyaXMuY29tIChbOS45NS42NS4xNV0pDQogICAgICAgICAg
YnkgZXBpYy5pcmlzLmNvbSAoTG90dXMgRG9taW5vIEJ1aWxkIDE2MSAoQmV0YSkpDQogICAgICAg
ICAgd2l0aCBTTVRQIGlkIDE5OTgwOTAzMjIwMDAxNTk6MTQyOCANCiAgICAgICAgICBmb3IgPGRh
dmVAY2hyb21hdGl4LmNvbT4gLA0KICAgICAgICAgICAgICA8aWV0Zi1wa2ljQGltYy5vcmc+IDsN
CiAgICAgICAgICBUaHUsIDMgU2VwIDE5OTggMjI6MDA6MDEgLTA0MDAgDQpSZWNlaXZlZDogZnJv
bSBhcmlzdGEuaXJpcy5jb20gKFs5Ljk1LjY1LjE1XSkNCiAgICAgICAgICBieSBlcGljLmlyaXMu
Y29tIChMb3R1cyBEb21pbm8gQnVpbGQgMTYxIChCZXRhKSkNCiAgICAgICAgICB3aXRoIFNNVFAg
aWQgMTk5ODA5MDMyMjAwMDE1OToxNDI4IA0KICAgICAgICAgIGZvciA8ZGF2ZUBjaHJvbWF0aXgu
Y29tPiAsDQogICAgICAgICAgICAgIDxpZXRmLXBraWNAaW1jLm9yZz4gOw0KICAgICAgICAgIFRo
dSwgMyBTZXAgMTk5OCAyMjowMDowMSAtMDQwMCANClgtTG90dXMtRnJvbURvbWFpbjogSVJJUw0K
RnJvbTogSm9obl9XcmF5QGlyaXMuY29tDQpUbzogRGF2ZSBIb3J2YXRoIDxkYXZlQGNocm9tYXRp
eC5jb20+DQpjYzogaWV0Zi1wa2ljQGltYy5vcmcNCk1lc3NhZ2UtSUQ6IDw4NTI1NjY3NS4wMDBC
MjM1Ny4wMEBhcmlzdGEuaXJpcy5jb20+DQpEYXRlOiBUaHUsIDMgU2VwIDE5OTggMTk6NTY6MTQg
LTA0MDANClN1YmplY3Q6IFJlOiBXaGF0IHRoZSBzdHJhdyBwb2xsIG1lYW5zDQpNaW1lLVZlcnNp
b246IDEuMA0KeC1ub3Rlcy0kMjROb3RlSGFzTmF0aXZlTUlNRTogMQ0KeC1ub3Rlcy1TTVRQT3Jp
Z2luYXRvcjogSm9obl9XcmF5QGlyaXMuY29tDQp4LW5vdGVzLSQyNFVwZGF0ZWRCeTogQ049RXBp
Yy9PPUlyaXMNCngtbm90ZXMtUm91dGVTZXJ2ZXJzOiBDTj1FcGljL089SXJpcw0KeC1ub3Rlcy1N
YWlsU2F2ZWRGb3JtOiBNZW1vDQp4LW5vdGVzLUZvcm06IE5vbkRlbGl2ZXJ5IFJlcG9ydA0KeC1u
b3Rlcy1GYWlsdXJlUmVhc29uOiBFcnJvciB0cmFuc2ZlcnJpbmcgdG8gaW1jLm9yZzsgU01UUCBQ
cm90b2NvbCBSZXR1cm5lZCBhIFBlcm1hbmVudCBFcnJvciA1NTAgPGlldGYtcGtpY0BpbWMub3Jn
Pi4uLiBVc2VyIHVua25vd24NCngtbm90ZXMtSW50ZW5kZWRSZWNpcGllbnQ6IGlldGYtcGtpY0Bp
bWMub3JnDQpDb250ZW50LXR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWkNCkNvbnRl
bnQtRGlzcG9zaXRpb246IGlubGluZQ0KDQpEYXZlIEhvcnZhdGggPGRhdmVAY2hyb21hdGl4LmNv
bT4gd3JpdGVzOg0KDQoNCj4+IFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byBvcHRpb25z
IGlzIHByaW1hcmlseSBzdG9yYWdlIGVmZmljaWVuY3kNCnZzLg0KPj4gcmV0cmlldmFsIGVmZmlj
aWVuY3kuICBCb3RoIG9wdGlvbnMgZGl2aWRlIGEgQ0FzIGNlcnRzIGludG8gdHdvIHBpbGVzLg0K
Pj4gT3B0aW9uIDEgaGFzIHBpbGUgQSBjb250YWluaW5nIG9ubHkgaW50cmEtZG9tYWluIGNlcnRz
LCBhbmQgcGlsZSBCDQo+PiBjb250YWluaW5nIG9ubHkgaW50ZXItZG9tYWluIGNlcnRzOyBvcHRp
b24gMiBoYXMgcGlsZSBBIGNvbnRhaW5pbmcgb25seQ0KPj4gaW50cmEtZG9tYWluIGNlcnRzIGFu
ZCBwaXRlIEIgY29udGFpbmluZyBhbGwgY2VydHMuICBXaGljaCBvcHRpb24gaXMNCj4+IHN1cGVy
aW9yIGRlcGVuZHMgb24gdHdvIHRoaW5nczoNCj4+DQo+Pi4uLg0KPj4NCj4+IEhhdmluZyB0aGUg
dGFyZ2V0IENBIGRpdmlkZSBpdHMgY2VydGlmaWNhdGVzIGJldHdlZW4gdHdvIHBsYWNlcyB3aXRo
aW4NCnRoZQ0KPj4gZGlyZWN0b3J5IGlzIG5vIGhlbHAgdG8gdGhpcyB2ZXJpZmllci4gIEFsbCBp
dCBkb2VzIGl0IGZvcmNlIHRoZQ0KdmVyaWZpZXINCj4+IHRvIG1ha2UgdHdvIHJldHJpZXZhbCBv
cGVyYXRpb25zIGluc3RlYWQgb2YgdGhlIG9uZSB0aGF0IHdvdWxkIGJlDQpyZXF1aXJlZA0KPj4g
Ynkgb3B0aW9uIDIuICBUaGUgdmVyaWZpZXIgaXNuJ3QgcmVhbGx5IGludGVyZXN0ZWQgaW4gd2hl
dGhlciBhDQpwYXJ0aWN1bGFyDQo+PiBjZXJ0aWZpY2F0ZSBjb21lcyBmcm9tIGFub3RoZXIgQ0Eg
ZnJvbSB0aGUgc2FtZSAiZG9tYWluIiBhcyB0aGUgdGFyZ2V0J3MNCkNBDQo+PiAtIGlmIGl0IGNh
cmVzIGFib3V0ICJkb21haW5zIiBhdCBhbGwsIHdoYXQgaXQgd291bGQgYmUgaW50ZXJlc3RlZCBp
biBpcw0KaWYNCj4+IGFueSBjZXJ0cyBjb21lIGZyb20gdGhlIHNhbWUgZG9tYWluIGFzIHRoZSB2
ZXJpZmllciAob3Igb25lIG9mIGl0cw0KdHJ1c3RlZA0KPj4gcm9vdHMpLCBub3QgdGhlIHRhcmdl
dCAoYW5kIG9mIGNvdXJzZSB0aGF0J3MgdmVyaWZpZXItc3BlY2lmaWMpLg0KPg0KPiAgICBKb2hu
LCAgdGhlIHZlcmlmaWVyIGRvZXMgTk9UIGhhdmUgdG8gaW52b2tlIHR3byByZXRyaWV2YWwgb3Bl
cmF0aW9ucy4NCj5UaGUgdmVyaWZpZXIgc2ltcGx5IHJlYWRzIHRoZSBDQSBlbnRyeSByZXF1ZXN0
aW5nIGJvdGggdGhlIGNBQ2VydGlmaWNhdGUNCj5hdHRyaWJ1dGUgYW5kIHRoZSBjcm9zc0NlcnRp
ZmljYXRlUGFpciBhdHRyaWJ1dGUgaW4gdGhlIHNhbWUgc2VhcmNoL3JlYWQNCj5vcGVyYXRpb24u
ICBBbGwgY2VydGlmaWNhdGVzIGFyZSByZXR1cm5lZC4gIFRoZSB2ZXJpZmllciBjYW4gdGhlbiBk
ZWNpZGUNCj53aGV0aGVyIHRvIGV4cGxvcmUgaW50ZXItZG9tYWluLCBpbnRyYS1kb21haW4sIGJv
dGggLCBub25lLCB3aGF0ZXZlci4NCj5UaGUgdmVyaWZpZXIgY2FuIGx1bXAgdGhlbSBhbGwgdG9n
ZXRoZXIgaW4gdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBpZg0KPnRoZXkgbGlrZSEgIFRoZSBtYWlu
IGFkdmFudGFnZSB0byBvcHRpb24gMSBpcyB3ZSBkb24ndCBzdG9yZSB0aGUNCj5jZXJ0aWZpY2F0
ZXMgdHdpY2Ugd2hpY2ggaXMgIGEgZnVuZGFtZW50YWwgZ29hbCBpbiBhbGwgZGF0YWJhc2UNCj5h
cHBsaWNhdGlvbnMuICAgSU1ITyBpdCBhcHBsaWVzIHRvIHJlcG9zaXRvcmllcyBhbmQgcHVibGlj
IGtleQ0KPmluZnJhc3RydWN0dXJlcyBhbHNvLg0KDQpUaGVyZSBtYXkgbm90IGJlIHR3byBwcm90
b2NvbCBhY3Rpb25zIGFjcm9zcyB0aGUgd2lyZSwgYnV0IGl0J3MgZGVmaW5pdGVseQ0KbGVzcyB3
b3JrIGZvciB0aGUgY2xpZW50IHRvIHJlY2VpdmUgYSBzaW5nbGUgc2V0IG9mIG9iamVjdHMgYWxs
IG9mIHRoZSBzYW1lDQp0eXBlLCBjb21wYXJlZCB0byB0aGUgdHdvIHNldHMgb2YgZGlmZmVyZW50
bHkgdHlwZWQgb2JqZWN0cyB0aGF0IG9wdGlvbiAxDQpyZXF1aXJlcyBpdCB0byByZXRyaWV2ZS4g
IFVuZGVyIG9wdGlvbiAyLCB2ZXJpZmllcnMgdGhhdCBkb24ndCBjYXJlIGFib3V0DQp0aGUgQ0Fz
IGlkZWFzIGFib3V0IGRvbWFpbnMgY2FuIHNpbXBseSByZXRyaWV2ZSBhbGwgdGhlIENBcyBjZXJ0
aWZpY2F0ZXMuDQpIYXZpbmcgdGhlIENBIGRpdmlkZSBpdHMgY2VydGlmaWNhdGVzIGludG8gdHdv
IHBpbGVzIG9ubHkgYWRkcyBjb21wbGV4aXR5DQp0byB0aGUgY2xpZW50J3MgdGFzay4NCg0KVGhl
IG9ubHkgcGxhY2Ugd2hlcmUgdmVyaWZpZXJzIHdpbGwgY2FyZSBhYm91dCB3aGljaCBkb21haW4g
dGhlIENBIHRoaW5rcw0KaXQncyBpbiwgaXMgaWYgdGhleSB0aGluayB0aGV5IChvciBvbmUgb2Yg
dGhlaXIgcm9vdHMpIGFyZSBpbiB0aGUgc2FtZQ0KZG9tYWluLiAgT25seSBpbiB0aGF0IGNhc2Ug
aXMgYSB2ZXJpZmllciBsaWtlbHkgdG8gZGVjaWRlIHRvIGxvb2sgZmlyc3QgYXQNCnRoZSBDQXMg
aW50cmEtZG9tYWluIGNlcnRzLCBhbmQgb3B0aW9uIDIgYWxsb3dzIGZvciB0aGlzIGNob2ljZSBq
dXN0IGFzDQpzaW1wbHkgYXMgZG9lcyBvcHRpb24gMS4NCg0KVGhlIGNvc3Qgb2YgdGhpcyBpbiBv
cHRpb24gMiBpcyB0aGUgZHVwbGljYXRpb24gb2Ygc29tZSBjZXJ0aWZpY2F0ZXMgaW4gdGhlDQpk
aXJlY3RvcnkgKHdlIGFscmVhZHkgaGF2ZSBkdXBsaWNhdGlvbiBpbiB0aGlzIGFyZWEsIHVubGVz
cyB0aGUgZGlyZWN0b3J5DQpoYXMgc29tZSBpbnRlbGxpZ2VuY2UgdGhhdCB3aWxsIGVuYWJsZSBp
dCB0byBzdG9yZSBjcm9zcy1jZXJ0IHBhaXJzIG9ubHkNCm9uY2UgYW5kIHNvbWVob3cgcGxhY2Ug
YSByZWZlcmVuY2UgdG8gdGhlIHNoYXJlZCBvYmplY3QgZnJvbSBib3RoIENBDQplbnRyaWVzKS4g
IEJ1dCB0aGlzIGR1cGxpY2F0aW9uIGlzIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBDQSAtIGlm
IGl0DQpkb2Vzbid0IHRoaW5rIHRoZSBiZW5lZml0cyBvZiBzdG9yaW5nIGhpbnRzIGZvciBsb2Nh
bCB2ZXJpZmllcnMgYXJlDQp3b3J0aHdoaWxlLCBvcHRpb24gMiBhbGxvd3MgaXQgdG8gdXNlIF9v
bmx5XyB0aGUgY3Jvc3NDZXJ0aWZpY2F0ZSBlbnRyeSBmb3INCmFsbCBpdHMgY2VydHMuDQoNCj4g
ICAgVGhlIGdlbmVyYWwgYWxnb3JpdGhtIHdlIGVudmlzaW9uIGlzIGZvciBjbGllbnRzIHRvIGZp
cnN0IGV4cGxvcmUgdGhlDQo+Y0FDZXJ0aWZpY2F0ZSBhdHRyaWJ1dGUsIHRoZW4gZXhwbG9yZSB0
aGUgY3Jvc3NDZXJ0aWZpY2F0ZVBhaXINCj5hdHRyaWJ1dGUuICAgVGhhdCB3YXkgbm90aGluZyB3
aWxsIGdldCBtaXNzZWQuICBJdCdzIG5vdCBhbiBhbGwgb3INCj5ub3RoaW5nIGNob2ljZS4gIEl0
J3MgYW4gYXR0ZW1wdCB0byBzdG9yZSB0aGUgY2VydGlmaWNhdGVzIG9uY2UgYW5kIHRvDQo+Z3Jv
dXAgdGhlbSB0byBtYWtlIGxvZ2ljYWwgZGVjaXNpb25zIHdoZW4gZXhwbG9yaW5nIHBvc3NpYmx5
IGNvbXBsZXgNCj5wYXRocy4NCg0KQnV0IHlvdSBjYW4gb25seSBtYWtlIGxvZ2ljYWwgZGVjaXNp
b25zIHdoZW4geW91IGhhdmUgc29tZSBkYXRhIHRvIHdvcmsNCndpdGguICBBIENBIGhhcyBubyBp
ZGVhIHdoZW4gaXQncyBwbGFjaW5nIGl0cyBjZXJ0cyBpbiB0aGUgZGlyZWN0b3J5IGFib3V0DQp3
aG8gaXMgZ29pbmcgdG8gY29tZSBsb29rIGZvciB0aGVtLiAgV2l0aG91dCBrbm93aW5nIHdoYXQg
ZG9tYWluIHRoZQ0KdmVyaWZpZXIgaXMgaW4sIHRoZSBDQSBjYW4ndCBob3BlIHRvIGhlbHAgaXQg
b3V0LiAgSXQgY2FuIG1ha2UgYQ0Kc3BlY2lhbC1jYXNlIG9wdGltaXphdGlvbiB1bmRlciBlaXRo
ZXIgb3B0aW9uIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUNCnZlcmlmaWVyIGlzIGluIHRoZSBzYW1l
IGRvbWFpbiBhcyB0aGUgQ0EgICh3aGljaCBpcyByZWFsbHkgdGhlIG9ubHkgdGltZQ0KdGhhdCBl
aXRoZXIgb3B0aW9uIG9mZmVycyBhbnkgYWR2YW50YWdlIG92ZXIgc2ltcGx5IGhhdmluZyBhIHNp
bmdsZSBlbnRyeQ0KaW50byB3aGljaCBhbGwgY2VydHMgYXJlIHBsYWNlZCkuDQoNCg0KDQpJbiBz
dW1tYXJ5LCBteSBjb250ZW50aW9uIGlzIHRoYXQgdmVyeSBmZXcgdmVyaWZpZXJzIHdpbGwgZXZl
ciB3YW50IHRvIGJlDQpib3RoZXJlZCB3aXRoICJkb21haW5zIiAob3IgYXQgbGVhc3QsIG5vdCB3
aXRoIHNvbWUgZm9yZWlnbiBDQSdzIGlkZWEgb2YNCndoYXQgYSBkb21haW4gaXMpLiAgT2YgdGhl
IHR3byBvcHRpb25zIHVuZGVyIGRpc2N1c3Npb24sIG9wdGlvbiAyIGFsbG93cw0KbW9zdCB2ZXJp
ZmllcnMgdG8gc2ltcGx5IGlnbm9yZSB0aGUgZmFjdCB0aGF0IGEgQ0EgaGFzIGNob3NlbiB0byBp
c3N1ZQ0KdW53YW50ZWQgaGludHMsIGFuZCBqdXN0IHJldHJpZXZlIHRoZSBjZXJ0cyBpdCB3YW50
cyBmcm9tIGEgc2luZ2xlIHBsYWNlLg0KVGhlIGZldyB2ZXJpZmllcnMgdGhhdCB3YW50IHRvIGRv
IHNvbWV0aGluZyB3aXRoIGEgQ0EncyBoaW50cyBjYW4gY2hvb3NlIHRvDQpkbyBzbyB1bmRlciBl
aXRoZXIgb3B0aW9uLCBidXQgb3B0aW9uIDEgd291bGQgZm9yY2UgYWxsIGNsaWVudCBzb2Z0d2Fy
ZSB0bw0KaW5jcmVhc2UgaW4gY29tcGxleGl0eSB0byBnYWluIHRoYXQgY2hvaWNlLiAgT3B0aW9u
IDIgYnVyZGVucyBvbmx5IHRob3NlDQpjbGllbnRzIHRoYXQgd2lzaCB0byBleHBsb2l0IHRoZSBo
aW50cy4NCg0KDQpKb2huDQoNCg0KDQo=

--0__=A7IrhvJHO6YHC08EJcBLPZrtEp3yZTZgRtvF2nXuh7jtqQezTMfX2cl5--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA23308 for ietf-pkix-bks; Fri, 4 Sep 1998 01:26:28 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA23296 for <[e-mail]>; Fri, 4 Sep 1998 01:26:25 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA25196; Fri, 4 Sep 1998 10:32:57 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id KAA16302; Fri, 4 Sep 1998 10:32:58 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 10:32:23 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: TemporalData (Time Stamp Protocol)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA22177 for ietf-pkix-bks; Fri, 4 Sep 1998 01:17:11 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA22167 for <[e-mail]>; Fri, 4 Sep 1998 01:17:09 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA13628; Fri, 4 Sep 1998 10:23:38 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id KAA05764; Fri, 4 Sep 1998 10:23:39 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 10:23:03 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: [e-mail]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA21703 for ietf-pkix-bks; Fri, 4 Sep 1998 01:05:24 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21551 for <[e-mail]>; Fri, 4 Sep 1998 00:59:48 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA12425; Fri, 4 Sep 1998 10:03:56 +0200
Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id KAA22052; Fri, 4 Sep 1998 10:03:56 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 10:03:20 -0700
From: Denis Pinkas <[e-mail]>
Reply-To: [e-mail]
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: [e-mail], "'Santosh Chokhani'" <[e-mail]>
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]
      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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12924 for ietf-pkix-bks; Thu, 3 Sep 1998 23:12:31 -0700 (PDT)
Received: from fw.ssb.it (fw.ssb.it [192.106.128.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA12918 for <[e-mail]>; Thu, 3 Sep 1998 23:12:29 -0700 (PDT)
Received: from notesmail.ssb.it (domino.ssb.it [192.168.19.5]) by ns.ssb.it (8.8.5/8.7.3) with SMTP id KAA02099 for <[e-mail]>; Fri, 4 Sep 1998 10:14:03 +0200 (CEST)
Received: by notesmail.ssb.it(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id C1256675.00231CDF ; Fri, 4 Sep 1998 08:23:31 +0200
X-Lotus-FromDomain: SSB
From: "Andrea Sansone" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 4 Sep 1998 08:21:29 +0200
Subject: for option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA12415 for ietf-pkix-bks; Thu, 3 Sep 1998 21:21:59 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA12411 for <[e-mail]>; Thu, 3 Sep 1998 21:21:52 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R8ZDT79L>; Fri, 4 Sep 1998 14:22:19 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D489@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Frank O'Dwyer'" <[e-mail]>, Dave Horvath <[e-mail]>
Cc: [e-mail]
Subject: RE: path development complexity (was Re: What the straw poll mean s)
Date: Fri, 4 Sep 1998 14:22:16 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, 4 September 1998 12:36
> To:	Dave Horvath
> Cc:	[e-mail]
> 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA12101 for ietf-pkix-bks; Thu, 3 Sep 1998 20:30:18 -0700 (PDT)
Received: from mail1.toronto.istar.net (mail1.toronto.istar.net [209.89.75.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA12097 for <[e-mail]>; Thu, 3 Sep 1998 20:30:11 -0700 (PDT)
Received: from ts55-02.tor.istar.ca ([204.191.148.33] helo=2keys.ca) by mail1.toronto.istar.net with esmtp (Exim 2.02 #1) id 0zEmeE-0007PK-00 for [e-mail]; Thu, 3 Sep 1998 23:34:54 -0400
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 23:31:01 -0400
From: Tony Bates <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11572 for ietf-pkix-bks; Thu, 3 Sep 1998 19:33:51 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11568 for <[e-mail]>; Thu, 3 Sep 1998 19:33:50 -0700 (PDT)
Received: from [158.152.104.114] (helo=brd.ie) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zEllm-00049c-00; Fri, 4 Sep 1998 02:38:39 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Sep 1998 03:35:30 +0100
From: "Frank O'Dwyer" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: Dave Horvath <[e-mail]>
CC: [e-mail]
Subject: path development complexity (was Re: What the straw poll means)
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11432 for ietf-pkix-bks; Thu, 3 Sep 1998 19:01:53 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11427 for <[e-mail]>; Thu, 3 Sep 1998 19:01:45 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R8ZDT787>; Fri, 4 Sep 1998 12:02:05 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D484@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Where to store CA certificates
Date: Fri, 4 Sep 1998 12:02:04 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Friday, 4 September 1998 10:11
> To:	'Ambarish Malpani'; '[e-mail]'
> 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:[e-mail]]
> > Sent:	Thursday, September 03, 1998 12:54 PM
> > To:	'[e-mail]'
> > 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.
> > [e-mail]
> > 1215 Terra Bella Ave.
> http://www.valicert.com
> > Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA10891 for ietf-pkix-bks; Thu, 3 Sep 1998 18:29:34 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA10887 for <[e-mail]>; Thu, 3 Sep 1998 18:29:29 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R8ZDT78T>; Fri, 4 Sep 1998 11:29:45 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D483@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, Carlisle Adams <[e-mail]>
Cc: [e-mail]
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
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

comments in line

> -----Original Message-----
> From:	Ambarish Malpani [SMTP:[e-mail]]
> Sent:	Friday, 4 September 1998 6:41
> To:	Carlisle Adams
> Cc:	[e-mail]
> 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:[e-mail]]
> > > Sent:         Thursday, September 03, 1998 12:14 PM
> > > To:   [e-mail]
> > > Cc:   [e-mail]
> > > 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.
> [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10579 for ietf-pkix-bks; Thu, 3 Sep 1998 17:29:36 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10575 for <[e-mail]>; Thu, 3 Sep 1998 17:29:35 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZW17>; Thu, 3 Sep 1998 20:33:56 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D22B@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 20:33:53 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 8:19 PM
> To:	'[e-mail]'; 'Santosh Chokhani'
> Cc:	[e-mail]
> Subject:	RE: What the straw poll means
> 
>        
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:[e-mail]]
> > Sent: 	September 3, 1998 7:50 PM
> > To: 	'[e-mail]'; Santosh Chokhani
> > Cc: 	[e-mail]
> > 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:	[e-mail] [SMTP:[e-mail]]
> > > Sent:	Thursday, September 03, 1998 8:51 AM
> > > To:	Santosh Chokhani
> > > Cc:	[e-mail]
> > > Subject:	RE: What the straw poll means
> > > 
> > > Santosh Chokhani <[e-mail]> 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
> > > 
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10535 for ietf-pkix-bks; Thu, 3 Sep 1998 17:19:11 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10529 for <[e-mail]>; Thu, 3 Sep 1998 17:19:09 -0700 (PDT)
Received: by gateway.r3.ch id <6801>; Fri, 4 Sep 1998 02:25:16 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 01:19:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 3, 1998 7:50 PM
> To: 	'[e-mail]'; Santosh Chokhani
> Cc: 	[e-mail]
> 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:	[e-mail] [SMTP:[e-mail]]
> > Sent:	Thursday, September 03, 1998 8:51 AM
> > To:	Santosh Chokhani
> > Cc:	[e-mail]
> > Subject:	RE: What the straw poll means
> > 
> > Santosh Chokhani <[e-mail]> 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
> > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10465 for ietf-pkix-bks; Thu, 3 Sep 1998 17:06:35 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10461 for <[e-mail]>; Thu, 3 Sep 1998 17:06:34 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZWAW>; Thu, 3 Sep 1998 20:10:55 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D229@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 20:10:53 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Thursday, September 03, 1998 12:54 PM
> To:	'[e-mail]'
> 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.
> [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10394 for ietf-pkix-bks; Thu, 3 Sep 1998 16:59:54 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10390 for <[e-mail]>; Thu, 3 Sep 1998 16:59:52 -0700 (PDT)
Received: by gateway.r3.ch id <6804>; Fri, 4 Sep 1998 02:05:54 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], [e-mail], "'John Everson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:59:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	John Everson[SMTP:[e-mail]]
> Sent: 	September 3, 1998 10:52 AM
> To: 	[e-mail]; [e-mail]
> Cc: 	[e-mail]
> 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:[e-mail]]
> Sent: Thursday, September 03, 1998 7:51 AM
> To: chokhani
> Cc: John.Wray; ietf-pkix
> Subject: RE: What the straw poll means
> 
> 
> Santosh Chokhani <[e-mail]> 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
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10378 for ietf-pkix-bks; Thu, 3 Sep 1998 16:59:19 -0700 (PDT)
Received: from portalcp.chevron.com ([e-mail] [207.24.17.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10374 for <[e-mail]>; Thu, 3 Sep 1998 16:59:18 -0700 (PDT)
Received: (from uucp@localhost) by portalcp.chevron.com (8.9.1a/8.9.1) id RAA23158 for <[e-mail]>; Thu, 3 Sep 1998 17:03:51 -0700 (PDT)
Received: from orbitcity.sr.chevron.com(146.27.94.253) by portalcp.chevron.com via smap (4.1) id xma023027; Thu, 3 Sep 98 17:03:40 -0700
Received: from chvpk-msxb1.sr.chevron.com (chvpk-msxb1.sr.chevron.com [146.27.94.102]) by orbitcity.chevron.com (8.9.1a/8.9.1) with ESMTP id RAA21084 for <[e-mail]>; Thu, 3 Sep 1998 17:03:35 -0700 (PDT)
Received: by chvpk-msxb1.sr.chevron.com with Internet Mail Service (5.5.1960.3) id <SG6CMP1Q>; Thu, 3 Sep 1998 17:03:35 -0700
Message-ID: <[e-mail]>
From: "Eaton, James (EATO)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 17:01:52 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.proper.com id QAA10375
Sender: [e-mail]
Precedence: bulk

 
 
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10349 for ietf-pkix-bks; Thu, 3 Sep 1998 16:53:54 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10345 for <[e-mail]>; Thu, 3 Sep 1998 16:53:51 -0700 (PDT)
Received: by gateway.r3.ch id <6806>; Fri, 4 Sep 1998 01:59:55 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, Dave Horvath <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:53:58 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 3, 1998 7:41 PM
> To: 	'Bill Burr'; Dave Horvath
> Cc: 	[e-mail]
> 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:[e-mail]]
> > Sent:	Thursday, September 03, 1998 12:48 PM
> > To:	Dave Horvath
> > Cc:	[e-mail]
> > 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 <[e-mail]>
> > >To: [e-mail] <[e-mail]>;
> [e-mail]
> > ><[e-mail]>
> > >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:[e-mail]]
> > >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> > >>>> To: [e-mail]
> > >>>> Cc: [e-mail]
> > >>>> 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
> > >>>> [e-mail]
> > >>>> 1-801-861-7387
> > >>
> > >>
> > >
> > >
> > Regards,
> > 
> > Bill Burr
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10339 for ietf-pkix-bks; Thu, 3 Sep 1998 16:52:58 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10335 for <[e-mail]>; Thu, 3 Sep 1998 16:52:57 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV9J>; Thu, 3 Sep 1998 19:57:18 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D227@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, [e-mail]
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
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From:	Carlisle Adams [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 2:25 PM
> To:	[e-mail]
> 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:[e-mail]]
> > Sent: 	Thursday, September 03, 1998 12:14 PM
> > To: 	[e-mail]
> > Cc: 	[e-mail]
> > 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10316 for ietf-pkix-bks; Thu, 3 Sep 1998 16:48:45 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10312 for <[e-mail]>; Thu, 3 Sep 1998 16:48:43 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV8R>; Thu, 3 Sep 1998 19:53:03 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D226@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Nada Kapidzic Cicovic'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:53:00 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From:	Nada Kapidzic Cicovic [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 5:03 AM
> To:	Santosh Chokhani; 'Bob Jueneman'; [e-mail]
> 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:[e-mail]]
> >> Sent:	Wednesday, September 02, 1998 8:33 PM
> >> To:	[e-mail]
> >> Cc:	[e-mail]
> >> 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
> >> [e-mail]
> >> 1-801-861-7387
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10300 for ietf-pkix-bks; Thu, 3 Sep 1998 16:46:40 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10296 for <[e-mail]>; Thu, 3 Sep 1998 16:46:38 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV8D>; Thu, 3 Sep 1998 19:50:59 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D225@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:50:58 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:	[e-mail] [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 8:51 AM
> To:	Santosh Chokhani
> Cc:	[e-mail]
> Subject:	RE: What the straw poll means
> 
> Santosh Chokhani <[e-mail]> 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
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10264 for ietf-pkix-bks; Thu, 3 Sep 1998 16:41:27 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10259 for <[e-mail]>; Thu, 3 Sep 1998 16:41:25 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <117939>; Thu, 3 Sep 1998 09:57:08 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Thu, 3 Sep 1998 09:51:37 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id JAA13959; Thu, 3 Sep 1998 09:52:30 -0500 (CDT)
From: John Everson <[e-mail]>
X-OpenMail-Hops: 1
Date: Thu, 3 Sep 1998 09:52:26 -0500
Message-Id: <H0001a0e0314a456@MHS>
Subject: RE: What the straw poll means
TO: [e-mail], [e-mail]
CC: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="openmail-part-0ef743e1-00000001"
Sender: [e-mail]
Precedence: bulk

--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:[e-mail]]
Sent: Thursday, September 03, 1998 7:51 AM
To: chokhani
Cc: John.Wray; ietf-pkix
Subject: RE: What the straw poll means


Santosh Chokhani <[e-mail]> 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--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10263 for ietf-pkix-bks; Thu, 3 Sep 1998 16:41:26 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10255 for <[e-mail]>; Thu, 3 Sep 1998 16:41:25 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <116352>; Thu, 3 Sep 1998 11:26:02 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Thu, 3 Sep 1998 11:26:45 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id LAA08023; Thu, 3 Sep 1998 11:27:38 -0500 (CDT)
X-OpenMail-Hops: 1
Date: Thu, 3 Sep 1998 11:27:34 -0500
Message-Id: <H00017cc03153bdb@MHS>
Subject: Option 2
FROM: GIUBILEO/unix////////RFC-822/GIUBILEO#a#SPRINTSEC#f#[e-mail]
TO: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="openmail-part-0ef92b5d-00000001"
Sender: [e-mail]
Precedence: bulk

--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: [phone]
[e-mail]
[PICTURE]


--openmail-part-0ef92b5d-00000001--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10254 for ietf-pkix-bks; Thu, 3 Sep 1998 16:41:24 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10250 for <[e-mail]>; Thu, 3 Sep 1998 16:41:23 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <119676>; Thu, 3 Sep 1998 11:21:53 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Thu, 3 Sep 1998 11:19:38 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id LAA06624 for [e-mail]; Thu, 3 Sep 1998 11:20:03 -0500 (CDT)
From: John Everson <[e-mail]>
X-OpenMail-Hops: 1
Date: Thu, 3 Sep 1998 11:20:00 -0500
Message-Id: <H0001a0e03154315@MHS>
Subject: Voting Question
TO: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="openmail-part-0ef90993-00000001"
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10227 for ietf-pkix-bks; Thu, 3 Sep 1998 16:38:00 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10223 for <[e-mail]>; Thu, 3 Sep 1998 16:37:57 -0700 (PDT)
Received: by gateway.r3.ch id <6804>; Fri, 4 Sep 1998 01:44:05 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Bill Burr <[e-mail]>, "'Dave Horvath'" <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Fri, 4 Sep 1998 00:38:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

	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:[e-mail]]
> Sent: 	September 3, 1998 2:14 PM
> To: 	Bill Burr
> Cc: 	[e-mail]
> 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 <[e-mail]>
> To: Dave Horvath <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> 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 <[e-mail]>
> >>To: [e-mail] <[e-mail]>; [e-mail]
> >><[e-mail]>
> >>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:[e-mail]]
> >>>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>>> To: [e-mail]
> >>>>> Cc: [e-mail]
> >>>>> 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
> >>>>> [e-mail]
> >>>>> 1-801-861-7387
> >>>
> >>>
> >>
> >>
> >Regards,
> >
> >Bill Burr
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10215 for ietf-pkix-bks; Thu, 3 Sep 1998 16:37:21 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10211 for <[e-mail]>; Thu, 3 Sep 1998 16:37:18 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZV6T>; Thu, 3 Sep 1998 19:41:38 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D224@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, Dave Horvath <[e-mail]>
Cc: [e-mail]
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 19:41:37 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Thursday, September 03, 1998 12:48 PM
> To:	Dave Horvath
> Cc:	[e-mail]
> 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 <[e-mail]>
> >To: [e-mail] <[e-mail]>; [e-mail]
> ><[e-mail]>
> >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:[e-mail]]
> >>>> Sent: Wednesday, September 02, 1998 8:33 PM
> >>>> To: [e-mail]
> >>>> Cc: [e-mail]
> >>>> 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
> >>>> [e-mail]
> >>>> 1-801-861-7387
> >>
> >>
> >
> >
> Regards,
> 
> Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10138 for ietf-pkix-bks; Thu, 3 Sep 1998 16:24:42 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10134 for <[e-mail]>; Thu, 3 Sep 1998 16:24:41 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZVZ4>; Thu, 3 Sep 1998 19:29:01 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D222@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Carlisle Adams <[e-mail]>, [e-mail]
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
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:	[e-mail] [SMTP:[e-mail]]
> Sent:	Thursday, September 03, 1998 5:09 PM
> To:	Carlisle Adams; [e-mail]
> 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10018 for ietf-pkix-bks; Thu, 3 Sep 1998 16:08:07 -0700 (PDT)
Received: from tac-nt-excom1.russell.com (mailgate1.russell.com [208.152.45.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10014 for <[e-mail]>; Thu, 3 Sep 1998 16:08:06 -0700 (PDT)
Received: by tac-nt-excom1.russell.com with Internet Mail Service (5.5.2232.9) id <S17JTY5D>; Thu, 3 Sep 1998 16:10:21 -0700
Message-ID: <[e-mail]>
From: "Tuttle, Kimberly (OSSC)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2.
Date: Thu, 3 Sep 1998 16:10:29 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09871 for ietf-pkix-bks; Thu, 3 Sep 1998 15:50:23 -0700 (PDT)
Received: from tac-nt-excom1.russell.com (mailgate1.russell.com [208.152.45.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09867 for <[e-mail]>; Thu, 3 Sep 1998 15:50:22 -0700 (PDT)
Received: by tac-nt-excom1.russell.com with Internet Mail Service (5.5.2232.9) id <S17JTYV0>; Thu, 3 Sep 1998 15:52:36 -0700
Message-ID: <[e-mail]>
From: "Evans,  Jim (OSSC)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 15:52:45 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Evans
Frank Russell Company

Security is what YOU Practice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09496 for ietf-pkix-bks; Thu, 3 Sep 1998 15:05:28 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09492 for <[e-mail]>; Thu, 3 Sep 1998 15:05:26 -0700 (PDT)
Received: by gateway.r3.ch id <6814>; Fri, 4 Sep 1998 00:11:30 +0100
Message-Id: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
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
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Ryan,

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Sent: 	Thursday, September 03, 1998 5:09 PM
> To: 	Carlisle Adams; [e-mail]
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09480 for ietf-pkix-bks; Thu, 3 Sep 1998 15:04:31 -0700 (PDT)
Received: from fep2.mail.ozemail.net (fep2.mail.ozemail.net [203.2.192.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09476 for <[e-mail]>; Thu, 3 Sep 1998 15:04:29 -0700 (PDT)
Received: from lesm95 (slcan52p02.ozemail.com.au [203.108.176.130]) by fep2.mail.ozemail.net (8.9.0/8.6.12) with SMTP id IAA11167 for <[e-mail]>; Fri, 4 Sep 1998 08:09:16 +1000 (EST)
Message-ID: <000b01bdd787$498d5d80$82b06ccb@lesm95>
From: "Les Mitchell" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Fri, 4 Sep 1998 08:07:40 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA09198 for ietf-pkix-bks; Thu, 3 Sep 1998 14:30:43 -0700 (PDT)
Received: from att.com (cagw2.att.com [192.128.52.90]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA09194 for <[e-mail]>; Thu, 3 Sep 1998 14:30:41 -0700 (PDT)
Received: from caig1.fw.att.com by cagw2.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-pkix sender qsun.ho.att.com!jayhawk (qsun.ho.att.com!jayhawk); Thu Sep  3 17:05 EDT 1998
Received: from qsun.ho.att.com (qsunn.ho.att.com [135.16.30.2]) by caig1.fw.att.com (AT&T/IPNS/GW-1.0) with SMTP id RAA02720 for <[e-mail]>; Thu, 3 Sep 1998 17:09:04 -0400 (EDT)
Received: by qsun.ho.att.com (SMI-8.6/EMS-1.2 sol2) id RAA27748; Thu, 3 Sep 1998 17:09:01 -0400
Date: Thu, 3 Sep 1998 17:09:01 -0400
Message-Id: <[e-mail]>
From: [e-mail] (Ryan Moats)
To: Carlisle Adams <[e-mail]>, [e-mail]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
Content-Type: text
Sender: [e-mail]
Precedence: bulk

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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08976 for ietf-pkix-bks; Thu, 3 Sep 1998 14:05:48 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA08972 for <[e-mail]>; Thu, 3 Sep 1998 14:05:47 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id RAA08361 for <[e-mail]>; Thu, 3 Sep 1998 17:10:25 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 03 Sep 1998 17:14:02 -0400
To: [e-mail]
From: Bill Burr <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08900 for ietf-pkix-bks; Thu, 3 Sep 1998 13:58:53 -0700 (PDT)
Received: from dtol.com ([e-mail] [206.51.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA08895 for <[e-mail]>; Thu, 3 Sep 1998 13:58:52 -0700 (PDT)
Received: from dtol.com (cyborg.dilkie.com [206.51.1.171]) by dtol.com (8.6.12/8.6.9) with ESMTP id RAA03433 for <[e-mail]>; Thu, 3 Sep 1998 17:07:44 GMT
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 17:02:06 -0400
From: Susan Lang <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08759 for ietf-pkix-bks; Thu, 3 Sep 1998 13:48:36 -0700 (PDT)
Received: from egate2.citicorp.com (egate2.citicorp.com [192.193.196.194]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA08755 for <[e-mail]>; Thu, 3 Sep 1998 13:48:35 -0700 (PDT)
Received: by egate2.citicorp.com id QAA00653 (InterLock SMTP Gateway 3.0 for [e-mail]); Thu, 3 Sep 1998 16:53:15 -0400
Message-Id: <[e-mail]>
Received: by egate2.citicorp.com (Protected-side Proxy Mail Agent-1); Thu, 3 Sep 1998 16:53:15 -0400
Date: Thu, 03 Sep 1998 16:52:36 -0400
From: David Solo <[e-mail]>
Reply-To: [e-mail]
Organization: Citicorp
X-Sender: "David Solo" <[e-mail]>
X-Mailer: Mozilla 4.04 [en]C-Citicorp  (WinNT; U)
Mime-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08394 for ietf-pkix-bks; Thu, 3 Sep 1998 13:36:31 -0700 (PDT)
Received: from atlantic.valicert.com (atlantic.valicert.com [209.185.6.135] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA08390 for <[e-mail]>; Thu, 3 Sep 1998 13:36:30 -0700 (PDT)
Received: (qmail 27414 invoked from network); 3 Sep 1998 20:41:06 -0000
Received: from amazon.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 3 Sep 1998 20:41:06 -0000
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 13:41:00 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: [e-mail]
Subject: Re: Let's try to understand the real issue (was... RE: What the straw poll means)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> > Sent:         Thursday, September 03, 1998 12:14 PM
> > To:   [e-mail]
> > Cc:   [e-mail]
> > 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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08321 for ietf-pkix-bks; Thu, 3 Sep 1998 13:34:47 -0700 (PDT)
Received: from host.ott.igs.net (host.ott.igs.net [206.248.16.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08313 for <[e-mail]>; Thu, 3 Sep 1998 13:34:42 -0700 (PDT)
Received: from igs.net (ttyE0a.ott.igs.net [207.210.11.12]) by host.ott.igs.net (8.8.5/8.6.12) with ESMTP id QAA04133 for <[e-mail]>; Thu, 3 Sep 1998 16:39:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 16:33:13 -0400
From: Robert Sabourin <[e-mail]>
Organization: TBS TechWatch
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06917 for ietf-pkix-bks; Thu, 3 Sep 1998 11:55:53 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06913 for <[e-mail]>; Thu, 3 Sep 1998 11:55:52 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQffgu13666; Thu, 3 Sep 1998 15:00:39 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRBJKA>; Thu, 3 Sep 1998 15:02:21 -0400
Message-ID: <[e-mail]>
From: GMurphy <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Option 2
Date: Thu, 3 Sep 1998 15:02:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06657 for ietf-pkix-bks; Thu, 3 Sep 1998 11:25:03 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06653 for <[e-mail]>; Thu, 3 Sep 1998 11:25:01 -0700 (PDT)
Received: by gateway.r3.ch id <6799>; Thu, 3 Sep 1998 20:31:12 +0100
Message-Id: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail]
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
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi all,

I propose that we try (once again) to understand what the real issue is
here.

> ----------
> From: 	Ryan Moats[SMTP:[e-mail]]
> Sent: 	Thursday, September 03, 1998 12:14 PM
> To: 	[e-mail]
> Cc: 	[e-mail]
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06580 for ietf-pkix-bks; Thu, 3 Sep 1998 11:19:46 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06576 for <[e-mail]>; Thu, 3 Sep 1998 11:19:44 -0700 (PDT)
Received: from ash (ash.chromatix.com [207.97.115.9]) by chromatix.com (8.8.8/8.8.8) with SMTP id OAA21961; Thu, 3 Sep 1998 14:23:52 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <00f701bdd766$a98bcf30$[e-mail]>
From: "Dave Horvath" <[e-mail]>
To: "Bill Burr" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 14:14:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

    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 <[e-mail]>
To: Dave Horvath <[e-mail]>
Cc: [e-mail] <[e-mail]>
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 <[e-mail]>
>>To: [e-mail] <[e-mail]>; [e-mail]
>><[e-mail]>
>>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:[e-mail]]
>>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>>> To: [e-mail]
>>>>> Cc: [e-mail]
>>>>> 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
>>>>> [e-mail]
>>>>> 1-801-861-7387
>>>
>>>
>>
>>
>Regards,
>
>Bill Burr
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06389 for ietf-pkix-bks; Thu, 3 Sep 1998 10:59:08 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06385 for <[e-mail]>; Thu, 3 Sep 1998 10:59:06 -0700 (PDT)
Received: by gateway.r3.ch id <6807>; Thu, 3 Sep 1998 20:05:15 +0100
Message-Id: <[e-mail]>
From: Rainer Rueppel <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Thu, 3 Sep 1998 19:01:41 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06098 for ietf-pkix-bks; Thu, 3 Sep 1998 10:26:28 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06094 for <[e-mail]>; Thu, 3 Sep 1998 10:26:25 -0700 (PDT)
Received: by gateway.r3.ch id <6804>; Thu, 3 Sep 1998 19:32:13 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Subject: RE: Where to store CA certificates
Date: Thu, 3 Sep 1998 18:26:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Ambarish Malpani[SMTP:[e-mail]]
> Sent: 	September 3, 1998 12:54 PM
> To: 	'[e-mail]'
> 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.
> [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05571 for ietf-pkix-bks; Thu, 3 Sep 1998 09:49:59 -0700 (PDT)
Received: from atlantic.valicert.com (atlantic.valicert.com [209.185.6.135] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA05566 for <[e-mail]>; Thu, 3 Sep 1998 09:49:58 -0700 (PDT)
Received: (qmail 24860 invoked from network); 3 Sep 1998 16:54:25 -0000
Received: from amazon.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 3 Sep 1998 16:54:25 -0000
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 09:54:19 -0700
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Where to store CA certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05522 for ietf-pkix-bks; Thu, 3 Sep 1998 09:46:08 -0700 (PDT)
Received: from chopin.digsigtrust.com (chopin.digsigtrust.com [208.30.64.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA05518 for <[e-mail]>; Thu, 3 Sep 1998 09:46:07 -0700 (PDT)
Received: from digsigtrust.com (rfwdesktop.digsigtrust.com [208.30.64.114]) by chopin.digsigtrust.com (8.9.1/8.9.1) with ESMTP id KAA12051 for <[e-mail]>; Thu, 3 Sep 1998 10:50:13 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 11:14:45 -0600
From: "Russel F. Weiser" <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------4DB9C958A073A47F89771625"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone]
> http://www.entrust.com            Fax: [phone]
>
>
> > ----------
> > From:         Santosh Chokhani[SMTP:[e-mail]]
> > Sent:         September 2, 1998 8:48 PM
> > To:   'Bob Jueneman'; [e-mail]
> > 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:[e-mail]]
> > > Sent:       Wednesday, September 02, 1998 8:33 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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
> > > [e-mail]
> > > 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: [e-mail]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------4DB9C958A073A47F89771625--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05452 for ietf-pkix-bks; Thu, 3 Sep 1998 09:40:08 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA05448 for <[e-mail]>; Thu, 3 Sep 1998 09:40:07 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id MAA05240; Thu, 3 Sep 1998 12:44:14 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 03 Sep 1998 12:47:53 -0400
To: "Dave Horvath" <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: What the straw poll means
Cc: [e-mail]
In-Reply-To: <008001bdd74d$95b14bc0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
>To: [e-mail] <[e-mail]>; [e-mail]
><[e-mail]>
>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:[e-mail]]
>>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>>> To: [e-mail]
>>>> Cc: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> 1-801-861-7387
>>
>>
>
>
Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05420 for ietf-pkix-bks; Thu, 3 Sep 1998 09:37:57 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA05416 for <[e-mail]>; Thu, 3 Sep 1998 09:37:56 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Thu, 03 Sep 1998 10:42:00 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 03 Sep 1998 10:41:47 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: What the straw poll means
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA05417
Sender: [e-mail]
Precedence: bulk

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05400 for ietf-pkix-bks; Thu, 3 Sep 1998 09:36:11 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA05396 for <[e-mail]>; Thu, 3 Sep 1998 09:36:10 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQffgk13897; Thu, 3 Sep 1998 12:40:21 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRB215>; Thu, 3 Sep 1998 12:42:33 -0400
Message-ID: <[e-mail]>
From: WHenry <[e-mail]>
To: [e-mail]
Subject: For Option #2
Date: Thu, 3 Sep 1998 12:42:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04949 for ietf-pkix-bks; Thu, 3 Sep 1998 09:27:37 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04942 for <[e-mail]>; Thu, 3 Sep 1998 09:27:35 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-US Robotics) id LAA09323; Thu, 3 Sep 1998 11:36:23 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 86256674.005B319B ; Thu, 3 Sep 1998 11:36:04 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Boby Joseph" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 3 Sep 1998 11:36:24 -0500
Subject: For option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04631 for ietf-pkix-bks; Thu, 3 Sep 1998 09:25:19 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04623 for <[e-mail]>; Thu, 3 Sep 1998 09:25:18 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA23905 for <[e-mail]>; Thu, 3 Sep 1998 12:30:05 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011704b214746ad0fe@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Thu, 3 Sep 1998 12:32:04 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: What the straw poll means
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA03056 for ietf-pkix-bks; Thu, 3 Sep 1998 09:09:07 -0700 (PDT)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA03051 for <[e-mail]>; Thu, 3 Sep 1998 09:09:05 -0700 (PDT)
Received: from kcig1.fw.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-pkix sender att.com!jayhawk (att.com!jayhawk); Thu Sep  3 11:12 CDT 1998
Received: from qsun.ho.att.com (qsunn.ho.att.com [135.16.30.2]) by kcig1.fw.att.com (AT&T/IPNS/GW-1.0) with SMTP id LAA02486 for <[e-mail]>; Thu, 3 Sep 1998 11:12:13 -0500 (CDT)
Received: from sloop.local.windrose.omaha.ne.us by qsun.ho.att.com (SMI-8.6/EMS-1.2 sol2) id MAA15045; Thu, 3 Sep 1998 12:12:00 -0400
From: "Ryan Moats" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Retrieval efficiency herring? (was... RE: What the straw poll means)
Date: Thu, 3 Sep 1998 11:14:31 -0500
Message-ID: <000101bdd755$ef033a00$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

[e-mail] writes:

> Santosh Chokhani <[e-mail]> 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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02866 for ietf-pkix-bks; Thu, 3 Sep 1998 08:46:32 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02862 for <[e-mail]>; Thu, 3 Sep 1998 08:46:31 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090311504488:1045  for <[e-mail]> ; Thu, 3 Sep 1998 11:50:44 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090311504488:1045  for <[e-mail]> ; Thu, 3 Sep 1998 11:50:44 -0400 
X-Lotus-FromDomain: IRIS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 3 Sep 1998 11:53:53 -0400
Subject: For Option 2
x-notes-Form: Memo
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02506 for ietf-pkix-bks; Thu, 3 Sep 1998 08:20:25 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02502 for <[e-mail]>; Thu, 3 Sep 1998 08:20:24 -0700 (PDT)
Received: from ash (ash.chromatix.com [207.97.115.9]) by chromatix.com (8.8.8/8.8.8) with SMTP id LAA21436; Thu, 3 Sep 1998 11:24:22 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <008001bdd74d$95b14bc0$[e-mail]>
From: "Dave Horvath" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: What the straw poll means
Date: Thu, 3 Sep 1998 11:14:45 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
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:[e-mail]]
>>> Sent: Wednesday, September 02, 1998 8:33 PM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> 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
>>> [e-mail]
>>> 1-801-861-7387
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02269 for ietf-pkix-bks; Thu, 3 Sep 1998 08:04:30 -0700 (PDT)
Received: from war.wyeth.com (ramail1.labs.wyeth.com [155.94.101.101] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA02265 for <[e-mail]>; Thu, 3 Sep 1998 08:04:22 -0700 (PDT)
Received: from USRA08-Message_Server by war.wyeth.com with Novell_GroupWise; Thu, 03 Sep 1998 11:08:48 -0400
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 03 Sep 1998 11:08:28 -0400
From: Peter Lindstrom <[e-mail]>
To: [e-mail]
Subject: For Option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01888 for ietf-pkix-bks; Thu, 3 Sep 1998 07:29:48 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01883 for <[e-mail]>; Thu, 3 Sep 1998 07:29:46 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id KAA21240; Thu, 3 Sep 1998 10:33:54 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 10:33:58 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: [e-mail]
CC: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

See comment below.

[e-mail] wrote:
> 
> Santosh Chokhani <[e-mail]> 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. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01852 for ietf-pkix-bks; Thu, 3 Sep 1998 07:26:05 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA01848 for <[e-mail]>; Thu, 3 Sep 1998 07:26:04 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA03719; Thu, 3 Sep 1998 10:30:39 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 03 Sep 1998 10:34:19 -0400
To: "Bob Jueneman" <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: What the straw poll means
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01521 for ietf-pkix-bks; Thu, 3 Sep 1998 06:54:16 -0700 (PDT)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA01517 for <[e-mail]>; Thu, 3 Sep 1998 06:54:15 -0700 (PDT)
Received: from GRIMM.BBN.COM by COLUMBIA.BBN.COM id aa11646; 3 Sep 98 9:55 EDT
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 09:56:48 -0400
From: Susan Joseph <[e-mail]>
Reply-To: [e-mail]
Organization: BBN
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

--
Susan Joseph
GTE Internetworking
9810 Patuxent Woods Drive
Columbia, MD 21046
Tel:  [phone]
Fax: [phone]
E-Mail:  [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01462 for ietf-pkix-bks; Thu, 3 Sep 1998 06:48:47 -0700 (PDT)
Received: from callisto.eci-esyst.com ([205.129.215.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA01458 for <[e-mail]>; Thu, 3 Sep 1998 06:48:45 -0700 (PDT)
Date: 3 Sep 1998 08:52:29 -0400
Subject: For Option 1
To: "PKIX Mail List" <[e-mail]>
X-Mailer: Mail*Link SMTP-QM 4.1.0
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body"
From: "Chris Francis" <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA01459
Sender: [e-mail]
Precedence: bulk

                                             Inter-Office Memo
                                      For Option 1

Chris Francis
Raytheon Systems



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA00872 for ietf-pkix-bks; Thu, 3 Sep 1998 05:49:16 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA00868 for <[e-mail]>; Thu, 3 Sep 1998 05:49:15 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id IAA20701; Thu, 3 Sep 1998 08:53:15 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 08:53:19 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: Nada Kapidzic Cicovic <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
Subject: Re: What the straw poll means
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> >> Sent:        Wednesday, September 02, 1998 8:33 PM
> >> To:  [e-mail]
> >> Cc:  [e-mail]
> >> 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
> >> [e-mail]
> >> 1-801-861-7387
> >

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA00808 for ietf-pkix-bks; Thu, 3 Sep 1998 05:43:05 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA00804 for <[e-mail]>; Thu, 3 Sep 1998 05:43:04 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090308471794:820  for <[e-mail]> , <[e-mail]> ; Thu, 3 Sep 1998 08:47:17 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090308471794:820  for <[e-mail]> , <[e-mail]> ; Thu, 3 Sep 1998 08:47:17 -0400 
X-Lotus-FromDomain: IRIS
To: Santosh Chokhani <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 3 Sep 1998 08:50:38 -0400
Subject: RE: What the straw poll means
Mime-Version: 1.0
x-notes-Form: Memo
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: [e-mail]
Precedence: bulk

Santosh Chokhani <[e-mail]> 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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA00646 for ietf-pkix-bks; Thu, 3 Sep 1998 05:23:58 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA00642 for <[e-mail]>; Thu, 3 Sep 1998 05:23:57 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id IAA20594; Thu, 3 Sep 1998 08:27:46 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 08:27:50 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: Sean Mullan <[e-mail]>
CC: Sharon Boeyen <[e-mail]>, [e-mail]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone]
> > http://www.entrust.com            Fax: [phone]
> >
> >
> > > ----------
> > > From:         Bob Jueneman[SMTP:[e-mail]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [e-mail]; [e-mail]; [e-mail]
> > > 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. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00488 for ietf-pkix-bks; Thu, 3 Sep 1998 04:53:43 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00484 for <[e-mail]>; Thu, 3 Sep 1998 04:53:42 -0700 (PDT)
Received: from chromatix.com (palm.chromatix.com [207.97.115.21]) by chromatix.com (8.8.8/8.8.8) with ESMTP id HAA20517 for <[e-mail]>; Thu, 3 Sep 1998 07:57:51 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1998 08:00:17 -0400
From: Richard Pimental <[e-mail]>
Organization: Chromatix, Inc.
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Content-Type: multipart/mixed; boundary="------------BBC97F524D955BDFBA611C8B"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
title:          Software Engineer
tel;work:       [phone]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------BBC97F524D955BDFBA611C8B--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00358 for ietf-pkix-bks; Thu, 3 Sep 1998 04:34:51 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00354 for <[e-mail]>; Thu, 3 Sep 1998 04:34:49 -0700 (PDT)
Received: by gateway.r3.ch id <6803>; Thu, 3 Sep 1998 13:40:59 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], "'Santosh Chokhani'" <[e-mail]>
Subject: RE: What the straw poll means
Date: Thu, 3 Sep 1998 12:35:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 2, 1998 8:48 PM
> To: 	'Bob Jueneman'; [e-mail]
> 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:[e-mail]]
> > Sent:	Wednesday, September 02, 1998 8:33 PM
> > To:	[e-mail]
> > Cc:	[e-mail]
> > 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
> > [e-mail]
> > 1-801-861-7387
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00104 for ietf-pkix-bks; Thu, 3 Sep 1998 04:04:33 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00100 for <[e-mail]>; Thu, 3 Sep 1998 04:04:30 -0700 (PDT)
Received: by gateway.r3.ch id <6803>; Thu, 3 Sep 1998 13:10:35 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Sharon Boeyen <[e-mail]>, "'Sean Mullan'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX  LDAPv2 schema I-D
Date: Thu, 3 Sep 1998 11:57:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Sean Mullan[SMTP:[e-mail]]
> Sent: 	September 2, 1998 4:32 PM
> To: 	Sharon Boeyen
> Cc: 	[e-mail]
> 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:[e-mail]  Tel: [phone]
> > http://www.entrust.com            Fax: [phone]
> > 
> > 
> > > ----------
> > > From:         Bob Jueneman[SMTP:[e-mail]]
> > > Sent:         September 1, 1998 7:20 PM
> > > To:   [e-mail]; [e-mail]; [e-mail]
> > > 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
> > >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA27382 for ietf-pkix-bks; Thu, 3 Sep 1998 02:02:08 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27378 for <[e-mail]>; Thu, 3 Sep 1998 02:02:06 -0700 (PDT)
Received: from jimmie ([10.0.0.22]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id LAA10604; Thu, 3 Sep 1998 11:02:05 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 03 Sep 1998 11:02:39 +0200
To: Santosh Chokhani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: RE: What the straw poll means
Cc: Santosh Chokhani <[e-mail]>
In-Reply-To: <51BF55C30B4FD1118B4900207812701E16D21E@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[e-mail]
>> Cc:	[e-mail]
>> 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
>> [e-mail]
>> 1-801-861-7387
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA01178 for ietf-pkix-bks; Wed, 2 Sep 1998 18:05:36 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA01174 for <[e-mail]>; Wed, 2 Sep 1998 18:05:34 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Wed, 02 Sep 1998 19:09:51 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 02 Sep 1998 19:09:16 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: What the straw poll means
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id SAA01175
Sender: [e-mail]
Precedence: bulk

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:[e-mail]] 
>> Sent:	Wednesday, September 02, 1998 8:33 PM
>> To:	[e-mail] 
>> Cc:	[e-mail] 
>> 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
>> [e-mail] 
>> 1-801-861-7387



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA00961 for ietf-pkix-bks; Wed, 2 Sep 1998 17:43:57 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA00957 for <[e-mail]>; Wed, 2 Sep 1998 17:43:55 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1TZ3RTW>; Wed, 2 Sep 1998 20:48:07 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D21E@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: Santosh Chokhani <[e-mail]>
Subject: RE: What the straw poll means
Date: Wed, 2 Sep 1998 20:48:05 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 02, 1998 8:33 PM
> To:	[e-mail]
> Cc:	[e-mail]
> 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
> [e-mail]
> 1-801-861-7387


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA00925 for ietf-pkix-bks; Wed, 2 Sep 1998 17:39:04 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA00921 for <[e-mail]>; Wed, 2 Sep 1998 17:39:03 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Wed, 02 Sep 1998 18:43:13 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 02 Sep 1998 18:42:40 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA00922
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA00862 for ietf-pkix-bks; Wed, 2 Sep 1998 17:29:02 -0700 (PDT)
Received: from prv-mail25.provo.novelll.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA00858 for <[e-mail]>; Wed, 2 Sep 1998 17:29:01 -0700 (PDT)
Received: from INET-PRV1-Message_Server by prv-mail25.provo.novelll.com with Novell_GroupWise; Wed, 02 Sep 1998 18:33:06 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 02 Sep 1998 18:33:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: What the straw poll means
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA00859
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
1-801-861-7387


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00484 for ietf-pkix-bks; Wed, 2 Sep 1998 16:33:42 -0700 (PDT)
Received: from dc.jones.com ([206.156.0.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA00480 for <[e-mail]>; Wed, 2 Sep 1998 16:33:40 -0700 (PDT)
Received: from dc.jones.com (cm0714h.jones.com [208.159.209.173]) by dc.jones.com (8.8.8/8.8.8) with ESMTP id TAA11700 for <[e-mail]>; Wed, 2 Sep 1998 19:35:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 19:35:39 -0400
From: bgmiller <[e-mail]>
Reply-To: [e-mail]
Organization: Jones Internet Channel
X-Mailer: Mozilla 4.05 [en]C-JIC-DC  (Win95; I)
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29792 for ietf-pkix-bks; Wed, 2 Sep 1998 15:56:02 -0700 (PDT)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29788 for <[e-mail]>; Wed, 2 Sep 1998 15:56:00 -0700 (PDT)
Received: from cwallace (jazzhive.erols.com [207.96.124.71]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id TAA11116 for <[e-mail]>; Wed, 2 Sep 1998 19:00:06 -0400 (EDT)
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 19:19:11 -0400
Message-ID: <01bdd6c8$17c917e0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BDD6A6.90B777E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29757 for ietf-pkix-bks; Wed, 2 Sep 1998 15:53:24 -0700 (PDT)
Received: from mail-oak-1.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29753 for <[e-mail]>; Wed, 2 Sep 1998 15:53:23 -0700 (PDT)
Received: from sfns01.hewm.com ([206.189.8.8]) by mail-oak-1.pilot.net with ESMTP id PAA23446 for <[e-mail]>; Wed, 2 Sep 1998 15:58:07 -0700 (PDT)
Received: by SFNS01 with Internet Mail Service (5.5.1960.3) id <RH9AD63X>; Wed, 2 Sep 1998 15:58:07 -0700
Message-ID: <422B07DB41D7D111B9AF00805F19B04C2BB524@SFNS01>
From: "Maloney, Teresa A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 15:58:03 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Thanks


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29732 for ietf-pkix-bks; Wed, 2 Sep 1998 15:47:08 -0700 (PDT)
Received: from mail.sprint.com (mail.sprint.com [208.4.28.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29728 for <[e-mail]>; Wed, 2 Sep 1998 15:47:07 -0700 (PDT)
Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <114634>; Wed, 2 Sep 1998 17:50:51 -0500
Received: from [144.223.148.154] by sii01.mail.sprint.com with ESMTP; Wed, 2 Sep 1998 17:51:42 -0500
Received: from localhost (root@localhost) by kcopmp01.corp.sprint.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id RAA20639 for [e-mail]; Wed, 2 Sep 1998 17:52:36 -0500 (CDT)
From: John Everson <[e-mail]>
X-OpenMail-Hops: 1
Date: Wed, 2 Sep 1998 17:52:31 -0500
Message-Id: <H0001a0e0313ef37@MHS>
Subject: For Option 2
TO: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29140 for ietf-pkix-bks; Wed, 2 Sep 1998 14:18:33 -0700 (PDT)
Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29136 for <[e-mail]>; Wed, 2 Sep 1998 14:18:32 -0700 (PDT)
Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id QAA34790 for <[e-mail]>; Wed, 2 Sep 1998 16:07:53 -0500
Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 2 Sep 1998 16:23:07 -0500
Message-ID: <c=US%a=MCI%p=SHL%l=[e-mail]>
From: "PACHL, Jan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 16:22:19 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29086 for ietf-pkix-bks; Wed, 2 Sep 1998 14:13:32 -0700 (PDT)
Received: from mail.spyrus.com.au (fwuser@[203.37.128.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29081 for <[e-mail]>; Wed, 2 Sep 1998 14:13:26 -0700 (PDT)
Message-ID: <A1019E9C2D34D211A501006008C204506FAC@MAIL>
From: Charles Moore <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: for Option 1
Date: Thu, 3 Sep 1998 07:03:54 +1000 
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29024 for ietf-pkix-bks; Wed, 2 Sep 1998 14:09:13 -0700 (PDT)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29020 for <[e-mail]>; Wed, 2 Sep 1998 14:09:12 -0700 (PDT)
Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id RAA56410 for <[e-mail]>; Wed, 2 Sep 1998 17:03:09 -0400
Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id RAA36166 for <[e-mail]>; Wed, 2 Sep 1998 17:12:53 -0400
Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU014 id 5040300019930751; Wed, 2 Sep 1998 17:09:46 -0400
From: MA Crane <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Message-ID: <5040300019930751000002L012*@MHS>
Date: Wed, 2 Sep 1998 17:09:46 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28896 for ietf-pkix-bks; Wed, 2 Sep 1998 13:55:12 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28892 for <[e-mail]>; Wed, 2 Sep 1998 13:55:11 -0700 (PDT)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id <RWPXR37C>; Wed, 2 Sep 1998 13:59:24 -0700
Message-ID: <D70342829C12D2119D0700805FBECA2FC79AF0@RED-MSG-55>
From: Rick Johnson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:59:20 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28703 for ietf-pkix-bks; Wed, 2 Sep 1998 13:28:05 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA28698 for <[e-mail]>; Wed, 2 Sep 1998 13:28:04 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA03697; Wed, 2 Sep 1998 13:32:16 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA05825; Wed, 2 Sep 1998 16:32:04 -0400
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA22112; Wed, 2 Sep 1998 16:32:04 -0400
Received: from east.sun.com by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA21764; Wed, 2 Sep 1998 16:32:02 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 16:32:03 -0400
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.5b1 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: [e-mail]
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX  LDAPv2 schema I-D
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone]
> http://www.entrust.com            Fax: [phone]
> 
> 
> > ----------
> > From:         Bob Jueneman[SMTP:[e-mail]]
> > Sent:         September 1, 1998 7:20 PM
> > To:   [e-mail]; [e-mail]; [e-mail]
> > 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
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27945 for ietf-pkix-bks; Wed, 2 Sep 1998 11:50:59 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27941 for <[e-mail]>; Wed, 2 Sep 1998 11:50:58 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1BY50L2>; Wed, 2 Sep 1998 14:55:09 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E0EC4A7@WUHER>
From: Kenneth Eggers <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 14:55:08 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Kenneth W. Eggers  <[e-mail]> http://www.cygnacom.com
CygnaCom Solutions, Inc.  
7927 Jones Branch Drive, Suite 100 West
McLean, VA  22102
[phone]x228  fax: [phone]                    



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27858 for ietf-pkix-bks; Wed, 2 Sep 1998 11:40:48 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27854 for <[e-mail]>; Wed, 2 Sep 1998 11:40:46 -0700 (PDT)
Received: by gateway.r3.ch id <6802>; Wed, 2 Sep 1998 20:46:47 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, [e-mail], [e-mail], "'Bob Jueneman'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 19:40:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	September 2, 1998 2:17 PM
> To: 	'Sharon Boeyen'; [e-mail]; [e-mail]; '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:[e-mail]]
> > Sent:	Wednesday, September 02, 1998 8:46 AM
> > To:	[e-mail]; [e-mail]; '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:[e-mail]  Tel: [phone] 
> > http://www.entrust.com            Fax: [phone] 
> >        
> > 
> > 
> > > ----------
> > > From: 	Bob Jueneman[SMTP:[e-mail]]
> > > Sent: 	September 1, 1998 7:20 PM
> > > To: 	[e-mail]; [e-mail]; [e-mail]
> > > 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
> > > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27837 for ietf-pkix-bks; Wed, 2 Sep 1998 11:37:20 -0700 (PDT)
Received: from krusty.rosenquist.com (cr462639-a.flfrd1.on.wave.home.com [24.112.89.61]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27833 for <[e-mail]>; Wed, 2 Sep 1998 11:37:19 -0700 (PDT)
Received: by krusty.rosenquist.com with Internet Mail Service (5.5.1960.3) id <RTZXP18A>; Wed, 2 Sep 1998 14:42:03 -0400
Message-ID: <[e-mail]>
From: Eric Rosenquist <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 14:42:00 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDD6A1.5ED91770"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27631 for ietf-pkix-bks; Wed, 2 Sep 1998 11:13:11 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27627 for <[e-mail]>; Wed, 2 Sep 1998 11:13:09 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1BY50GJ>; Wed, 2 Sep 1998 14:17:20 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D219@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, [e-mail], [e-mail], "'Bob Jueneman'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 14:17:18 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent:	Wednesday, September 02, 1998 8:46 AM
> To:	[e-mail]; [e-mail]; '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:[e-mail]  Tel: [phone] 
> http://www.entrust.com            Fax: [phone] 
>        
> 
> 
> > ----------
> > From: 	Bob Jueneman[SMTP:[e-mail]]
> > Sent: 	September 1, 1998 7:20 PM
> > To: 	[e-mail]; [e-mail]; [e-mail]
> > 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
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA27427 for ietf-pkix-bks; Wed, 2 Sep 1998 10:57:12 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA27423 for <[e-mail]>; Wed, 2 Sep 1998 10:57:11 -0700 (PDT)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id <RWP6JHY3>; Wed, 2 Sep 1998 11:01:25 -0700
Message-ID: <61AC5C9A4B9CD11181A200805F57CD5403F46D21@RED-MSG-44>
From: Peter Brundrett <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 11:01:16 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA27149 for ietf-pkix-bks; Wed, 2 Sep 1998 10:31:11 -0700 (PDT)
Received: from dell_srv.bankers.org (l131.wespay.org [204.188.21.131]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA27145 for <[e-mail]>; Wed, 2 Sep 1998 10:31:10 -0700 (PDT)
Received: by l130.wespay.org with Internet Mail Service (5.5.1960.3) id <RYVJG1T6>; Wed, 2 Sep 1998 10:35:02 -0700
Message-ID: <[e-mail]>
From: Peter Yeatrakas <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:34:55 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26986 for ietf-pkix-bks; Wed, 2 Sep 1998 10:17:47 -0700 (PDT)
Received: from shadow.munge.com ([e-mail] [24.3.19.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26982 for <[e-mail]>; Wed, 2 Sep 1998 10:17:45 -0700 (PDT)
Received: from localhost (kaos@localhost) by shadow.munge.com (8.8.7/8.8.7) with SMTP id NAA11361; Wed, 2 Sep 1998 13:20:43 -0400 (EDT) (envelope-from [e-mail])
Date: Wed, 2 Sep 1998 13:20:42 -0400 (EDT)
From: Karen Oostendorp <[e-mail]>
To: [e-mail]
cc: Chris Vance <[e-mail]>
Subject: For Option 1
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26827 for ietf-pkix-bks; Wed, 2 Sep 1998 10:07:57 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26823 for <[e-mail]>; Wed, 2 Sep 1998 10:07:56 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <S1BY501N>; Wed, 2 Sep 1998 13:12:02 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E12B0DF@WUHER>
From: Peter Hesse <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 13:11:54 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

----------------------------------------------------------------
Peter M. Hesse           [e-mail]   
CygnaCom Solutions, Inc. [phone](voice) [phone](fax)
Visit the CygnaCom Solutions Web Site:  http://www.cygnacom.com
Page me instantly! http://wwp.mirabilis.com/1942828#pager


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26794 for ietf-pkix-bks; Wed, 2 Sep 1998 10:04:13 -0700 (PDT)
Received: from hq.freegate.com ([208.226.86.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA26790 for <[e-mail]>; Wed, 2 Sep 1998 10:04:12 -0700 (PDT)
Received: (qmail+freegate 12097 invoked by alias); 2 Sep 1998 17:08:41 -0000
Received: from ws37-n0.hq.freegate.com (HELO tardo2.hq.freegate.com) (208.226.86.165) by hq.freegate.com with SMTP; 2 Sep 1998 17:08:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 02 Sep 1998 10:08:25 -0700
To: [e-mail]
From: Joe Tardo <[e-mail]>
Subject: For Option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26755 for ietf-pkix-bks; Wed, 2 Sep 1998 10:00:11 -0700 (PDT)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA26751 for <[e-mail]>; Wed, 2 Sep 1998 10:00:10 -0700 (PDT)
Received: from [10.81.217.217] by eagle.rsa.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 2 Sep 1998 17:17:36 UT
Received: by LOBESTER with Internet Mail Service (5.0.1460.8) id <P3J70J5X>; Wed, 2 Sep 1998 10:07:06 -0700
Message-ID: <6236E58EC451D1119E80006097040ED98D3C04@LOBESTER>
From: Bruce Greenblatt <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 10:07:04 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Note new phone number below |
                            v
----------------------------------------------------
Bruce Greenblatt      
[e-mail]   Personal: [e-mail]
[phone]        http://www.innetix.com/~bruceg
----------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA26612 for ietf-pkix-bks; Wed, 2 Sep 1998 09:48:47 -0700 (PDT)
Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA26608 for <[e-mail]>; Wed, 2 Sep 1998 09:48:45 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo28.mx.aol.com (IMOv16.1) id 7WUCa24183 for <[e-mail]>; Wed, 2 Sep 1998 12:52:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 2 Sep 1998 12:52:48 EDT
To: [e-mail]
Mime-Version: 1.0
Subject: For Option 1
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 3.0 for Windows 95 sub 18
Sender: [e-mail]
Precedence: bulk

I vote for Option 1.

EAL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA25443 for ietf-pkix-bks; Wed, 2 Sep 1998 09:03:45 -0700 (PDT)
Received: from dkeynt1.DATAKEY.COM (dkeynt1.datakey.com [205.218.59.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25439 for <[e-mail]>; Wed, 2 Sep 1998 09:03:44 -0700 (PDT)
Received: from datakey.com ([205.218.59.20]) by dkeynt1.DATAKEY.COM (Netscape Messaging Server 3.5)  with ESMTP id 382 for <[e-mail]>; Wed, 2 Sep 1998 11:09:26 -0500
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:10:19 -0500
From: "Dale Gustafson" <[e-mail]>
Organization: Datakey, Inc.
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: PKIX Working Group <[e-mail]>
Subject: For Option 2
References: <5040300019913452000002L022*@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA25345 for ietf-pkix-bks; Wed, 2 Sep 1998 08:54:18 -0700 (PDT)
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25341 for <[e-mail]>; Wed, 2 Sep 1998 08:54:17 -0700 (PDT)
Received: from erols.com (207-172-132-91.s91.tnt5.col.erols.com [207.172.132.91]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id MAA06506 for <[e-mail]>; Wed, 2 Sep 1998 12:00:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:06:52 +0000
From: susanmaloney <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA25191 for ietf-pkix-bks; Wed, 2 Sep 1998 08:40:02 -0700 (PDT)
Received: from r3.ch (gateway.r3.ch [193.73.163.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25187 for <[e-mail]>; Wed, 2 Sep 1998 08:40:01 -0700 (PDT)
Received: by gateway.r3.ch id <6803>; Wed, 2 Sep 1998 17:46:05 +0100
Message-Id: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Extension of straw poll
Date: Wed, 2 Sep 1998 16:40:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA25160 for ietf-pkix-bks; Wed, 2 Sep 1998 08:36:10 -0700 (PDT)
Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25156 for <[e-mail]>; Wed, 2 Sep 1998 08:36:09 -0700 (PDT)
Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id LAA62454 for <[e-mail]>; Wed, 2 Sep 1998 11:25:17 -0400
Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id LAA37654 for <[e-mail]>; Wed, 2 Sep 1998 11:39:46 -0400
Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU053 id 5040300019913452; Wed, 2 Sep 1998 11:36:41 -0400
From: Ivan Milman <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Message-ID: <5040300019913452000002L022*@MHS>
Date: Wed, 2 Sep 1998 11:36:41 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Thanks,
Ivan

Ivan M. Milman
IBM/Austin
Distributed System Services
Email:  [e-mail]        Phone:
1-512-838-8152                                       Fax:
1-512-838-8597                      T/L:  678-8152


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24801 for ietf-pkix-bks; Wed, 2 Sep 1998 08:01:01 -0700 (PDT)
Received: from thunder.smartlink.navy.mil (thunder.smartlink.navy.mil [204.36.16.143]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24790 for <[e-mail]>; Wed, 2 Sep 1998 08:01:00 -0700 (PDT)
Received: (from smap@localhost) by thunder.smartlink.navy.mil (8.7.3/8.7.3) id LAA01758 for <[e-mail]>; Wed, 2 Sep 1998 11:03:13 -0400 (EDT)
X-Authentication-Warning: thunder.smartlink.navy.mil: smap set sender to <[e-mail]> using -f
Received: from localhost(127.0.0.1) by thunder via smap (V2.0) id xma001756; Wed, 2 Sep 98 11:02:48 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:02:48 -0400
From: Tom Horvath <[e-mail]>
Organization: Smart Link Office
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24771 for ietf-pkix-bks; Wed, 2 Sep 1998 07:59:29 -0700 (PDT)
Received: from stingray.missi.ncsc.mil ([144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24767 for <[e-mail]>; Wed, 2 Sep 1998 07:59:28 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA29628 for <[e-mail]>; Wed, 2 Sep 1998 11:03:31 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA29624 for <[e-mail]>; Wed, 2 Sep 1998 11:03:31 -0400 (EDT)
Received: from [144.51.53.159] (impala.missi.ncsc.mil [144.51.53.159]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA01159 for <[e-mail]>; Wed, 2 Sep 1998 11:02:54 -0400 (EDT)
X-Sender: [e-mail]
Message-Id: <v03110700b2130f1ae193@[144.51.53.159]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 Sep 1998 11:05:12 -0400
To: [e-mail]
From: David Dalkowski <[e-mail]>
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24736 for ietf-pkix-bks; Wed, 2 Sep 1998 07:55:24 -0700 (PDT)
Received: from mclean2-mail.usae.bah.com (mclean2-mail.usae.bah.com [156.80.5.110]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24732 for <[e-mail]>; Wed, 2 Sep 1998 07:55:23 -0700 (PDT)
Received: from bah.com ([156.80.128.200]) by mclean2-mail.usae.bah.com (Netscape Messaging Server 3.01)  with ESMTP id AAA27454 for <[e-mail]>; Wed, 2 Sep 1998 10:54:26 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 11:00:48 -0400
From: "Hirsch Matthew" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.03 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24667 for ietf-pkix-bks; Wed, 2 Sep 1998 07:48:37 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24663 for <[e-mail]>; Wed, 2 Sep 1998 07:48:35 -0700 (PDT)
Received: from juniper (juniper.chromatix.com [207.97.115.33]) by chromatix.com (8.8.8/8.8.8) with SMTP id KAA09830 for <[e-mail]>; Wed, 2 Sep 1998 10:52:43 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <008401bdd680$fb7af820$[e-mail]>
From: "Bill Lenz" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Wed, 2 Sep 1998 10:50:09 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01BDD65F.74558200"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24607 for ietf-pkix-bks; Wed, 2 Sep 1998 07:44:25 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24603 for <[e-mail]>; Wed, 2 Sep 1998 07:44:25 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA02474 for <[e-mail]>; Wed, 2 Sep 1998 07:49:07 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04MF3N5>; Wed, 2 Sep 1998 07:48:19 -0700
Message-ID: <[e-mail]>
From: "Pawluk, Jean" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 07:48:14 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24547 for ietf-pkix-bks; Wed, 2 Sep 1998 07:38:43 -0700 (PDT)
Received: from marlowe.APSINC.COM (marlowe.apsinc.com [198.160.146.80]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24543 for <[e-mail]>; Wed, 2 Sep 1998 07:38:42 -0700 (PDT)
Received: by MARLOWE with Internet Mail Service (5.5.2232.9) id <R4PAPTDT>; Wed, 2 Sep 1998 07:41:32 -0700
Message-ID: <70EAEA308C1FD211BF9B00805FBEF6B4158921@MARLOWE>
From: Bruce Bell <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: for option 1
Date: Wed, 2 Sep 1998 07:41:24 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Bruce S. Bell
Compliance Officer
phone [phone] ext.361
fax      [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA24010 for ietf-pkix-bks; Wed, 2 Sep 1998 06:46:56 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA24006 for <[e-mail]>; Wed, 2 Sep 1998 06:46:55 -0700 (PDT)
Received: from bonsai.chromatix.com (bonsai.chromatix.com [207.97.115.32]) by chromatix.com (8.8.8/8.8.8) with SMTP id JAA09586 for <[e-mail]>; Wed, 2 Sep 1998 09:51:03 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <00c101bdd678$680639e0$[e-mail]>
From: "Nora Kraemer" <[e-mail]>
To: <[e-mail]>
Subject: Option 1
Date: Wed, 2 Sep 1998 09:48:46 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01BDD656.E0E3D100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

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:  [phone]
Fax:       [phone]
[e-mail]
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:[e-mail]">[e-mail]</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--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23960 for ietf-pkix-bks; Wed, 2 Sep 1998 06:42:29 -0700 (PDT)
Received: from post.queensu.ca (post.QueensU.CA [130.15.126.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23956 for <[e-mail]>; Wed, 2 Sep 1998 06:42:23 -0700 (PDT)
Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.9.0/8.9.0) with SMTP id JAA29695 for <[e-mail]>; Wed, 2 Sep 1998 09:47:06 -0400 (EDT)
Received: from apollo.ee.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA22895; Wed, 2 Sep 98 09:47:05 EDT
Received: from localhost by apollo.ee.queensu.ca (SMI-8.6/SMI-SVR4) id JAA14757; Wed, 2 Sep 1998 09:47:04 -0400
Date: Wed, 2 Sep 1998 09:47:04 -0400 (EDT)
From: Serge Mister <[e-mail]>
X-Sender: misters@apollo
Reply-To: Serge Mister <[e-mail]>
To: [e-mail]
Subject: For Option 2
Message-Id: <Pine.GSO.3.96.980902094403.14741B-100000@apollo>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23926 for ietf-pkix-bks; Wed, 2 Sep 1998 06:39:03 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23921 for <[e-mail]>; Wed, 2 Sep 1998 06:39:02 -0700 (PDT)
Received: from chromatix.com (maple.chromatix.com [207.97.115.23]) by chromatix.com (8.8.8/8.8.8) with ESMTP id JAA09547; Wed, 2 Sep 1998 09:43:10 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 09:38:22 -0400
From: David Berstein <[e-mail]>
Organization: Chromatix
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

--
      _/_/_/         David M. Berstein
   _/      _/
  _/                 Chromatix, Inc.
 _/           _/  _/ 10451 Twin Rivers Road, Suite 265
_/            _/_/   Columbia, MD 21044
 _/     _/   _/_/    Phone:  [phone] | http://www.chromatix.com
  _/_/_/   _/   _/   Fax:    [phone] | [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23868 for ietf-pkix-bks; Wed, 2 Sep 1998 06:33:01 -0700 (PDT)
Received: from ha1.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23863 for <[e-mail]>; Wed, 2 Sep 1998 06:33:00 -0700 (PDT)
Received: from shadow.munge.com ([24.3.19.3]) by ha1.rdc1.md.home.com (Netscape Mail Server v2.02) with SMTP id AAA28598 for <[e-mail]>; Wed, 2 Sep 1998 06:37:42 -0700
Date: Wed, 2 Sep 1998 09:36:05 -0400 (EDT)
From: Chris Vance <[e-mail]>
To: [e-mail]
Subject: For Option 1
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23392 for ietf-pkix-bks; Wed, 2 Sep 1998 05:47:21 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA23388 for <[e-mail]>; Wed, 2 Sep 1998 05:47:20 -0700 (PDT)
Received: 	id IAA23613; Wed, 2 Sep 1998 08:49:31 -0400
Received: by gateway id <RNJC07PP>; Wed, 2 Sep 1998 08:46:38 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Wed, 2 Sep 1998 08:46:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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

mailto:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23383 for ietf-pkix-bks; Wed, 2 Sep 1998 05:47:04 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA23378 for <[e-mail]>; Wed, 2 Sep 1998 05:47:03 -0700 (PDT)
Received: 	id IAA23379; Wed, 2 Sep 1998 08:48:31 -0400
Received: by gateway id <RNJC07PN>; Wed, 2 Sep 1998 08:45:38 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], [e-mail], "'Bob Jueneman'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePairattributes- PK IX LDAPv2 schema I-D
Date: Wed, 2 Sep 1998 08:45:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       


> ----------
> From: 	Bob Jueneman[SMTP:[e-mail]]
> Sent: 	September 1, 1998 7:20 PM
> To: 	[e-mail]; [e-mail]; [e-mail]
> 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
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23301 for ietf-pkix-bks; Wed, 2 Sep 1998 05:40:29 -0700 (PDT)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23297 for <[e-mail]>; Wed, 2 Sep 1998 05:40:26 -0700 (PDT)
Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id IAA14963 for <[e-mail]>; Wed, 2 Sep 1998 08:45:08 -0400 (EDT)
Received: from mm60206-lptp.mitre.org (128.29.105.60) by fuzzy.mitre.org with SMTP id 389257; Wed, 02 Sep 1998 08:45:07 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 02 Sep 1998 08:37:49 -0400
To: [e-mail]
From: [e-mail] (Ella P. Gardner)
Subject: For Option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Ella P. Gardner	               phone: [phone]
The MITRE Corporation	         fax    [phone]
1820 Dolley Madison Boulevard	   email: [e-mail]
McLean, VA 22102-3481



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23208 for ietf-pkix-bks; Wed, 2 Sep 1998 05:26:25 -0700 (PDT)
Received: from Sonnet.GSC.GTE.Com (Sonnet.GSC.GTE.Com [131.131.251.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23204 for <[e-mail]>; Wed, 2 Sep 1998 05:26:24 -0700 (PDT)
Received: from gscex01.ndhm.gtegsc.com ("port 3641"@gscex01.ndhm.gtegsc.com) by Sonnet.GSC.GTE.Com (PMDF V5.0-8 #17886) id <[e-mail]> for [e-mail]; Wed, 02 Sep 1998 08:30:46 -0400 (EDT)
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.0.1460.8) id <Q16F2A6D>; Wed, 02 Sep 1998 08:28:31 -0400
Date: Wed, 02 Sep 1998 08:34:05 -0400
From: "Saylor, John" <[e-mail]>
Subject: For Option 2
To: "'[e-mail]'" <[e-mail]>
Message-id: <ED3CB0BEB22CD211A4580008C756184441476F@NDHMEX01>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-type: text/plain
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk

\js



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22985 for ietf-pkix-bks; Wed, 2 Sep 1998 04:53:31 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22981 for <[e-mail]>; Wed, 2 Sep 1998 04:53:29 -0700 (PDT)
Received: from chromatix.com (redoak.chromatix.com [207.97.115.4]) by chromatix.com (8.8.8/8.8.8) with ESMTP id HAA09208 for <[e-mail]>; Wed, 2 Sep 1998 07:57:37 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 08:01:58 -0400
From: John Garner <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: "IETF X.509 PKI" <[e-mail]>
Subject: For Option 1
Content-Type: multipart/alternative; boundary="------------06CB147F224BAAC5EA029C20"
Sender: [e-mail]
Precedence: bulk

--------------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:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]



--------------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; [phone]&nbsp; |&nbsp; <A HREF="http://www.chromatix.com">http://www.chromatix.com</A>
&nbsp; _/_/_/&nbsp;&nbsp; _/&nbsp;&nbsp; _/ Fax:&nbsp;&nbsp;&nbsp; [phone]&nbsp; |&nbsp; [e-mail]</PRE>
&nbsp;</HTML>

--------------06CB147F224BAAC5EA029C20--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22811 for ietf-pkix-bks; Wed, 2 Sep 1998 04:32:01 -0700 (PDT)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22807 for <[e-mail]>; Wed, 2 Sep 1998 04:31:59 -0700 (PDT)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id HAA03515 for <[e-mail]>; Wed, 2 Sep 1998 07:36:35 -0400 (EDT)
Received: from mwppp12.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA26210; Wed, 2 Sep 1998 07:36:34 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 02 Sep 1998 07:36:15 -0400
To: [e-mail]
From: Elliott N Ginsburg <[e-mail]>
Subject: for option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22784 for ietf-pkix-bks; Wed, 2 Sep 1998 04:28:38 -0700 (PDT)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22780 for <[e-mail]>; Wed, 2 Sep 1998 04:28:36 -0700 (PDT)
Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id HAA24382 for <[e-mail]>; Wed, 2 Sep 1998 07:22:32 -0400
Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id HAA24986 for <[e-mail]>; Wed, 2 Sep 1998 07:32:18 -0400
Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU014 id 5040300019901937; Wed, 2 Sep 1998 07:29:13 -0400
From: Mark C Davis <[e-mail]>
To: <[e-mail]>
Subject: For Option 2
Message-ID: <5040300019901937000002L072*@MHS>
Date: Wed, 2 Sep 1998 07:29:13 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

______________________________________________________________
Mark C Davis/Raleigh/IBM, DSS Network Security, [e-mail]
[phone], pager 1(800)946-4646 PIN 6066244,  FAX [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22620 for ietf-pkix-bks; Wed, 2 Sep 1998 04:08:00 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22616 for <[e-mail]>; Wed, 2 Sep 1998 04:07:59 -0700 (PDT)
Received: from stefans (t2o68p26.telia.com [62.20.138.146]) by mailc.telia.com (8.8.8/8.8.8) with SMTP id NAA05183; Wed, 2 Sep 1998 13:12:31 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Sep 1998 13:10:19 +0200
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA22617
Sender: [e-mail]
Precedence: bulk

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
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA22485 for ietf-pkix-bks; Wed, 2 Sep 1998 03:54:07 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA22480 for <[e-mail]>; Wed, 2 Sep 1998 03:54:06 -0700 (PDT)
From: [e-mail]
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090206582906:162  for <[e-mail]> ; Wed, 2 Sep 1998 06:58:29 -0400 
Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino Build 161 (Beta)) with SMTP id 1998090206582906:162  for <[e-mail]> ; Wed, 2 Sep 1998 06:58:29 -0400 
X-Lotus-FromDomain: IRIS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 2 Sep 1998 07:01:37 -0400
Subject: For Option 2
x-notes-Form: Memo
x-notes-$24UpdatedBy: CN=Epic/O=Iris
x-notes-$24Hops: 22
X-Priority: 3 (Normal)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA22420 for ietf-pkix-bks; Wed, 2 Sep 1998 03:47:26 -0700 (PDT)
Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA22416 for <[e-mail]>; Wed, 2 Sep 1998 03:47:25 -0700 (PDT)
Received: from wigeon.shiva.com (wigeon.shiva.com [140.248.194.223]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id GAA07839 for <[e-mail]>; Wed, 2 Sep 1998 06:49:05 -0400 (EDT)
Received: from shiva.com by wigeon.shiva.com (SMI-8.6/SMI-SVR4) id GAA05853; Wed, 2 Sep 1998 06:51:37 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 06:51:36 -0400
From: Jesse Walker <[e-mail]>
Organization: Shiva Corporation
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: [e-mail]
Subject: For option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA21021 for ietf-pkix-bks; Wed, 2 Sep 1998 03:06:50 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA21017 for <[e-mail]>; Wed, 2 Sep 1998 03:06:48 -0700 (PDT)
Received: from stefans (t2o68p44.telia.com [62.20.138.164]) by mailc.telia.com (8.8.8/8.8.8) with SMTP id MAA12855; Wed, 2 Sep 1998 12:10:23 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Sep 1998 12:08:11 +0200
To: Santosh Chokhani <[e-mail]>, Sharon Boeyen <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA21018
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
>> Sent:	Tuesday, September 01, 1998 3:54 PM
>> To:	Sharon Boeyen; '[e-mail]'
>> 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
>> 
>> 

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA21010 for ietf-pkix-bks; Wed, 2 Sep 1998 03:05:49 -0700 (PDT)
Received: from mailc.telia.com ([e-mail] [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA21006 for <[e-mail]>; Wed, 2 Sep 1998 03:05:46 -0700 (PDT)
Received: from stefans (t2o68p44.telia.com [62.20.138.164]) by mailc.telia.com (8.8.8/8.8.8) with SMTP id MAA12859 for <[e-mail]>; Wed, 2 Sep 1998 12:10:24 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Sep 1998 12:08:12 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA21007
Sender: [e-mail]
Precedence: bulk

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19711 for ietf-pkix-bks; Wed, 2 Sep 1998 01:35:50 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19707 for <[e-mail]>; Wed, 2 Sep 1998 01:35:49 -0700 (PDT)
Received: from roger ([10.0.0.21]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA05769 for <[e-mail]>; Wed, 2 Sep 1998 10:37:32 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 02 Sep 1998 10:39:52 +0200
To: [e-mail]
From: Martin =?iso-8859-1?Q?Lindström?= <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA19708
Sender: [e-mail]
Precedence: bulk

 ______________________________________
|________ Entegrity Solutions _________|
|                                      |
| Martin Lindström, Systems Engineer   |
|                                      |                                    
| Finlandsgatan 60                     |
| S-164 74 Kista, Sweden               |
| Direct: [phone]            |
| Fax:    [phone]            |
| Cell:   [phone]           |
|______________________________________|




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19623 for ietf-pkix-bks; Wed, 2 Sep 1998 01:18:14 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19619 for <[e-mail]>; Wed, 2 Sep 1998 01:18:13 -0700 (PDT)
Received: from esmarelda ([10.0.0.11]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA05687 for <[e-mail]>; Wed, 2 Sep 1998 10:20:01 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.44 (Beta)
Date: Wed, 02 Sep 1998 10:19:46 +0200
To: [e-mail]
From: Thomas Caldenius <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19614 for ietf-pkix-bks; Wed, 2 Sep 1998 01:17:50 -0700 (PDT)
Received: from ccas.ru (ext1.ccas.ru [193.233.208.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19610 for <[e-mail]>; Wed, 2 Sep 1998 01:17:47 -0700 (PDT)
Received: from sauron ([193.232.81.34]) by ccas.ru (8.7.5/8.7.3) with SMTP id MAA18012 for <[e-mail]>; Wed, 2 Sep 1998 12:19:50 +0300 (EET DST)
Message-ID: <005501bdd64a$e2293fc0$[e-mail]>
From: "Andrey Lopatenko" <[e-mail]>
To: <[e-mail]>
Subject: Option 2
Date: Wed, 2 Sep 1998 12:22:54 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01BDD66C.68EE6D70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19576 for ietf-pkix-bks; Wed, 2 Sep 1998 01:12:11 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19572 for <[e-mail]>; Wed, 2 Sep 1998 01:12:09 -0700 (PDT)
Received: from jimmie ([10.0.0.22]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA05667 for <[e-mail]>; Wed, 2 Sep 1998 10:13:54 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 02 Sep 1998 10:14:29 +0200
To: [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA08102 for ietf-pkix-bks; Tue, 1 Sep 1998 22:34:25 -0700 (PDT)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA08098 for <[e-mail]>; Tue, 1 Sep 1998 22:34:22 -0700 (PDT)
Received: by relay2.elvis.ru (8.8.5/1.24) id JAA19889; Wed, 2 Sep 1998 09:38:55 +0400 (MSK DST)
Message-ID: <[e-mail]>
X-Mailer: XFMail 1.3 [p0] on Solaris
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Wed, 02 Sep 1998 09:38:55 +0400 (MSK DST)
From: Pavel Krylov <[e-mail]>
To: [e-mail]
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA25421 for ietf-pkix-bks; Tue, 1 Sep 1998 21:15:31 -0700 (PDT)
Received: from mailer.Symantec.Com (mailer.symantec.com [198.6.49.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA25417 for <[e-mail]>; Tue, 1 Sep 1998 21:15:30 -0700 (PDT)
From: [e-mail]
Received: from smtp-ima.symantec.com (host39-sub74.symantec.com [155.64.74.39]) by mailer.Symantec.Com (8.8.8/8.8.8) with ESMTP id VAA24786 for <[e-mail]>; Tue, 1 Sep 1998 21:18:25 -0700 (PDT)
Received: from ccMail by smtp-ima.symantec.com (IMA Internet Exchange 3.1) id 00201118; Tue, 1 Sep 1998 21:17:59 -0700
Mime-Version: 1.0
Date: Tue, 1 Sep 1998 21:14:44 -0700
Message-ID: <[e-mail]>
To: [e-mail]
Subject: option 2
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24963 for ietf-pkix-bks; Tue, 1 Sep 1998 19:38:21 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24959 for <[e-mail]>; Tue, 1 Sep 1998 19:38:19 -0700 (PDT)
Received: from yuriy_nb.spyrus.com ([209.66.65.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA26697 for <[e-mail]>; Tue, 1 Sep 1998 19:42:28 -0700 (PDT)
From: "Yuriy Dzambasow" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 22:44:42 -0400
Message-ID: <001e01bdd61b$a2db8b40$066c42d1@yuriy_nb.spyrus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22960 for ietf-pkix-bks; Tue, 1 Sep 1998 16:20:11 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA22956 for <[e-mail]>; Tue, 1 Sep 1998 16:20:10 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Tue, 01 Sep 1998 17:20:24 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 01 Sep 1998 17:20:10 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePairattributes- PKIX LDAPv2 schema I-D
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA22957
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22879 for ietf-pkix-bks; Tue, 1 Sep 1998 16:12:52 -0700 (PDT)
Received: from aum.proper.com (ts011d20.cup-ca.concentric.net [209.31.12.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA22874 for <[e-mail]>; Tue, 1 Sep 1998 16:12:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Tue, 01 Sep 1998 09:01:49 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: For  Option 2
In-Reply-To: <[e-mail]>
References: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22266 for ietf-pkix-bks; Tue, 1 Sep 1998 14:58:03 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22262 for <[e-mail]>; Tue, 1 Sep 1998 14:58:03 -0700 (PDT)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <RWP6XMJM>; Tue, 1 Sep 1998 15:02:12 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0509BA3E@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:02:05 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22248 for ietf-pkix-bks; Tue, 1 Sep 1998 14:56:13 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22244 for <[e-mail]>; Tue, 1 Sep 1998 14:56:12 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SAKHKX5N>; Tue, 1 Sep 1998 18:00:16 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D210@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 18:00:13 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

For option 1

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
[phone] (voice)
[phone] (fax)
[e-mail]
http://www.cygnacom.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22241 for ietf-pkix-bks; Tue, 1 Sep 1998 14:56:00 -0700 (PDT)
Received: from louie.scs.carleton.ca (louie.scs.carleton.ca [134.117.5.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22237 for <[e-mail]>; Tue, 1 Sep 1998 14:55:58 -0700 (PDT)
Received: from turing (turing [134.117.5.10]) by louie.scs.carleton.ca (96/30.01.97) with SMTP id SAA04115 for <[e-mail]>; Tue, 1 Sep 1998 18:00:00 -0400 (EDT)
Received: from floyd by turing (5.x/SMI-SVR4) id AA03913; Tue, 1 Sep 1998 17:59:55 -0400
From: [e-mail] (Mike Just)
Received: by floyd (5.x/Scs-1.0-client) id AA17259; Tue, 1 Sep 1998 17:59:54 -0400
Date: Tue, 1 Sep 1998 17:59:54 -0400
Message-Id: <9809012159.AA17259@floyd>
To: [e-mail]
Subject: For Option 2
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22199 for ietf-pkix-bks; Tue, 1 Sep 1998 14:52:28 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22195 for <[e-mail]>; Tue, 1 Sep 1998 14:52:26 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SAKHKXZ0>; Tue, 1 Sep 1998 17:56:29 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E16D20F@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Sharon Boeyen <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Santosh Chokhani'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 17:56:27 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

They are stored in caCertificate attribute of directory entry
representing the subject (subscriber) CA.

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[e-mail]]
> Sent:	Tuesday, September 01, 1998 3:54 PM
> To:	Sharon Boeyen; '[e-mail]'
> 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 [e-mail] 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:[e-mail]  Tel: [phone] 
> >http://www.entrust.com            Fax: [phone] 
> >       
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB     
> Lotsgatan 27 D                  Tel. [phone]              
> 216 42  Malmö                   Fax. [phone]              
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22157 for ietf-pkix-bks; Tue, 1 Sep 1998 14:46:11 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22153 for <[e-mail]>; Tue, 1 Sep 1998 14:46:10 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA04459; Tue, 1 Sep 1998 14:48:30 -0700 (PDT)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA09078; Tue, 1 Sep 1998 14:50:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 01 Sep 1998 14:50:18 -0700
To: [e-mail]
From: Michael Myers <[e-mail]>
Subject: For Option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22067 for ietf-pkix-bks; Tue, 1 Sep 1998 14:37:38 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA22063 for <[e-mail]>; Tue, 1 Sep 1998 14:37:37 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA08469 for <[e-mail]>; Tue, 1 Sep 1998 14:41:46 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id RAA28723; Tue, 1 Sep 1998 17:41:41 -0400
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id RAA01584; Tue, 1 Sep 1998 17:41:43 -0400
Received: from east.sun.com by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id RAA17370; Tue, 1 Sep 1998 17:41:40 -0400
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 17:41:41 -0400
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.5b1 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21256 for ietf-pkix-bks; Tue, 1 Sep 1998 14:28:24 -0700 (PDT)
Received: from spacenet.com.br (saturno.spacenet.com.br [200.255.100.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21252 for <[e-mail]>; Tue, 1 Sep 1998 14:28:20 -0700 (PDT)
Received: from spacenet.com.br (lagoa.spacenet.com.br [200.255.243.65]) by spacenet.com.br (8.8.4/SMI-SVR4) id SAA00630; Tue, 1 Sep 1998 18:18:41 -0300 (EST)
X-Sender: lagoa.spacenet.com.br [200.255.243.65]
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 18:32:48 -0300
From: Eduardo Rosemberg de Moura <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

-- 
Eduardo Rosemberg de Moura
mailto:[e-mail] ([e-mail])
Phone: [phone] (voice)
       [phone] (fax)
Mobile:[phone]
ICQ:   6365858


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21166 for ietf-pkix-bks; Tue, 1 Sep 1998 14:17:29 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21162 for <[e-mail]>; Tue, 1 Sep 1998 14:17:28 -0700 (PDT)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <RWP6XHA8>; Tue, 1 Sep 1998 14:21:33 -0700
Message-ID: <39ADCF833E74D111A2D700805F1951EF056B9D4A@RED-MSG-06>
From: Brian LaMacchia <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:21:30 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20962 for ietf-pkix-bks; Tue, 1 Sep 1998 13:51:24 -0700 (PDT)
Received: from mtahqs2.ncr.disa.mil (mtahqs2.ncr.disa.mil [164.117.144.158]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20957 for <[e-mail]>; Tue, 1 Sep 1998 13:51:23 -0700 (PDT)
Received: by mtahqs2.ncr.disa.mil with Internet Mail Service (5.0.1460.8) id <R503HD5B>; Tue, 1 Sep 1998 20:55:56 -0000
Message-ID: <[e-mail]>
From: "Adkins, Sherrill" <[e-mail]>
To: [e-mail]
Subject: For Option 1
Date: Tue, 1 Sep 1998 20:55:47 -0000 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20951 for ietf-pkix-bks; Tue, 1 Sep 1998 13:50:49 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20947 for <[e-mail]>; Tue, 1 Sep 1998 13:50:48 -0700 (PDT)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id <RWPXN6PY>; Tue, 1 Sep 1998 13:54:57 -0700
Message-ID: <4FD6422BE942D111908D00805F3158DF055136F3@RED-MSG-52>
From: Barb Fox <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: for Option 1
Date: Tue, 1 Sep 1998 13:54:51 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20939 for ietf-pkix-bks; Tue, 1 Sep 1998 13:49:06 -0700 (PDT)
Received: from ultraman.ilan.net (ultraman.ilan.net [207.211.122.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20935 for <[e-mail]>; Tue, 1 Sep 1998 13:49:03 -0700 (PDT)
Received: from secantnet.com ([207.211.125.5]) by ultraman.ilan.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 610-52672U600L100S0V35) with SMTP id AAA5949 for <[e-mail]>; Tue, 1 Sep 1998 16:45:31 -0400
Received: from secantnet.com by secantnet.com (SMI-8.6/SMI-SVR4) id QAA06759; Tue, 1 Sep 1998 16:53:36 -0400
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 16:53:40 -0400
From: Greg Byrd <[e-mail]>
Organization: SECANT Network Technologies
X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: [e-mail]
Subject: for option 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

-- 
Greg Byrd                          [e-mail]
SECANT Network Technologies, Inc.  919-462-1900 x229
P.O. Box 14285                     919-462-1933 (fax)
Research Triangle Park, NC 27709


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20554 for ietf-pkix-bks; Tue, 1 Sep 1998 13:02:41 -0700 (PDT)
Received: from chopin.digsigtrust.com (chopin.digsigtrust.com [208.30.64.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20550 for <[e-mail]>; Tue, 1 Sep 1998 13:02:40 -0700 (PDT)
Received: from digsigtrust.com (rfwdesktop.digsigtrust.com [208.30.64.114]) by chopin.digsigtrust.com (8.9.1/8.9.1) with ESMTP id OAA01554 for <[e-mail]>; Tue, 1 Sep 1998 14:06:48 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:31:19 -0600
From: "Russel F. Weiser" <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: multipart/mixed; boundary="------------C201775B051242826227D678"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------C201775B051242826227D678--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20474 for ietf-pkix-bks; Tue, 1 Sep 1998 12:51:51 -0700 (PDT)
Received: from maild.telia.com ([e-mail] [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20470 for <[e-mail]>; Tue, 1 Sep 1998 12:51:47 -0700 (PDT)
Received: from stefans (t2o68p112.telia.com [62.20.138.232]) by maild.telia.com (8.8.8/8.8.8) with SMTP id VAA14836; Tue, 1 Sep 1998 21:55:47 +0200 (CEST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 01 Sep 1998 21:53:35 +0200
To: Sharon Boeyen <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Cc: "'Santosh Chokhani'" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA20471
Sender: [e-mail]
Precedence: bulk

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 [e-mail] 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:[e-mail]  Tel: [phone] 
>http://www.entrust.com            Fax: [phone] 
>       
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20428 for ietf-pkix-bks; Tue, 1 Sep 1998 12:44:44 -0700 (PDT)
Received: from fw.ssb.it (fw.ssb.it [192.106.128.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20424 for <[e-mail]>; Tue, 1 Sep 1998 12:44:40 -0700 (PDT)
Received: from notesmail.ssb.it (domino.ssb.it [192.168.19.5]) by ns.ssb.it (8.8.5/8.7.3) with SMTP id XAA26047 for <[e-mail]>; Tue, 1 Sep 1998 23:45:55 +0200 (CEST)
Received: by notesmail.ssb.it(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id C1256672.006D747B ; Tue, 1 Sep 1998 21:55:32 +0200
X-Lotus-FromDomain: SSB
From: "Fabio Omenigrandi" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 1 Sep 1998 21:32:35 +0200
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20329 for ietf-pkix-bks; Tue, 1 Sep 1998 12:37:15 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20325 for <[e-mail]>; Tue, 1 Sep 1998 12:37:13 -0700 (PDT)
Received: 	id PAA27010; Tue, 1 Sep 1998 15:38:44 -0400
Received: by gateway id <RNJC0ZXX>; Tue, 1 Sep 1998 15:35:52 -0400
Message-ID: <[e-mail]>
From: Ron Chittaro <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:35:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20095 for ietf-pkix-bks; Tue, 1 Sep 1998 12:08:59 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20091 for <[e-mail]>; Tue, 1 Sep 1998 12:08:56 -0700 (PDT)
Received: 	id PAA23359; Tue, 1 Sep 1998 15:09:38 -0400
Received: by gateway id <RNJC0ZSP>; Tue, 1 Sep 1998 15:06:46 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Tim Polk'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Straw Poll cACertificate & crossCertificatePair attributes -  PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 15:06:36 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: 	Tuesday, September 01, 1998 1:39 PM
> To: 	'[e-mail]'
> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20090 for ietf-pkix-bks; Tue, 1 Sep 1998 12:08:55 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20086 for <[e-mail]>; Tue, 1 Sep 1998 12:08:54 -0700 (PDT)
Received: 	id PAA23418; Tue, 1 Sep 1998 15:10:18 -0400
Received: by gateway id <RNJC0ZST>; Tue, 1 Sep 1998 15:07:26 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail]
Subject: For Option 2
Date: Tue, 1 Sep 1998 15:07:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20051 for ietf-pkix-bks; Tue, 1 Sep 1998 12:03:04 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20047 for <[e-mail]>; Tue, 1 Sep 1998 12:03:03 -0700 (PDT)
Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id PAA06735 for <[e-mail]>; Tue, 1 Sep 1998 15:07:10 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 15:07:07 -0400
From: Dave Horvath <[e-mail]>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  [phone]  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    [phone]  |  [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19990 for ietf-pkix-bks; Tue, 1 Sep 1998 11:59:18 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19986 for <[e-mail]>; Tue, 1 Sep 1998 11:59:17 -0700 (PDT)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQfezk12448; Tue, 1 Sep 1998 15:03:22 -0400 (EDT)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <RZYRA0CT>; Tue, 1 Sep 1998 15:05:27 -0400
Message-ID: <[e-mail]>
From: MHenry <[e-mail]>
To: [e-mail]
Subject: for option 2
Date: Tue, 1 Sep 1998 15:05:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19970 for ietf-pkix-bks; Tue, 1 Sep 1998 11:56:58 -0700 (PDT)
Received: from stingray.missi.ncsc.mil ([144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19966 for <[e-mail]>; Tue, 1 Sep 1998 11:56:57 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA22769 for <[e-mail]>; Tue, 1 Sep 1998 15:00:56 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA22763 for <[e-mail]>; Tue, 1 Sep 1998 15:00:55 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA14818 for <[e-mail]>; Tue, 1 Sep 1998 15:00:19 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 01 Sep 1998 15:01:51 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Tue, 1 Sep 1998 15:01:51 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'IETF/PKIX'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 15:01:50 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19925 for ietf-pkix-bks; Tue, 1 Sep 1998 11:47:27 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19921 for <[e-mail]>; Tue, 1 Sep 1998 11:47:25 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Tue, 1 Sep 1998 19:51:30 +0100
Received: from mail0.sse.ie (unverified [193.120.32.47]) by mail2.sse.ie (Integralis SMTPRS 2.04) with ESMTP id <[e-mail]>; Tue, 01 Sep 1998 19:51:21 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id TAA07273 for <[e-mail]>; Tue, 1 Sep 1998 19:51:19 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
Reply-To: [e-mail]
To: [e-mail]
Subject: For Option 2
From: Stephen Farrell <[e-mail]>
MIME-Version: 1.0
Date: Tue, 01 Sep 1998 19:52:09 +0100
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19878 for ietf-pkix-bks; Tue, 1 Sep 1998 11:38:52 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19874 for <[e-mail]>; Tue, 1 Sep 1998 11:38:51 -0700 (PDT)
Received: from chromatix.com (poplar.chromatix.com [207.97.115.14]) by chromatix.com (8.8.8/8.8.8) with ESMTP id OAA06632 for <[e-mail]>; Tue, 1 Sep 1998 14:42:57 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:43:28 -0400
From: Michael Maloney <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: multipart/mixed; boundary="------------10B5479D1700C8A1FFAC998E"
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
title:          Senior Engineer
tel;work:       301 596-8466
tel;fax:        [phone]
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------10B5479D1700C8A1FFAC998E--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19820 for ietf-pkix-bks; Tue, 1 Sep 1998 11:35:01 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19816 for <[e-mail]>; Tue, 1 Sep 1998 11:35:00 -0700 (PDT)
Received: 	id OAA19092; Tue, 1 Sep 1998 14:36:01 -0400
Received: by gateway id <RNJC0ZNA>; Tue, 1 Sep 1998 14:33:07 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 2
Date: Tue, 1 Sep 1998 14:33:05 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19706 for ietf-pkix-bks; Tue, 1 Sep 1998 11:23:55 -0700 (PDT)
Received: from inetgw.fs.lmco.com (inetgw.fs.lmco.com [204.177.125.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19702 for <[e-mail]>; Tue, 1 Sep 1998 11:23:53 -0700 (PDT)
Received: (from mail@localhost) by inetgw.fs.lmco.com (AIX4.2/UCB 8.7/8.7) id OAA33110 for <[e-mail]>; Tue, 1 Sep 1998 14:28:26 -0400 (EDT)
Received: from dmsman.man.fs.lmco.com(158.187.195.16) by inetgw.fs.lmco.com via smap (V2.0) id xma075892; Tue, 1 Sep 98 14:27:58 -0400
Received: by dmsman.man.fs.lmco.com with Internet Mail Service (5.5.2232.9) id <RQDKB2NB>; Tue, 1 Sep 1998 14:26:58 -0400
Message-ID: <[e-mail]>
From: "Rogers III, Edward B." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:26:56 -0400 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

R/ Ed
Technical Lead, DMS Security Evolution
Lockheed Martin Federal Systems



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19574 for ietf-pkix-bks; Tue, 1 Sep 1998 11:06:39 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19570 for <[e-mail]>; Tue, 1 Sep 1998 11:06:38 -0700 (PDT)
Received: from cedar.chromatix.com (cedar.chromatix.com [207.97.115.12]) by chromatix.com (8.8.8/8.8.8) with SMTP id OAA06514; Tue, 1 Sep 1998 14:10:42 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <018201bdd5d4$10ca0520$[e-mail]>
From: "Steven (Pete) Peterson" <[e-mail]>
To: <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 14:12:22 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017F_01BDD5B2.89B86520"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19563 for ietf-pkix-bks; Tue, 1 Sep 1998 11:05:08 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19559 for <[e-mail]>; Tue, 1 Sep 1998 11:05:04 -0700 (PDT)
Received: from chromatix.com (kapok.chromatix.com [207.97.115.37]) by chromatix.com (8.8.8/8.8.8) with ESMTP id OAA06501 for <[e-mail]>; Tue, 1 Sep 1998 14:09:07 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:12:56 -0400
From: Thomas Llanso <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

--

      _/_/_/                   Thomas H. Llanso
   _/      _/
  _/       _/                  Chromatix, Inc.
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/      Phone:  [phone]  |
http://www.chromatix.com
 _/_/_/   _/   _/      Fax:    [phone]  |
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19529 for ietf-pkix-bks; Tue, 1 Sep 1998 11:03:15 -0700 (PDT)
Received: from hq.vni.net (hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19524 for <[e-mail]>; Tue, 1 Sep 1998 11:03:12 -0700 (PDT)
Received: from ieca.com (nova-aaa-061.vni.net [205.177.115.61]) by hq.vni.net (8.8.8/8.8.5) with ESMTP id OAA10687 for <[e-mail]>; Tue, 1 Sep 1998 14:07:49 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 14:06:38 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.06 [en] (Win98; U)
MIME-Version: 1.0
To: [e-mail]
Subject: For Option 1
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19400 for ietf-pkix-bks; Tue, 1 Sep 1998 10:53:33 -0700 (PDT)
Received: from hq.ljl.COM (hq.ljl.com [206.151.234.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19394 for <[e-mail]>; Tue, 1 Sep 1998 10:53:28 -0700 (PDT)
Received: from larry.ljl.com by hq.ljl.COM. with smtp id aa23343; Tue, 1 Sep 1998 12:58:23 -0500
Received: by localhost with Microsoft MAPI; Tue, 1 Sep 1998 12:58:07 -0500
Message-ID: <[e-mail]>
From: Larry Layten <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: For Option 1
Date: Tue, 1 Sep 1998 12:58:05 -0500
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19364 for ietf-pkix-bks; Tue, 1 Sep 1998 10:50:49 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19360 for <[e-mail]>; Tue, 1 Sep 1998 10:50:48 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Tue, 01 Sep 1998 11:51:07 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 01 Sep 1998 11:51:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes- PKIX LDAPv2 schema I-D
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA19361
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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.







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19335 for ietf-pkix-bks; Tue, 1 Sep 1998 10:44:44 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19330 for <[e-mail]>; Tue, 1 Sep 1998 10:44:43 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id NAA09240 for <[e-mail]>; Tue, 1 Sep 1998 13:52:46 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id NAA17303; Tue, 1 Sep 1998 13:51:23 -0400
Date: Tue, 1 Sep 1998 13:51:23 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: For Option 1
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19270 for ietf-pkix-bks; Tue, 1 Sep 1998 10:35:35 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19266 for <[e-mail]>; Tue, 1 Sep 1998 10:35:34 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Tue, 01 Sep 1998 11:35:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 01 Sep 1998 11:35:15 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Digital signature and non-repudiation key usage bits
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA19267
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19246 for ietf-pkix-bks; Tue, 1 Sep 1998 10:32:52 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19242 for <[e-mail]>; Tue, 1 Sep 1998 10:32:51 -0700 (PDT)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id NAA17339 for <[e-mail]>; Tue, 1 Sep 1998 13:37:18 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 01 Sep 1998 13:39:54 -0400
To: "'[e-mail]'" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: For  Option 2
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19241 for ietf-pkix-bks; Tue, 1 Sep 1998 10:32:51 -0700 (PDT)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19237 for <[e-mail]>; Tue, 1 Sep 1998 10:32:49 -0700 (PDT)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id NAA17327 for <[e-mail]>; Tue, 1 Sep 1998 13:37:11 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 01 Sep 1998 13:39:47 -0400
To: "'[e-mail]'" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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.






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18845 for ietf-pkix-bks; Tue, 1 Sep 1998 09:34:40 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA18836 for <[e-mail]>; Tue, 1 Sep 1998 09:34:39 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA06062 for <[e-mail]>; Tue, 1 Sep 1998 09:38:47 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id MAA08888; Tue, 1 Sep 1998 12:38:43 -0400
Received: from saguaro.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id MAA22275; Tue, 1 Sep 1998 12:38:45 -0400
Received: by saguaro.East.Sun.COM (SMI-8.6/SMI-SVR4) id MAA16476; Tue, 1 Sep 1998 12:38:44 -0400
From: Anne Anderson - Sun Microsystems <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue,  1 Sep 1998 12:38:44 -0400 (EDT)
To: [e-mail]
Subject: For Option 1
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13804.8941.806700.92413@saguaro>
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18167 for ietf-pkix-bks; Tue, 1 Sep 1998 08:12:58 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA18162 for <[e-mail]>; Tue, 1 Sep 1998 08:12:56 -0700 (PDT)
Received: 	id LAA21117; Tue, 1 Sep 1998 11:13:29 -0400
Received: by gateway id <RNJC0YLQ>; Tue, 1 Sep 1998 11:10:37 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Steve Kent'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Straw Poll cACertificate & crossCertificatePair attributes - PKIX LDAPv2 schema I-D
Date: Tue, 1 Sep 1998 11:10:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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 [e-mail] 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:[e-mail]  Tel: [phone] 
http://www.entrust.com            Fax: [phone] 
       



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18070 for ietf-pkix-bks; Tue, 1 Sep 1998 08:03:07 -0700 (PDT)
Received: from hrdcgate.nhq.hrdc-drhc.gc.ca (hrdcgate.nhq.hrdc-drhc.gc.ca [198.103.152.3]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA18066 for <[e-mail]>; Tue, 1 Sep 1998 08:03:05 -0700 (PDT)
Received: from svmailsw1.hq-ac.prv by hrdcgate.nhq.hrdc-drhc.gc.ca via smtpd (for imc.org [206.184.129.134]) with SMTP; 1 Sep 1998 15:07:43 UT
Received: from gwsmtpim1.hq-ac.prv (10.54.254.16) by svmailsw1.hq-ac.prv (NPlex 1.3.152) for [e-mail]; 1 Sep 1998 11:10:02 -0400
Received: by gwsmtpim1.hq-ac.prv with VINES-ISMTP; Tue, 1 Sep 98 11:10:04 -0400
Date: Tue, 1 Sep 98 11:09:56 -0400
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
To: <[e-mail]>
From: "Fred Gloade Hrdc-drhc" <[e-mail]>
Reply-To: <[e-mail]>
Subject: fwd: Re: ...no subject...
X-Incognito-SN: 1396
X-Incognito-Version: 4.11.23
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA18067
Sender: [e-mail]
Precedence: bulk

Fred Gloade 
Senior Auditor/Vérificateur principal
Information Technology and Systems
Technologies et systèmes informatiques
[phone]
[e-mail]

-------------
Original Text
From: "Steve Coya" <[e-mail]>, on 9/1/98 8:37 AM:
To: [e-mail]@NHQ
Cc: INET[<[e-mail]>]

Fred,

Your question should be sent to the PKIX Working Group:
[e-mail]




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
>>[phone]
>>[e-mail]
>>
>>
>>

o