RE: NEW Data type for certificate selection ?

Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> Thu, 01 October 1998 01:48 UTC

Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA20401 for <pkix-archive@odin.ietf.org>; Wed, 30 Sep 1998 21:48:50 -0400 (EDT)
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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: 'Dave Horvath ' <dave@chromatix.com>, 'Stefan Santesson ' <stefan@accurata.se>
Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>, "''list@seis.nc-forum.com ' '" <list@seis.nc-forum.com>, "''pgut001@cs.auckland.ac.nz ' '" <pgut001@cs.auckland.ac.nz>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 01 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: owner-ietf-pkix@imc.org
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; 'ietf-pkix@imc.org '; 'list@seis.nc-forum.com ';
'pgut001@cs.auckland.ac.nz '
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 (list@seis.nc-forum.com)
>> >
>> >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: pgut001@cs.auckland.ac.nz
>> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>> >> list@seis.nc-forum.com
>> >> 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 (list@seis.nc-forum.com)
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: info@seis.se
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <stefan@accurata.se>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. +46-40 152211
>> 216 42  Malmö                   Fax. +46-40 150790
>> Sweden                        Mobile +46-70 5247799
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  dave@chromatix.com
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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




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 <ietf-pkix@imc.org>; 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 <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9810010015150.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
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                     egerck@novaware.cps.softex.br
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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'Dave Horvath '" <dave@chromatix.com>, "'Stefan Santesson '" <stefan@accurata.se>
Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>, "''list@seis.nc-forum.com ' '" <list@seis.nc-forum.com>, "''pgut001@cs.auckland.ac.nz ' '" <pgut001@cs.auckland.ac.nz>
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: owner-ietf-pkix@imc.org
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; 'ietf-pkix@imc.org '; 'list@seis.nc-forum.com ';
'pgut001@cs.auckland.ac.nz '
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 (list@seis.nc-forum.com)
>> >
>> >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: pgut001@cs.auckland.ac.nz
>> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>> >> list@seis.nc-forum.com
>> >> 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 (list@seis.nc-forum.com)
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: info@seis.se
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <stefan@accurata.se>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. +46-40 152211
>> 216 42  Malmö                   Fax. +46-40 150790
>> Sweden                        Mobile +46-70 5247799
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  dave@chromatix.com
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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



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 (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03010 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 15:49:51 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19981001005315.009f7d30@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 00:53:52 +0200
To: Dave Horvath <dave@chromatix.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
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: owner-ietf-pkix@imc.org
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 (list@seis.nc-forum.com)
>> >
>> >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: pgut001@cs.auckland.ac.nz
>> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>> >> list@seis.nc-forum.com
>> >> 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 (list@seis.nc-forum.com)
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: info@seis.se
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson                <stefan@accurata.se>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D                  Tel. +46-40 152211
>> 216 42  Malmö                   Fax. +46-40 150790
>> Sweden                        Mobile +46-70 5247799
>> 
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>-- 
>               ================================================
>
>      _/_/_/                   David J. Horvath
>   _/      _/                  
>  _/       _/                  Chromatix, Inc. 
> _/           _/  _/           10451 Twin Rivers Road, Suite 265
>_/            _/_/             Columbia, MD 21044
> _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
>  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  dave@chromatix.com
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; Wed, 30 Sep 1998 15:31:04 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 00:35:02 +0200
To: Ed Gerck <egerck@laser.cps.softex.br>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
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: owner-ietf-pkix@imc.org
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                     egerck@novaware.cps.softex.br
>http://novaware.cps.softex.br
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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 <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9809301211200.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
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                     egerck@novaware.cps.softex.br
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 30 Sep 1998 13:44:11 -0400 (EDT)
Message-ID: <008101bdec99$e9fa7a60$010ed180@klerer.basit.com>
From: "Robert Klerer" <klerer@xhair.com>
To: <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 (list@seis.nc-forum.com)
>>
>>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: pgut001@cs.auckland.ac.nz
>>> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>>> list@seis.nc-forum.com
>>> 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 (list@seis.nc-forum.com)
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: info@seis.se
>>
>>
>>
>-------------------------------------------------------------------
>Stefan Santesson                <stefan@accurata.se>
>Accurata Systemsäkerhet AB
>Lotsgatan 27 D                  Tel. +46-40 152211
>216 42  Malmö                   Fax. +46-40 150790
>Sweden                        Mobile +46-70 5247799
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>



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 <ietf-pkix@imc.org>; 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 dave@chromatix.com)
Message-ID: <3612686B.C127798B@chromatix.com>
Date: Wed, 30 Sep 1998 13:20:43 -0400
From: Dave Horvath <dave@chromatix.com>
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 <stefan@accurata.se>
CC: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
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 (list@seis.nc-forum.com)
> >
> >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: pgut001@cs.auckland.ac.nz
> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
> >> list@seis.nc-forum.com
> >> 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 (list@seis.nc-forum.com)
> >Info about this list: http://www.nc-forum.com/seis
> >SEIS Contact: info@seis.se
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson                <stefan@accurata.se>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. +46-40 152211
> 216 42  Malmö                   Fax. +46-40 150790
> Sweden                        Mobile +46-70 5247799
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------

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

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  dave@chromatix.com


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 (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28786 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 07:39:57 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 30 Sep 1998 16:43:41 +0200
To: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
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: owner-ietf-pkix@imc.org
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 (list@seis.nc-forum.com)
>
>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: pgut001@cs.auckland.ac.nz
>> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>> list@seis.nc-forum.com
>> 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 (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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 dave@chromatix.com)
Message-ID: <36124B27.2FE16E0C@chromatix.com>
Date: Wed, 30 Sep 1998 11:15:51 -0400
From: David Horvath <dave@chromatix.com>
Organization: @Home Network
X-Mailer: Mozilla 4.05 [en]C-AtHome0404  (Win95; U)
MIME-Version: 1.0
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
CC: "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
References: <D1A949D4508DD1119C8100400533BEDC07B96A@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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: pgut001@cs.auckland.ac.nz
> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
> list@seis.nc-forum.com
> 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 <ietf-pkix@imc.org>; 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: <4.1.0.67.19980929132920.009c4d20@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.67 (Beta)
Date: Tue, 29 Sep 1998 13:30:03 -0400
To: Allen_Rochkind@3com.com
From: Russ Housley <housley@spyrus.com>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
Cc: ietf-pkix@imc.org
In-Reply-To: <8825668D.00778D10.00@hqoutbound.ops.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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, Allen_Rochkind@3com.com 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 <ietf-pkix@imc.org>; 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: <199809291206.IAA07388@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <anders.rundgren@jaybis.com>
To: "'Ed Gerck'" <egerck@laser.cps.softex.br>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Cc: "'Stefan Santesson'" <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Mon, 28 Sep 1998 15:25:33 -0700 (PDT)
Message-Id: <199809282225.PAA07281@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Mon, 28 Sep 1998 15:31:45 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: A question and comment about PKIX - Part 1, Version 11.
In-Reply-To: <8825668D.00778D10.00@hqoutbound.ops.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Mon, 28 Sep 1998 14:49:01 -0700 (PDT)
From: Allen_Rochkind@3com.com
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
Message-ID: <8825668D.00778D10.00@hqoutbound.ops.3com.com>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
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: owner-ietf-pkix@imc.org
Precedence: bulk

 
Snip

----------
From: pgut001@cs.auckland.ac.nz
To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
list@seis.nc-forum.com
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 <ietf-pkix@imc.org>; 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 <egerck@laser.cps.softex.br>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
cc: cert-talk@structuredarts.com, ietf-pkix@imc.org, list@seis.nc-forum.com
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <199809281406.HAA29579@gateway-ext.StructuredArts.COM>
Message-ID: <Pine.LNX.4.02.9809281408220.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

On Tue, 29 Sep 1998, Peter Gutmann wrote:

>Stefan Santesson <stefan@accurata.se> 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                     egerck@novaware.cps.softex.br
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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F500139B046@sothmxs01.entrust.com>
From: Robert Zuccherato <robert.zuccherato@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Mon, 28 Sep 1998 07:54:54 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [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 pgut001@cs.auckland.ac.nz)
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90699489017466>; Tue, 29 Sep 1998 03:01:30 (NZST)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cert-talk@structuredarts.com, ietf-pkix@imc.org, list@seis.nc-forum.com
Subject: Re: NEW Data type for certificate selection ?
Reply-To: pgut001@cs.auckland.ac.nz
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: <90699489017466@cs26.cs.auckland.ac.nz>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

Stefan Santesson <stefan@accurata.se> 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 <ietf-pkix@imc.org>; Mon, 28 Sep 1998 07:26:37 -0700 (PDT)
Message-Id: <199809281426.HAA03359@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Mon, 28 Sep 1998 07:32:49 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Questions about PKIX
In-Reply-To: <8525668D.002BF40F.00@mta2.lotus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F500206DD8A@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "'Warwick Ford'" <wford@verisign.com>, "'Steve Kent'" <kent@bbn.com>
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: owner-ietf-pkix@imc.org
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:Alan.Lloyd@OpenDirectory.com.au]
> Sent: 	September 27, 1998 6:24 PM
> To: 	'ietf-pkix@imc.org'
> 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 <ietf-pkix@imc.org>; 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: <360F8B0E.D3FD99CC@iss.isl.melco.co.jp>
Date: Mon, 28 Sep 1998 22:11:42 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <yositake@iss.isl.melco.co.jp>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: Stefan Santesson <stefan@accurata.se>
Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19980928111642.00a76390@m1.403.telia.com>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F500206DD84@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'Santosh Chokhani'" <chokhani@cygnacom.com>
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:chokhani@cygnacom.com]
> Sent: 	September 27, 1998 12:32 PM
> To: 	'Internet-Drafts@ietf.org'
> Cc: 	ietf-pkix@imc.org
> 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:	Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org]
> > Sent:	Thursday, September 24, 1998 10:27 AM
> > Cc:	ietf-pkix@imc.org
> > 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 ietf-pkix@imc.org
> > 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:	mailserv@ietf.org.  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 (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA29632 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 02:14:11 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980928111642.00a76390@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Sep 1998 11:17:31 +0200
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com;
>cert-talk@structuredarts.com
>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                <stefan@accurata.se>
>Accurata Systemsäkerhet AB     
>Lotsgatan 27 D                  Tel. +46-40 152211              
>216 42  Malmö                   Fax. +46-40 150790              
>Sweden                        Mobile +46-70 5247799
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'tyone '" <tyone@iss.isl.melco.co.jp>
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: owner-ietf-pkix@imc.org
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: ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Mon, 28 Sep 1998 00:48:14 -0700 (PDT)
From: Stefan_Salzmann/HAM/Lotus@lotus.com
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
cc: Helmut_Speichermann/FRA/Lotus@lotus.com, Boris_Baltzer/MUC1/Lotus@lotus.com, Georg_Zyprian/FRA/Lotus@lotus.com
Message-ID: <8525668D.002BF40F.00@mta2.lotus.com>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: <360EF227.7D17CD5B@iss.isl.melco.co.jp>
Date: Mon, 28 Sep 1998 11:19:19 +0900
From: tyone <tyone@iss.isl.melco.co.jp>
X-Mailer: Mozilla 4.05 [ja] (WinNT; I)
Mime-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Internet-Drafts@ietf.org'" <Internet-Drafts@ietf.org>
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:	Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org]
> Sent:	Thursday, September 24, 1998 10:27 AM
> Cc:	ietf-pkix@imc.org
> 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 ietf-pkix@imc.org
> 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:	mailserv@ietf.org.  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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'ietf-tls@consensus.com '" <ietf-tls@consensus.com>, "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>, "'Stefan Santesson '" <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com;
cert-talk@structuredarts.com
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                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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



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 <ietf-pkix@imc.org>; 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: <3.0.32.19980925090738.0094f7e8@mail.verisign.com>
X-Sender: mmyers@mail.verisign.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Sep 1998 09:24:36 -0700
To: Denis Pinkas <Denis.Pinkas@bull.net>, IETF-PXIX <ietf-pkix@imc.org>
From: Michael Myers <mmyers@verisign.com>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <199809251427.KAA06021@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-08.txt
Date: Fri, 25 Sep 1998 10:27:54 -0400
Sender: owner-ietf-pkix@imc.org
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 ietf-pkix@imc.org 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:	mailserv@ietf.org.  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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980924132531.I-D@ietf.org>

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:	<19980924132531.I-D@ietf.org>

--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 <ietf-pkix@imc.org>; Fri, 25 Sep 1998 04:30:59 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980925133351.00a88250@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Sep 1998 13:34:29 +0200
To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com'" <list@seis.nc-forum.com>, "'cert-talk@structuredarts.com'" <cert-talk@structuredarts.com>
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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:stefan@accurata.se]
>>Sent: 	Thursday, September 24, 1998 8:41 AM
>>To: 	ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com;
>>cert-talk@structuredarts.com
>>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                <stefan@accurata.se>
>>Accurata Systemsäkerhet AB     
>>Lotsgatan 27 D                  Tel. +46-40 152211              
>>216 42  Malmö                   Fax. +46-40 150790              
>>Sweden                        Mobile +46-70 5247799
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>>
>
>Attachment Converted: "c:\internet\eudora\attach\MATCH2.DOC"
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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: <360B627F.981A419E@iss.isl.melco.co.jp>
Date: Fri, 25 Sep 1998 18:29:35 +0900
From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <yositake@iss.isl.melco.co.jp>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: Stefan Santesson <stefan@accurata.se>
Cc: ietf-pkix@imc.org, list@seis.nc-forum.com, ietf-tls@consensus.com, cert-talk@structuredarts.com
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19980924144039.00a6ccf0@m1.403.telia.com>
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: owner-ietf-pkix@imc.org
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                <stefan@accurata.se>
> Accurata Systems$BgL(Berhet AB
> Lotsgatan 27 D                  Tel. +46-40 152211
> 216 42  Malm$Bö (B                  Fax. +46-40 150790
> Sweden                        Mobile +46-70 5247799
>
> 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <B0000285171@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; 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 <01BDE7B3.263212E0@avenger.missi.ncsc.mil>; Thu, 24 Sep 1998 12:02:06 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-980924160205Z-6343@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com'" <list@seis.nc-forum.com>, "'ietf-tls@consensus.com'" <ietf-tls@consensus.com>, "'cert-talk@structuredarts.com'" <cert-talk@structuredarts.com>, "'Stefan Santesson'" <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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:stefan@accurata.se]
>Sent: 	Thursday, September 24, 1998 8:41 AM
>To: 	ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com;
>cert-talk@structuredarts.com
>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                <stefan@accurata.se>
>Accurata Systems=E4kerhet AB    =20
>Lotsgatan 27 D                  Tel. +46-40 152211             =20
>216 42  Malm=F6                   Fax. +46-40 150790             =20
>Sweden                        Mobile +46-70 5247799
>
>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 (root@you.got.net [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21791 for <ietf-pkix@imc.org>; 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: <360A5FAF.9012BC3D@got.net>
Date: Thu, 24 Sep 1998 08:05:20 -0700
From: Michael McNeil <memcneil@got.net>
Organization: GMT
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Denis Pinkas <Denis.Pinkas@bull.net>
CC: Stephen Kent <kent@bbn.com>, Warwick Ford <wford@verisign.com>, ietf-pkix@imc.org, Jeffrey Schiller <jis@mit.edu>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <3609BEDD.B8F71C12@got.net> <360A8F3E.B7DA84C5@bull.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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
memcneil@got.net
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 <ietf-pkix@imc.org>; 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 <m0zMCQA-0004eAC@bilbo.thawte.com> (Debian Smail3.2.0.101) for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 16:31:02 +0200 (SAST) 
Message-ID: <360A56AA.93669667@thawte.com>
Date: Thu, 24 Sep 1998 16:26:50 +0200
From: Mark Shuttleworth <marks@thawte.com>
Reply-To: marks@thawte.com
Organization: Thawte Consulting
X-Mailer: Mozilla 4.5b2 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms78C9DE34404C8A045EF33A31"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <199809241427.KAA02163@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
Date: Thu, 24 Sep 1998 10:27:24 -0400
Sender: owner-ietf-pkix@imc.org
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 ietf-pkix@imc.org 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:	mailserv@ietf.org.  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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980923172008.I-D@ietf.org>

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:	<19980923172008.I-D@ietf.org>

--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 <ietf-pkix@imc.org>; 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: <199809241426.KAA02093@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-dcs-00.txt
Date: Thu, 24 Sep 1998 10:26:39 -0400
Sender: owner-ietf-pkix@imc.org
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:	mailserv@ietf.org.  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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980923134838.I-D@ietf.org>

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:	<19980923134838.I-D@ietf.org>

--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 <ietf-pkix@imc.org>; 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: <199809241426.KAA02081@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-00.txt
Date: Thu, 24 Sep 1998 10:26:34 -0400
Sender: owner-ietf-pkix@imc.org
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:	mailserv@ietf.org.  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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980923134327.I-D@ietf.org>

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:	<19980923134327.I-D@ietf.org>

--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 <ietf-pkix@imc.org>; 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: <199809241426.KAA02063@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-11.txt
Date: Thu, 24 Sep 1998 10:26:08 -0400
Sender: owner-ietf-pkix@imc.org
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 ietf-pkix@imc.org 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:	mailserv@ietf.org.  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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980923132903.I-D@ietf.org>

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:	<19980923132903.I-D@ietf.org>

--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 <ietf-pkix@imc.org>; 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: <199809241412.HAA09631@spyrus.com>
X-Sender: rhousley@mail.spyrus.com (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" <TSGman@earthlink.net>
From: Russ Housley <housley@spyrus.com>
Subject: Re: Amending the PKIX-WG Charter to reflect the addition of timestamping
Cc: ietf-pkix@imc.org
In-Reply-To: <001c01bde698$615e7640$200ba8c0@tsg-laptop>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <kent@bbn.com>
>Warwick Ford <wford@verisign.com>
>
>Security Area Director(s):
>Jeffrey Schiller <jis@mit.edu>
>Marcus Leech <mleech@nortel.ca>
>
>Security Area Advisor:
>Jeffrey Schiller <jis@mit.edu>
>
>Mailing Lists:
>General Discussion:ietf-pkix@imc.org
>To Subscribe: ietf-pkix-request@imc.org
>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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F500206DD59@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: CryptoNEWS@aol.com, "'Denis Pinkas'" <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net]
> Sent: 	September 24, 1998 2:59 PM
> To: 	CryptoNEWS@aol.com
> Cc: 	ietf-pkix@imc.org
> Subject: 	Re: X.509 Documentation
> 
> CryptoNEWS@aol.com 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 (root@maild.telia.com [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20853 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 05:38:04 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980924144039.00a6ccf0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 24 Sep 1998 14:41:23 +0200
To: ietf-pkix@imc.org, list@seis.nc-forum.com, ietf-tls@consensus.com, cert-talk@structuredarts.com
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; Thu, 24 Sep 1998 04:54:02 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [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 pgut001@cs.auckland.ac.nz)
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90663837419831>; Thu, 24 Sep 1998 23:59:34 (NZST)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: Petra.Gloeckner@darmstadt.gmd.de, ietf-pkix@imc.org
Subject: Re: basic constraint extension
Reply-To: pgut001@cs.auckland.ac.nz
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: <90663837419831@cs26.cs.auckland.ac.nz>
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <360A968C.FD285E0E@bull.net>
Date: Thu, 24 Sep 1998 11:59:24 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: CryptoNEWS@aol.com
CC: ietf-pkix@imc.org
Subject: Re: X.509 Documentation
References: <4932bdcf.360a0cc8@aol.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

CryptoNEWS@aol.com 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 <ietf-pkix@imc.org>; 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: <360A8F3E.B7DA84C5@bull.net>
Date: Thu, 24 Sep 1998 11:28:15 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Michael McNeil <memcneil@got.net>
CC: Stephen Kent <kent@bbn.com>, Warwick Ford <wford@verisign.com>, ietf-pkix@imc.org, Jeffrey Schiller <jis@mit.edu>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <3609BEDD.B8F71C12@got.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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
> memcneil@got.net
> 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 <ietf-pkix@imc.org>; Thu, 24 Sep 1998 02:05:50 -0700 (PDT)
From: CryptoNEWS@aol.com
Received: from CryptoNEWS@aol.com by imo26.mx.aol.com (IMOv16.10) id 7HBDa02301 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 05:11:36 -0400 (EDT)
Message-ID: <4932bdcf.360a0cc8@aol.com>
Date: Thu, 24 Sep 1998 05:11:36 EDT
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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 (root@you.got.net [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29799 for <ietf-pkix@imc.org>; 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: <3609BEDD.B8F71C12@got.net>
Date: Wed, 23 Sep 1998 20:39:10 -0700
From: Michael McNeil <memcneil@got.net>
Organization: GMT
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>, Warwick Ford <wford@verisign.com>
CC: ietf-pkix@imc.org, Jeffrey Schiller <jis@mit.edu>
Subject: Re: meeting minutes
References: <v04011701b22c2cbc4e8e@[128.33.238.151]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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
memcneil@got.net
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 <ietf-pkix@imc.org>; Wed, 23 Sep 1998 11:00:08 -0700 (PDT)
Message-Id: <199809231800.LAA24404@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Wed, 23 Sep 1998 11:05:32 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Fwd: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

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

--Paul Hoffman, Director
--Internet Mail Consortium

>To: IETF-Announce: ;
>Cc: ietf-tls@consensus.com
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-ietf-tls-ac509prof-00.txt
>Date: Wed, 23 Sep 1998 10:43:01 -0400
>Sender: cclark@ns.cnri.reston.va.us
>
>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:	mailserv@ietf.org.  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:	<19980922141332.I-D@ietf.org>
>
>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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F50AC97BC@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Cc: "'Steve Kent'" <kent@bbn.com>, "'Warwick Ford'" <wford@verisign.com>
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: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 
       



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 (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21060 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 04:29:00 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980923133149.00a71210@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 23 Sep 1998 13:32:27 +0200
To: Al Arsenault <aarsenault@spyrus.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil>
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 23 Sep 1998 10:03:37 +0200 (DFT)
Message-ID: <360929FB.C577E062@bull.net>
Date: Wed, 23 Sep 1998 10:03:55 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <ietf-pkix@imc.org>
Subject: Archive cutoff & Retention period
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 23 Sep 1998 09:59:22 +0200 (DFT)
Message-ID: <360928FB.2D9D963E@bull.net>
Date: Wed, 23 Sep 1998 09:59:40 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <ietf-pkix@imc.org>
Subject: Minor comments on OCSP-06
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Tue, 22 Sep 1998 19:20:08 -0700 (PDT)
From: "Todd S. Glassey" <TSGman@earthlink.net>
To: "Ietf-Pkix" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <kent@bbn.com>
Warwick Ford <wford@verisign.com>

Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>

Mailing Lists:
General Discussion:ietf-pkix@imc.org
To Subscribe: ietf-pkix-request@imc.org
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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F50AC97A8@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Cc: "'Steve Kent'" <kent@bbn.com>, "'Warwick Ford'" <wford@verisign.com>, "'Santosh Chokhani'" <chokhani@sisko.cygnacom.com>
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: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 
       



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 <ietf-pkix@imc.org>; 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: <3.0.6.32.19980922081543.00902790@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 22 Sep 1998 08:15:43 -0400
To: Stefan Santesson <stefan@accurata.se>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: Re: PKIX Roadmap
In-Reply-To: <3.0.32.19980922062458.00a7e6f0@m1.403.telia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <anders.rundgren@jaybis.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <36076D59.62280554@darmstadt.gmd.de>
Date: Tue, 22 Sep 1998 11:26:49 +0200
From: "Petra Glöckner" <Petra.Gloeckner@darmstadt.gmd.de>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: ietf-pkix@imc.org
CC: herfert@darmstadt.gmd.de
Subject: basic constraint extension
References: <199809081502.LAA04610@ietf.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6C21A3596B2679A5F64C275F"
Sender: owner-ietf-pkix@imc.org
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: Petra.Gloeckner@darmstadt.gmd.de
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 <ietf-pkix@imc.org>; Mon, 21 Sep 1998 21:22:01 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980922062458.00a7e6f0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 22 Sep 1998 06:25:35 +0200
To: Al Arsenault <aarsenault@spyrus.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil>
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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: <3.0.6.32.19980921133257.009044e0@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Mon, 21 Sep 1998 13:32:57 -0400
To: Stefan Santesson <stefan@accurata.se>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: Re: PKIX Roadmap
In-Reply-To: <3.0.32.19980921161854.00a71640@m1.403.telia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Mon, 21 Sep 1998 12:23:14 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1305727475==_ma============"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011701b22c2cbc4e8e@[128.33.238.151]>
Date: Mon, 21 Sep 1998 12:20:00 -0400
To: ietf-pkix@imc.org
From: Stephen Kent <kent@bbn.com>
Subject: meeting minutes
Sender: owner-ietf-pkix@imc.org
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:
imc-pfi@imc.org.



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:
imc-pfi@imc.org.




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 <ietf-pkix@imc.org>; Mon, 21 Sep 1998 07:34:21 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980921161854.00a71640@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 21 Sep 1998 16:19:49 +0200
To: Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil>
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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: <36067C64.DE008EBB@bull.net>
Date: Mon, 21 Sep 1998 09:18:44 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@jaybis.com>
CC: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: OCSP - Public Key Dstribution
References: <01BDE484.F1DA1820@HYDRA>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net]
> Sent:  Saturday, September 19, 1998 02:15
> To:  Andreas Berger
> Cc:  Peter Sylvester; ambarish@valicert.com; ietf-pkix@imc.org
> 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:Denis.Pinkas@bull.net
>  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:Denis.Pinkas@bull.net
 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 <ietf-pkix@imc.org>; 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: <36067EF5.8F246720@bull.net>
Date: Mon, 21 Sep 1998 09:29:41 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Michael Myers <mmyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <3.0.32.19980918180005.00920ee4@mail.verisign.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net
 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 (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04793 for <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Mon, 21 Sep 1998 10:08:18 +1000 (EST)
Message-Id: <199809210008.KAA06232@typhoon.dstc.qut.edu.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: ietf-pkix@imc.org
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 <povey@dstc.qut.edu.au>
Sender: owner-ietf-pkix@imc.org
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: povey@dstc.edu.au     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




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 <ietf-pkix@imc.org>; 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 <Peter.Sylvester@edelweb.fr>
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: <199809201741.TAA18646@emeriau.edelweb.fr>
To: anders.rundgren@jaybis.com
Subject: Re: OCSP - Public Key Dstribution
Cc: ietf-pkix@imc.org
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <Peter.Sylvester@edelweb.fr>
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: <199809201741.TAA18643@emeriau.edelweb.fr>
To: ietf-pkix@imc.org, mmyers@verisign.com
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <anders.rundgren@jaybis.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net]
Sent:  Saturday, September 19, 1998 02:15
To:  Andreas Berger
Cc:  Peter Sylvester; ambarish@valicert.com; ietf-pkix@imc.org
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:Denis.Pinkas@bull.net
 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 <ietf-pkix@imc.org>; 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: <amit@netcom.com>
From: "Amit Kapoor" <amit@netcom.com>
To: "PKIX" <ietf-pkix@imc.org>
Subject: Testing the ASN.1 in Part 1
Date: Sat, 19 Sep 1998 13:58:24 -0700
Message-ID: <001a01bde410$3dbd7cc0$0a01040a@mordor.cylink.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.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <3.0.32.19980918180005.00920ee4@mail.verisign.com>
X-Sender: mmyers@mail.verisign.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 18 Sep 1998 18:00:08 -0700
To: ietf-pkix@imc.org
From: Michael Myers <mmyers@verisign.com>
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <3.0.3.32.19980918143811.00b1f6e0@poptop.llnl.gov>
X-Sender: e048786@poptop.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 18 Sep 1998 14:38:11 -0700
To: "Flanigan, Bill" <flanigab@ncr.disa.mil>, ietf-pkix@imc.org
From: Tony Bartoletti <azb@llnl.gov>
Subject: RE: proposed text for attributes
In-Reply-To: <5F21F6A15446D211B0730020484016A34A8DED@RBMAIL103>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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: azb@llnl.gov   phone: 510-422-3881             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 <ietf-pkix@imc.org>; 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" <flanigab@ncr.disa.mil>
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:           (703) 681-2318
Defense Information Systems Agency      Fax:           (703) 681-2814 
Information Assurance Engineering       DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           (703) 681-2318   
Falls Church, VA 22041-2717        Internet:  <flanigab@ncr.disa.mil>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:phoffman@imc.org]
> Sent:	Friday, September 18, 1998 12:39 PM
> To:	ietf-pkix@imc.org
> 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 (jan@romulus.cs.ut.ee [193.40.5.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23951 for <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Fri, 18 Sep 1998 21:15:08 +0300 (EET DST)
Date: Fri, 18 Sep 1998 21:15:06 +0300 (   )
From: Jan Willemson <jan@cs.ut.ee>
To: ietf-pkix@imc.org
Subject: Who uses what?
Message-ID: <Pine.GSO.4.02A.9809182058590.12460-100000@romulus.cs.ut.ee>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
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: <199809181728.KAA15812@spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Fri, 18 Sep 1998 13:29:49 -0400
To: Dean Povey <povey@dstc.qut.edu.au>
From: Russ Housley <housley@spyrus.com>
Subject: Re: Testing the ASN.1 in Part 1 
Cc: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pkix@imc.org
In-Reply-To: <199809180548.PAA24765@typhoon.dstc.qut.edu.au>
References: <Your message of "Tue, 15 Sep 1998 14:29:01 +1000."             <199809150429.OAA08287@typhoon.dstc.qut.edu.au>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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:
povey@dstc.edu.au&nbsp;&nbsp;&nbsp;&nbsp; | Cryptozilla:<br>
&gt;Research Scientist&nbsp; | ph:&nbsp; +61 7 3864
5120&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
<a href="http://www.cryptozilla.org/" eudora="autourl">www.cryptozilla.org/</a><br>
&gt;Security Unit, DSTC | fax: +61 7 3864
1282&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Oscar - PKI Toolkit:<br>
&gt;Brisbane, Australia | www: security.dstc.edu.au/ |&nbsp;
oscar.dstc.qut.edu.au/<br>
&gt;<br>
&gt;<br>
</html>



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 <ietf-pkix@imc.org>; Fri, 18 Sep 1998 09:33:45 -0700 (PDT)
Message-Id: <199809181633.JAA23013@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Fri, 18 Sep 1998 09:39:16 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: proposed text for attributes
In-Reply-To: <D789F71F24B4D111955D00A0C99B4F50AC9788@sothmxs01.entrust.c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <Peter.Sylvester@edelweb.fr>
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: <199809181541.RAA17885@emeriau.edelweb.fr>
To: aberger@darmstadt.gmd.de, Denis.Pinkas@bull.net
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: ambarish@valicert.com, ietf-pkix@imc.org
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <3602F778.27E7C98D@bull.net>
Date: Fri, 18 Sep 1998 17:14:48 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Andreas Berger <aberger@darmstadt.gmd.de>
CC: Peter Sylvester <Peter.Sylvester@edelweb.fr>, ambarish@valicert.com, ietf-pkix@imc.org
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <199809180856.KAA17797@emeriau.edelweb.fr> <360230B4.B31B53E8@darmstadt.gmd.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net
 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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F50AC9788@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 
       



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 <ietf-pkix@imc.org>; 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: <360230B4.B31B53E8@darmstadt.gmd.de>
Date: Fri, 18 Sep 1998 12:06:44 +0200
From: Andreas Berger <aberger@darmstadt.gmd.de>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: Peter Sylvester <Peter.Sylvester@edelweb.fr>
CC: ambarish@valicert.com, ietf-pkix@imc.org
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <199809180856.KAA17797@emeriau.edelweb.fr>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <Peter.Sylvester@edelweb.fr>
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: <199809180902.LAA17802@emeriau.edelweb.fr>
To: ietf-pkix@imc.org, danjw1@pacbell.net
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <Peter.Sylvester@edelweb.fr>
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: <199809180856.KAA17797@emeriau.edelweb.fr>
To: ambarish@valicert.com
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Cc: ietf-pkix@imc.org
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <36021C9D.7B5FFABE@pacbell.net>
Date: Fri, 18 Sep 1998 01:41:01 -0700
From: Dan Weinstein <danjw1@pacbell.net>
X-Mailer: Mozilla 4.5b2 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org, Peter.Sylvester@edelweb.fr
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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
danjw1@pacbell.net


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 (root@typhoon.dstc.qut.edu.au [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: <199809180548.PAA24765@typhoon.dstc.qut.edu.au>
X-Mailer: exmh version 2.0.2 2/24/98
cc: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pkix@imc.org
Subject: Re: Testing the ASN.1 in Part 1 
In-reply-to: Your message of "Tue, 15 Sep 1998 14:29:01 +1000." <199809150429.OAA08287@typhoon.dstc.qut.edu.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Sep 1998 15:47:57 +1000
From: Dean Povey <povey@dstc.qut.edu.au>
Sender: owner-ietf-pkix@imc.org
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: povey@dstc.edu.au     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




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 (qmailr@old-atlantic.valicert.com [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26259 for <ietf-pkix@imc.org>; 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: <360184DB.74788BAE@valicert.com>
Date: Thu, 17 Sep 1998 14:53:31 -0700
From: Ambarish Malpani <ambarish@valicert.com>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b2 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
References: <199809171636.SAA17487@emeriau.edelweb.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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.				        ambarish@valicert.com
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Thu, 17 Sep 1998 18:36:02 +0200
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA17487 for ietf-pkix@imc.org; Thu, 17 Sep 1998 18:36:01 +0200
Date: Thu, 17 Sep 1998 18:36:01 +0200
Message-Id: <199809171636.SAA17487@emeriau.edelweb.fr>
To: ietf-pkix@imc.org
Subject: fast review of draft-ietf-pkix-ocsp-06.txt
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F50AC9785@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: ietf-pkix@imc.org, "'bgmiller@dc.jones.com'" <bgmiller@dc.jones.com>
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: owner-ietf-pkix@imc.org
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:bgmiller@dc.jones.com]
> Sent: 	September 16, 1998 10:26 PM
> To: 	ietf-pkix@imc.org
> 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 <ietf-pkix@imc.org>; 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: <418B8B7ACE69D111879B00805F6F281DFFF5B7@exccup-25006.mis.tandem.com>
From: "Kurn, David" <david.kurn@compaq.com>
To: "'bgmiller@dc.jones.com'" <bgmiller@dc.jones.com>, ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:bgmiller@dc.jones.com]
Sent: Wednesday, September 16, 1998 7:27 PM
To: ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <199809171409.KAA14218@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ocsp-06.txt
Date: Thu, 17 Sep 1998 10:09:49 -0400
Sender: owner-ietf-pkix@imc.org
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:	mailserv@ietf.org.  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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980916113902.I-D@ietf.org>

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:	<19980916113902.I-D@ietf.org>

--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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 16 Sep 1998 22:27:11 -0400 (EDT)
Message-ID: <3600735C.98A336F8@dc.jones.com>
Date: Wed, 16 Sep 1998 22:26:37 -0400
From: bgmiller <bgmiller@dc.jones.com>
Reply-To: bgmiller@dc.jones.com
Organization: Jones Internet Channel
X-Mailer: Mozilla 4.05 [en]C-JIC-DC  (Win95; I)
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory Attributes
References: <199809162243.PAA27828@mail.proper.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Wed, 16 Sep 1998 15:43:36 -0700 (PDT)
Message-Id: <199809162243.PAA27828@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 16 Sep 1998 15:49:01 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attributes
In-Reply-To: <418B8B7ACE69D111879B00805F6F281DFFF5AE@exccup-25006.mis.ta ndem.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <418B8B7ACE69D111879B00805F6F281DFFF5AE@exccup-25006.mis.tandem.com>
From: "Kurn, David" <david.kurn@compaq.com>
To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:chokhani@cygnacom.com]
Sent: Wednesday, September 16, 1998 2:23 PM
To: ietf-pkix@imc.org
Subject: Storage of CA Certificates in LDAP and X.500 Directory
Attributes


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

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

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

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

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


Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
chokhani@cygancom.com
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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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
(703) 848-0883 (voice)
(703) 848-0960 (fax)
chokhani@cygancom.com
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 <ietf-pkix@imc.org>; 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: <3.0.32.19980915134441.0129cf5c@mail.verisign.com>
X-Sender: wford@mail.verisign.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 15 Sep 1998 13:52:32 -0700
To: ietf-pkix@imc.org
From: Warwick Ford <wford@verisign.com>
Subject: Schema Straw Poll Closure
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 (781)2456996 x225; Fax (781)2456006
wford@verisign.com;  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 (root@firewall.globeset.com [207.239.133.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11376 for <ietf-pkix@imc.org>; Tue, 15 Sep 1998 08:56:24 -0700 (PDT)
Received: from drought.globeset.com (trevor@drought.globeset.com [10.1.192.39]) by firewall.globeset.com (8.9.0/8.9.0) with ESMTP id LAA26296 for <ietf-pkix@imc.org>; 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 <trevor@globeset.com>
Date: Tue, 15 Sep 1998 11:02:01 -0500 (CDT)
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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 (root@typhoon.dstc.qut.edu.au [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: <199809150429.OAA08287@typhoon.dstc.qut.edu.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: Paul Hoffman / IMC <phoffman@imc.org>
cc: ietf-pkix@imc.org
Subject: Re: Testing the ASN.1 in Part 1 
In-reply-to: Your message of "Mon, 14 Sep 1998 08:36:12 MST." <199809141530.IAA08890@mail.proper.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 15 Sep 1998 14:29:01 +1000
From: Dean Povey <povey@dstc.qut.edu.au>
Sender: owner-ietf-pkix@imc.org
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: povey@dstc.edu.au     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




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 <B0002256729@mailgate.apple.com>; 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: <199809141718.KAA10684@scv1.apple.com>
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" <aram@apple.com>
To: "Paul Hoffman / IMC" <phoffman@imc.org>, ietf-pkix@imc.org
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 (qmailr@old-atlantic.valicert.com [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA09709 for <ietf-pkix@imc.org>; 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: <35FD4DD3.C7E6F4F4@valicert.com>
Date: Mon, 14 Sep 1998 10:09:39 -0700
From: Ambarish Malpani <ambarish@valicert.com>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Andreas Berger <aberger@darmstadt.gmd.de>
CC: pkix <ietf-pkix@imc.org>
Subject: Re: OCSP ASN.1 comments
References: <35FD13B7.DE69F00D@darmstadt.gmd.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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.				        ambarish@valicert.com
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 <ietf-pkix@imc.org>; Mon, 14 Sep 1998 08:30:52 -0700 (PDT)
Message-Id: <199809141530.IAA08890@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 14 Sep 1998 08:36:12 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Testing the ASN.1 in Part 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Mon, 14 Sep 1998 15:01:21 +0200 (MET DST)
Message-ID: <35FD13B7.DE69F00D@darmstadt.gmd.de>
Date: Mon, 14 Sep 1998 15:01:43 +0200
From: Andreas Berger <aberger@darmstadt.gmd.de>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: pkix <ietf-pkix@imc.org>
Subject: OCSP ASN.1 comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Sat, 12 Sep 1998 15:22:48 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [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: <3.0.32.19980913002508.00a62ae0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 13 Sep 1998 00:25:48 +0200
To: Mike Smith <mfsmith@zionsbank.com>, ietf-pkix@imc.org
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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 <stefan@accurata.se> 09/11 8:44 AM >>>
>******************  InterScan Message (on zbc2)
>
>noname is scanned and no virus found
>*********************************************************
>












    !
>!
>


                                                           
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; Sat, 12 Sep 1998 14:23:47 -0700 (PDT)
Message-ID: <A1019E9C2D34D211A501006008C2045001BF66@MAIL>
From: Charles Moore <cmoore@spyrus.com.au>
To: "'Peter Lipp'" <Peter.Lipp@iaik.tu-graz.ac.at>, Paul Koning <pkoning@xedia.com>, mfsmith@zionsbank.com
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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: +61 73 256 7465, 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 <ietf-pkix@imc.org>; 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" <Peter.Lipp@iaik.tu-graz.ac.at>
To: "Paul Koning" <pkoning@xedia.com>, <mfsmith@zionsbank.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Fri, 11 Sep 1998 21:59:08 +0200
Message-ID: <000001bdddbe$a311f630$0a03a8c0@plipp.iaik.tu-graz.ac.at>
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: <199809111807.OAA28256@tonga.xedia.com>
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <s5f91899.098@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 12:33:22 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: pkoning@xedia.com
Cc: stefan@accurata.se, ietf-pkix@imc.org
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
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 <pkoning@xedia.com> 09/11 12:07 PM >>>
>>>>> "Mike" == Mike Smith <mfsmith@zionsbank.com> 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 <ietf-pkix@imc.org>; 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: <199809111807.OAA28256@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: mfsmith@zionsbank.com
Cc: stefan@accurata.se, ietf-pkix@imc.org
Subject: Re: RE: New Extension Proposed: Method Of Authentication
References: <s5f8f745.021@zionsbank.com>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

>>>>> "Mike" == Mike Smith <mfsmith@zionsbank.com> 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 <ietf-pkix@imc.org>; 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: <s5f8f890.088@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 10:16:37 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: stefan@accurata.se, ietf-pkix@imc.org
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
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 <stefan@accurata.se> 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 <ietf-pkix@imc.org>; 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: <s5f8f745.021@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 11 Sep 1998 10:11:04 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: stefan@accurata.se, ietf-pkix@imc.org
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
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 <stefan@accurata.se> 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 <ietf-pkix@imc.org>; 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 dave@chromatix.com)
Message-ID: <35F93C79.E50E1015@chromatix.com>
Date: Fri, 11 Sep 1998 11:06:33 -0400
From: Dave Horvath <dave@chromatix.com>
Organization: Chromatix Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780)
MIME-Version: 1.0
To: Denis.Pinkas@bull.net
CC: Santosh Chokhani <chokhani@cygnacom.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER> <35F96A8E.6C3A@bull.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net]
> > > Sent: Wednesday, September 09, 1998 8:44 PM
> > > To:   Santosh Chokhani
> > > Cc:   'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > 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:sharon.boeyen@entrust.com]
> > > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > > To:   'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > > > Subject:      RE: forward & reverse elements - population
> > > > >
> > > > >
> > > > >
> > > > > > ----------
> > > > > > From:       Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > > > Sent:       September 8, 1998 10:05 AM
> > > > > > To:         'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > > > 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:Denis.Pinkas@bull.net
> > >       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:Denis.Pinkas@bull.net
>       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:  (301) 596-8466  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  dave@chromatix.com


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 (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21098 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 07:41:22 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id QAA00126 for <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Fri, 11 Sep 1998 16:46:46 +0200 (CEST)
Message-Id: <3.0.32.19980911164344.00996d60@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 11 Sep 1998 16:44:21 +0200
To: <ietf-pkix@imc.org>
From: Stefan Santesson <stefan@accurata.se>
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: owner-ietf-pkix@imc.org
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                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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


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 <ietf-pkix@imc.org>; 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: <35F96A8E.6C3A@bull.net>
Date: Fri, 11 Sep 1998 11:23:10 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Reply-To: Denis.Pinkas@bull.net
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@cygnacom.com>
CC: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net]
> > Sent: Wednesday, September 09, 1998 8:44 PM
> > To:   Santosh Chokhani
> > Cc:   'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > 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:sharon.boeyen@entrust.com]
> > > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > > To:   'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > > Subject:      RE: forward & reverse elements - population
> > > >
> > > >
> > > >
> > > > > ----------
> > > > > From:       Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > > Sent:       September 8, 1998 10:05 AM
> > > > > To:         'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > > 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:Denis.Pinkas@bull.net
> >       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:Denis.Pinkas@bull.net
      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 <ietf-pkix@imc.org>; Fri, 11 Sep 1998 00:54:09 -0700 (PDT)
Message-Id: <199809110919.KAA08686@ns0.zergo.com>
Received: forwarded by SMTP 3.0.6.
From: Graham Bland <gbland@zergo.com>
Date: Fri, 11 Sep 1998 8:49:49 +0000
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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: mfsmith@zionsbank.com
> Sent: 10 September 1998 18:06
> To: Ian Roberts; Graham Bland; Chris Wright; chokhani@cygnacom.com;
> azb@llnl.gov; william.burr@nist.gov; BJUENEMAN@novell.com;
> pbaker@verisign.com
> Cc: ietf-pkix@imc.org
> 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 <chokhani@cygnacom.com> 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:azb@llnl.gov]
> > Sent: Wednesday, September 09, 1998 3:12 PM
> > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> > william.burr@nist.gov; BJUENEMAN@novell.com
> > Cc: ietf-pkix@imc.org
> > 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:pbaker@verisign.com]
> > >> Sent: Wednesday, September 09, 1998 1:16 PM
> > >> To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com
> > >> Cc: ietf-pkix@imc.org
> > >> 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: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com



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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <B0000267235@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; 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 <01BDDCCE.A3748CA0@avenger.missi.ncsc.mil>; Thu, 10 Sep 1998 15:21:09 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-980910192109Z-33919@avenger.missi.ncsc.mil>
From: "Fillingham,  David W." <dwfilli@missi.ncsc.mil>
To: "'Mike Smith'" <mfsmith@zionsbank.com>, "'chokhani@cygnacom.com'" <chokhani@cygnacom.com>, "'azb@llnl.gov'" <azb@llnl.gov>, "'william.burr@nist.gov'" <william.burr@nist.gov>, "'BJUENEMAN@novell.com'" <BJUENEMAN@novell.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:pbaker@verisign.com]
>Sent: 	Thursday, September 10, 1998 1:48 PM
>To: 	Mike Smith; chokhani@cygnacom.com; azb@llnl.gov; william.burr@nist.gov;
>BJUENEMAN@novell.com
>Cc: 	ietf-pkix@imc.org
>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 <ietf-pkix@imc.org>; 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" <pbaker@verisign.com>
To: "Mike Smith" <mfsmith@zionsbank.com>, <chokhani@cygnacom.com>, <azb@llnl.gov>, <william.burr@nist.gov>, <BJUENEMAN@novell.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: RE: New Extension Proposed: Method Of Authentication
Date: Thu, 10 Sep 1998 13:48:20 -0400
Message-ID: <002001bddce3$3318eb80$9d07a8c0@pbaker-pc.verisign.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
In-Reply-To: <s5f7a303.014@zionsbank.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <s5f7a303.014@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 10 Sep 1998 09:59:21 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: chokhani@cygnacom.com, azb@llnl.gov, william.burr@nist.gov, BJUENEMAN@novell.com, pbaker@verisign.com
Cc: ietf-pkix@imc.org
Subject: Re: RE: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
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 <chokhani@cygnacom.com> 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:azb@llnl.gov] 
> Sent: Wednesday, September 09, 1998 3:12 PM
> To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> william.burr@nist.gov; BJUENEMAN@novell.com 
> Cc: ietf-pkix@imc.org 
> 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:pbaker@verisign.com] 
> >> Sent: Wednesday, September 09, 1998 1:16 PM
> >> To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com 
> >> Cc: ietf-pkix@imc.org 
> >> 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: azb@llnl.gov   phone: 510-422-3881             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 <ietf-pkix@imc.org>; Thu, 10 Sep 1998 08:43:50 -0700 (PDT)
Message-Id: <199809101543.IAA22911@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 10 Sep 1998 08:49:00 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Fwd: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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: ipsec@tis.com
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt
>Date: Thu, 10 Sep 1998 10:34:19 -0400
>Sender: cclark@ns.cnri.reston.va.us
>
>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 ipsec@tis.com
>          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:	mailserv@ietf.org.  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:	<19980909162526.I-D@ietf.org>
>
>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 (NoBody@slack.lne.com [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22534 for <ietf-pkix@imc.org>; 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 <ericm@lne.com>
Message-Id: <199809101519.IAA12666@slack.lne.com>
Subject: Re: New Extension Proposed: Method Of Authentication
To: pkoning@xedia.com (Paul Koning)
Date: Thu, 10 Sep 1998 08:19:49 -0700 (PDT)
Cc: azb@llnl.gov, ietf-pkix@imc.org
In-Reply-To: <199809101321.JAA14290@tonga.xedia.com> 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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <199809101321.JAA14290@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: azb@llnl.gov
Cc: ietf-pkix@imc.org
Subject: RE: New Extension Proposed: Method Of Authentication
References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> <3.0.3.32.19980909162025.00a06390@poptop.llnl.gov>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

>>>>> "Tony" == Tony Bartoletti <azb@llnl.gov> 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Thu, 10 Sep 1998 18:38:00 +0530
Message-ID: <000b01bddcbc$29a0ac40$546801c4@TinTins.fcpl.co.in>
From: "Shailesh" <shailesh@fcpl.co.in>
To: <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <35F84A56.32A2@bull.net>
Date: Thu, 10 Sep 1998 14:53:26 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Reply-To: Denis.Pinkas@bull.net
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Eric Murray <ericm@lne.com>
CC: ietf-pkix@imc.org
Subject: Re: New Extension Proposed: Method Of Authentication
References: <199809091924.MAA11040@slack.lne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net
      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 <ietf-pkix@imc.org>; 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: <35F843D4.7FF4@bull.net>
Date: Thu, 10 Sep 1998 14:25:40 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Reply-To: Denis.Pinkas@bull.net
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Mike Smith <mfsmith@zionsbank.com>
CC: william.burr@nist.gov, BJUENEMAN@novell.com, ietf-pkix@imc.org
Subject: Re: New Extension Proposed: Method Of Authentication
References: <s5f6527f.038@zionsbank.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net
      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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Thu, 10 Sep 1998 17:52:05 +0530
Message-ID: <002b01bddcb6$078be850$646801c4@dynamo.fcpl.co.in>
From: "Abhay Kulkarni" <abhay@fcpl.co.in>
To: <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:  abhay@fcpl.co.in
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:abhay@fcpl.co.in">abhay@fcpl.co.in</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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: <s5f788bd.052@wpgate.domus.com>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 10 Sep 1998 08:07:16 -0400
From: William Dziadyk <WDziadyk@domus.com>
To: ietf-pkix@imc.org
Subject: For Option 2
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

      
---------------------------------------------------------------------------------
   William Dziadyk, PEng
   IT Security Services, DOMUS Software, Ottawa, Ontario, Canada 
   (613) 230-6285  ext 342  ----   WDziadyk@DOMUS.com 
 ---------------------------------------------------------------------------------


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: <35F77875.E02C36B8@geocities.com>
Date: Thu, 10 Sep 1998 12:27:57 +0530
From: Narayan Raghu <narry@geocities.com>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Paul Hoffman / IMC <phoffman@imc.org>
CC: ietf-pkix@imc.org
Subject: Re: New Extension Proposed: Method Of Authentication
X-Priority: 3 (Normal)
References: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <199809092353.QAA27581@mail.proper.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Tony Bartoletti'" <azb@llnl.gov>, Phillip M Hallam-Baker <pbaker@verisign.com>, Santosh Chokhani <chokhani@cygnacom.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com, Eric Murray <ericm@lne.com>
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:azb@llnl.gov]
> Sent:	Wednesday, September 09, 1998 7:20 PM
> To:	Phillip M Hallam-Baker; Santosh Chokhani; Mike Smith;
> william.burr@nist.gov; BJUENEMAN@novell.com; Eric Murray
> Cc:	ietf-pkix@imc.org
> 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: azb@llnl.gov   phone: 510-422-3881             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 <ietf-pkix@imc.org>; Wed, 9 Sep 1998 16:53:53 -0700 (PDT)
Message-Id: <199809092353.QAA27581@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 09 Sep 1998 16:58:57 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: RE: New Extension Proposed: Method Of Authentication
In-Reply-To: <3.0.3.32.19980909162025.00a06390@poptop.llnl.gov>
References: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <3.0.3.32.19980909162025.00a06390@poptop.llnl.gov>
X-Sender: e048786@poptop.llnl.gov
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" <pbaker@verisign.com>, "Santosh Chokhani" <chokhani@cygnacom.com>, "Mike Smith" <mfsmith@zionsbank.com>, <william.burr@nist.gov>, <BJUENEMAN@novell.com>, Eric Murray <ericm@lne.com>
From: Tony Bartoletti <azb@llnl.gov>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: <ietf-pkix@imc.org>
In-Reply-To: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com>
References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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: azb@llnl.gov   phone: 510-422-3881             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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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" <dan.corcoran@eds.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <B0000265539@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; 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 <01BDDC08.BD7E9300@avenger.missi.ncsc.mil>; Wed, 9 Sep 1998 15:44:33 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-980909194432Z-33291@avenger.missi.ncsc.mil>
From: "Fillingham,  David W." <dwfilli@missi.ncsc.mil>
To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, "'Mike Smith'" <mfsmith@zionsbank.com>, "'william.burr@nist.gov'" <william.burr@nist.gov>, "'BJUENEMAN@novell.com'" <BJUENEMAN@novell.com>, "'Tony Bartoletti'" <azb@llnl.gov>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:azb@llnl.gov]
>Sent: 	Wednesday, September 09, 1998 3:12 PM
>To: 	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
>william.burr@nist.gov; BJUENEMAN@novell.com
>Cc: 	ietf-pkix@imc.org
>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:pbaker@verisign.com]
>>> Sent:	Wednesday, September 09, 1998 1:16 PM
>>> To:	Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com
>>> Cc:	ietf-pkix@imc.org
>>> 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: azb@llnl.gov   phone: 510-422-3881             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 <ietf-pkix@imc.org>; 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" <pbaker@verisign.com>
To: "Santosh Chokhani" <chokhani@cygnacom.com>, "Mike Smith" <mfsmith@zionsbank.com>, <william.burr@nist.gov>, <BJUENEMAN@novell.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 15:39:46 -0400
Message-ID: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.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.3110.3
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Tony Bartoletti'" <azb@llnl.gov>, Santosh Chokhani <chokhani@cygnacom.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:azb@llnl.gov]
> Sent:	Wednesday, September 09, 1998 3:12 PM
> To:	Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> william.burr@nist.gov; BJUENEMAN@novell.com
> Cc:	ietf-pkix@imc.org
> 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:pbaker@verisign.com]
> >> Sent:	Wednesday, September 09, 1998 1:16 PM
> >> To:	Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com
> >> Cc:	ietf-pkix@imc.org
> >> 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: azb@llnl.gov   phone: 510-422-3881             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 (NoBody@slack.lne.com [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25428 for <ietf-pkix@imc.org>; 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 <ericm@lne.com>
Message-Id: <199809091924.MAA11040@slack.lne.com>
Subject: Re: New Extension Proposed: Method Of Authentication
To: chokhani@cygnacom.com (Santosh Chokhani)
Date: Wed, 9 Sep 1998 12:24:18 -0700 (PDT)
Cc: pbaker@verisign.com, mfsmith@zionsbank.com, william.burr@nist.gov, BJUENEMAN@novell.com, ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <3.0.3.32.19980909121219.0094d830@poptop.llnl.gov>
X-Sender: e048786@poptop.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 09 Sep 1998 12:12:19 -0700
To: Santosh Chokhani <chokhani@cygnacom.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com
From: Tony Bartoletti <azb@llnl.gov>
Subject: RE: New Extension Proposed: Method Of Authentication
Cc: ietf-pkix@imc.org
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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:pbaker@verisign.com]
>> Sent:	Wednesday, September 09, 1998 1:16 PM
>> To:	Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com
>> Cc:	ietf-pkix@imc.org
>> 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: azb@llnl.gov   phone: 510-422-3881             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 <ietf-pkix@imc.org>; Wed, 9 Sep 1998 11:49:36 -0700 (PDT)
From: randy.sanovic@gm.com
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
Message-ID: <0525667A.006CF616.00@usabhmg01.mail.gm.com>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Kurn, David'" <david.kurn@compaq.com>, Santosh Chokhani <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:david.kurn@compaq.com]
> Sent:	Wednesday, September 09, 1998 1:51 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org'
> 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:chokhani@cygnacom.com]
> > Sent:	Wednesday, September 09, 1998 10:32 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> 'ietf-pkix@imc.org'
> > 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 <ietf-pkix@imc.org>; 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: <418B8B7ACE69D111879B00805F6F281DFFF568@exccup-25006.mis.tandem.com>
From: "Kurn, David" <david.kurn@compaq.com>
To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:chokhani@cygnacom.com]
> Sent:	Wednesday, September 09, 1998 10:32 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; 'ietf-pkix@imc.org'
> 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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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:pbaker@verisign.com]
> Sent:	Wednesday, September 09, 1998 1:16 PM
> To:	Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com
> Cc:	ietf-pkix@imc.org
> 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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Kurn, David'" <david.kurn@compaq.com>, Santosh Chokhani <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:david.kurn@compaq.com]
> Sent:	Wednesday, September 09, 1998 1:12 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org'
> 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:chokhani@cygnacom.com]
> > Sent:	Wednesday, September 09, 1998 9:53 AM
> > To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen';
> 'ietf-pkix@imc.org'
> > 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:david.kurn@compaq.com]
> > > Sent:	Wednesday, September 09, 1998 12:16 PM
> > > To:	'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > 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:chokhani@cygnacom.com]
> > > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > > To:	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > > To:	'ietf-pkix@imc.org'; '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:chokhani@cygnacom.com]
> > > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > > To:	'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > ----------
> > > > > > > > From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > > > > > 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 <ietf-pkix@imc.org>; 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" <pbaker@verisign.com>
To: "Mike Smith" <mfsmith@zionsbank.com>, <william.burr@nist.gov>, <BJUENEMAN@novell.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: New Extension Proposed: Method Of Authentication
Date: Wed, 9 Sep 1998 13:15:46 -0400
Message-ID: <001f01bddc15$7bf63980$ee0110ac@pbaker-pc.verisign.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
In-Reply-To: <s5f6527f.038@zionsbank.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <418B8B7ACE69D111879B00805F6F281DFFF566@exccup-25006.mis.tandem.com>
From: "Kurn, David" <david.kurn@compaq.com>
To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:chokhani@cygnacom.com]
> Sent:	Wednesday, September 09, 1998 9:53 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; 'ietf-pkix@imc.org'
> 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:david.kurn@compaq.com]
> > Sent:	Wednesday, September 09, 1998 12:16 PM
> > To:	'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > 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:chokhani@cygnacom.com]
> > > Sent:	Wednesday, September 09, 1998 8:27 AM
> > > To:	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > To:	'ietf-pkix@imc.org'; '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:chokhani@cygnacom.com]
> > > > > Sent: 	September 9, 1998 9:08 AM
> > > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > > To:	'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > > > > Subject:	RE: forward & reverse elements - population
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > ----------
> > > > > > > From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > > > > 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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Kurn, David'" <david.kurn@compaq.com>, Santosh Chokhani <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:david.kurn@compaq.com]
> Sent:	Wednesday, September 09, 1998 12:16 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org'
> 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:chokhani@cygnacom.com]
> > Sent:	Wednesday, September 09, 1998 8:27 AM
> > To:	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > Sent:	Wednesday, September 09, 1998 11:02 AM
> > > To:	'ietf-pkix@imc.org'; '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:chokhani@cygnacom.com]
> > > > Sent: 	September 9, 1998 9:08 AM
> > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > > To:	'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > > > Subject:	RE: forward & reverse elements - population
> > > > > 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > > > 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
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: <21781.905359115@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:31:48 -0700 (PDT)
Message-Id: <199809091631.JAA23381@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 09 Sep 1998 09:36:53 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: New Extension Proposed: Method Of Authentication
In-Reply-To: <s5f6527f.038@zionsbank.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:18:58 -0700 (PDT)
From: Alan_Buffett@hc-sc.gc.ca
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
Message-ID: <8525667A.005A035D.00@smta00.hc-sc.gc.ca>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <418B8B7ACE69D111879B00805F6F281DFFF564@exccup-25006.mis.tandem.com>
From: "Kurn, David" <david.kurn@compaq.com>
To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:chokhani@cygnacom.com]
> Sent:	Wednesday, September 09, 1998 8:27 AM
> To:	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > Sent:	Wednesday, September 09, 1998 11:02 AM
> > To:	'ietf-pkix@imc.org'; '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:chokhani@cygnacom.com]
> > > Sent: 	September 9, 1998 9:08 AM
> > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > > To:	'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > > Subject:	RE: forward & reverse elements - population
> > > > 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > > Sent: 	September 8, 1998 10:05 AM
> > > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > > 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 <ietf-pkix@imc.org>; 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: <s5f6527f.038@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 09 Sep 1998 10:03:36 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: william.burr@nist.gov, BJUENEMAN@novell.com
Cc: ietf-pkix@imc.org
Subject: New Extension Proposed: Method Of Authentication
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Denis.Pinkas@bull.net'" <Denis.Pinkas@bull.net>, Santosh Chokhani <chokhani@cygnacom.com>
Cc: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net]
> Sent:	Wednesday, September 09, 1998 8:44 PM
> To:	Santosh Chokhani
> Cc:	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> 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:sharon.boeyen@entrust.com]
> > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > To:   'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > Subject:      RE: forward & reverse elements - population
> > >
> > >
> > >
> > > > ----------
> > > > From:       Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > Sent:       September 8, 1998 10:05 AM
> > > > To:         'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > 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:Denis.Pinkas@bull.net
>       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 <ietf-pkix@imc.org>; Wed, 9 Sep 1998 08:41:28 -0700 (PDT)
From: Ross_Smith@hc-sc.gc.ca
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
Message-ID: <8525667A.00567CC1.00@smta00.hc-sc.gc.ca>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <35F720DC.42B3@bull.net>
Date: Wed, 09 Sep 1998 17:44:12 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Reply-To: Denis.Pinkas@bull.net
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@cygnacom.com>
CC: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Re: forward & reverse elements - population
References: <51BF55C30B4FD1118B4900207812701E1B1A5C@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com]
> > Sent: Tuesday, September 08, 1998 5:46 PM
> > To:   'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > Subject:      RE: forward & reverse elements - population
> >
> >
> >
> > > ----------
> > > From:       Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > Sent:       September 8, 1998 10:05 AM
> > > To:         'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > 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:Denis.Pinkas@bull.net
      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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, Santosh Chokhani <chokhani@cygnacom.com>
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: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com]
> Sent:	Wednesday, September 09, 1998 11:02 AM
> To:	'ietf-pkix@imc.org'; '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:chokhani@cygnacom.com]
> > Sent: 	September 9, 1998 9:08 AM
> > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > > Sent:	Tuesday, September 08, 1998 5:46 PM
> > > To:	'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > > Subject:	RE: forward & reverse elements - population
> > > 
> > > 
> > > 
> > > > ----------
> > > > From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > > Sent: 	September 8, 1998 10:05 AM
> > > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > > 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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F50AC9752@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Santosh Chokhani'" <chokhani@cygnacom.com>
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: owner-ietf-pkix@imc.org
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:chokhani@cygnacom.com]
> Sent: 	September 9, 1998 9:08 AM
> To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'; 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:sharon.boeyen@entrust.com]
> > Sent:	Tuesday, September 08, 1998 5:46 PM
> > To:	'ietf-pkix@imc.org'; 'Santosh Chokhani'
> > Subject:	RE: forward & reverse elements - population
> > 
> > 
> > 
> > > ----------
> > > From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > > Sent: 	September 8, 1998 10:05 AM
> > > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > > 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 9 Sep 1998 15:41:28 +0200 (DFT)
Message-ID: <35F703F0.53AA@bull.net>
Date: Wed, 09 Sep 1998 15:40:49 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Reply-To: Denis.Pinkas@bull.net
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <ietf-pkix@imc.org>
Subject: For Option none
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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:Denis.Pinkas@bull.net
      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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, Santosh Chokhani <chokhani@cygnacom.com>
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: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com]
> Sent:	Tuesday, September 08, 1998 5:46 PM
> To:	'ietf-pkix@imc.org'; 'Santosh Chokhani'
> Subject:	RE: forward & reverse elements - population
> 
> 
> 
> > ----------
> > From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> > Sent: 	September 8, 1998 10:05 AM
> > To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> > 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'Mike Smith '" <mfsmith@zionsbank.com>, "'fod@brd.ie '" <fod@brd.ie>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker '" <pbaker@verisign.com>
Cc: "'dave@chromatix.com '" <dave@chromatix.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
Precedence: bulk

Thanks for the reply - comments in line. 

----------
From: Phillip M Hallam-Baker
To: Mike Smith; fod@brd.ie; Alan.Lloyd@OpenDirectory.com.au
Cc: dave@chromatix.com; ietf-pkix@imc.org
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 (qmailr@old-atlantic.valicert.com [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA02147 for <ietf-pkix@imc.org>; 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: <35F60F60.37C6098E@valicert.com>
Date: Tue, 08 Sep 1998 22:17:20 -0700
From: Ambarish Malpani <ambarish@valicert.com>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Posnak <ejp@xetex.com>
CC: IETF PKIX <ietf-pkix@imc.org>
Subject: Re: OCSP in Chicago
References: <35F5A976.E3A03DCE@valicert.com> <35F5D996.DF96F76A@xetex.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
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.				        ambarish@valicert.com
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 <ietf-pkix@imc.org>; 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: <199809090245.WAA25675@2gn.com>
X-Sender: rodney@module-one.tillerman.nu
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 08 Sep 1998 23:44:10 -0400
To: Pavel Krylov <versed@elvis.ru>
From: Rodney Thayer <rodney@tillerman.nu>
Subject: Re: depth
Cc: ietf-pkix@imc.org
In-Reply-To: <XFMail.980907213528.versed@elvis.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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          versed@elvis.ru
> 



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 <ietf-pkix@imc.org>; 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: <35F5D996.DF96F76A@xetex.com>
Date: Tue, 08 Sep 1998 18:27:51 -0700
From: Ed Posnak <ejp@xetex.com>
Organization: Xetex Corporation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Ambarish Malpani <ambarish@valicert.com>
CC: IETF PKIX <ietf-pkix@imc.org>
Subject: Re: OCSP in Chicago
References: <35F5A976.E3A03DCE@valicert.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 15:05:56 -0700 (PDT)
Message-Id: <4.1.0.52.19980908180708.009c44a0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Tue, 08 Sep 1998 18:07:20 -0400
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
From: Russ Housley <housley@spyrus.com>
Subject: For Option 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <35F5A976.E3A03DCE@valicert.com>
Date: Tue, 08 Sep 1998 15:02:30 -0700
From: Ambarish Malpani <ambarish@valicert.com>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5b1 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF PKIX <ietf-pkix@imc.org>
Subject: OCSP in Chicago
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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.				        ambarish@valicert.com
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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F50AC974B@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Santosh Chokhani'" <chokhani@cygnacom.com>
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: owner-ietf-pkix@imc.org
Precedence: bulk

> ----------
> From: 	Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> Sent: 	September 8, 1998 10:05 AM
> To: 	'Sharon Boeyen'; 'ietf-pkix@imc.org'
> 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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 13:02:55 -0700 (PDT)
Received: from mailext02.compaq.com by mailext02.compaq.com via smail with esmtp id <m0zGRZ9-0007GRC@mailext02.compaq.com> for <ietf-pkix@imc.org>; 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 <m0zGRYi-0005BsC@mail.compaq.com> for <ietf-pkix@imc.org>; 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: <895FABD47F78D011863400805FBEBA8E0319E7A7@EXCHOU-CA0301.im.hou.compaq.com>
From: "Fuerst, Neal" <Neal.Fuerst@COMPAQ.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
Precedence: bulk

Thanks.

Neal Fuerst
Information Security Analyst
Compaq Computer Corporation
E-Mail: neal.fuerst@compaq.com
Phone: 281.518.8072
Pager: 713.509.4586

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



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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <01BDDB25.6EC159C0@napmsnoc02.shl.com>; Tue, 8 Sep 1998 12:37:25 -0700
Message-ID: <c=US%a=MCI%p=SHL%l=DALFW03-980908193704Z-53756@napmsnoc02.shl.com>
From: "PACHL, Jan" <jpachl@shl.com>
To: "'David Boyce'" <D.Boyce@isode.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
Precedence: bulk

in response to:
>From: 	David Boyce[SMTP:D.Boyce@isode.com]
>"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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: <D107B66CF5B9D111BA2A0000F86630AB8D822A@ogoexc1.ogo.dec.com>
From: Daya Puls <Daya.Puls@digital.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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: 978-496-9191, Eml: daya.puls@digital.com





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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 12:22:06 -0700 (PDT)
From: rpierce@2keys.ca
Received: (from rpierce@localhost) by 2keys.ca (8.8.7/8.8.7) id LAA16441 for ietf-pkix@imc.org; Tue, 8 Sep 1998 11:23:54 -0400
Message-Id: <199809081523.LAA16441@2keys.ca>
Subject: For Option 2
To: ietf-pkix@imc.org (IETF PKIX)
Date: Tue, 8 Sep 1998 15:23:54 +0000 ()
Content-Type: text
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 10:11:54 -0700 (PDT)
From: Dimitri.Vekris@bmo.com
Received: by lion.harrisbank.com id AA24091 (SMTP Gateway 3.0 for ietf-pkix@imc.org) 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 <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 12:20:46 -0400
Message-Id: <3.0.32.19980908122045.00f2f688@bl-mail2.corpeast.baynetworks.com>
X-Sender: dgiglio@bl-mail2.corpeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 08 Sep 1998 12:20:47 -0400
To: ietf-pkix@imc.org
From: David_Giglio@baynetworks.com (David Giglio)
Subject: For option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

___________________________________________________________________
David Giglio - Senior Product Manager 
Bay Networks, Inc.                Access Server Div.
M/S BL8-05                        dgiglio@baynetworks.com
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 <ietf-pkix@imc.org>; 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" <pbaker@verisign.com>
To: "Mike Smith" <mfsmith@zionsbank.com>, <fod@brd.ie>, <Alan.Lloyd@OpenDirectory.com.au>
Cc: <dave@chromatix.com>, <ietf-pkix@imc.org>
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$ee0110ac@pbaker-pc.verisign.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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <s5f398ef.030@zionsbank.com>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 08:43:17 -0700 (PDT)
From: Dimitri.Vekris@bmo.com
Received: by lion.harrisbank.com id AA18645 (SMTP Gateway 3.0 for ietf-pkix@imc.org) 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 <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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" <jpachl@shl.com>
cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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=DALFW03-980908135819Z-50946@dalmsdoc01.shl.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Sep 1998 16:38:15 +0100
Message-ID: <20698.905269095@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
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:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	d.boyce@isode.com	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 <ietf-pkix@imc.org>; 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 <sharon.boeyen@entrust.com>
cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Re: forward & reverse elements - population 
In-reply-to: Your message of "Mon, 07 Sep 1998 20:01:30 EDT." <D789F71F24B4D111955D00A0C99B4F50AC9748@sothmxs01.entrust.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Sep 1998 16:36:43 +0100
Message-ID: <20692.905269003@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
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:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	d.boyce@isode.com	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 <ietf-pkix@imc.org>; 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: <199809081502.LAA04610@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-10.txt
Date: Tue, 08 Sep 1998 11:02:09 -0400
Sender: owner-ietf-pkix@imc.org
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 ietf-pkix@tandem.com
   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:	mailserv@ietf.org.  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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980904152252.I-D@ietf.org>

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:	<19980904152252.I-D@ietf.org>

--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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 07:50:38 -0700 (PDT)
From: Jean_Bernatchez@hc-sc.gc.ca
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
Message-ID: <85256679.0051E05C.00@smta00.hc-sc.gc.ca>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <chokhani@cygnacom.com>
To: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
Precedence: bulk

comments in-line.

> -----Original Message-----
> From:	Sharon Boeyen [SMTP:sharon.boeyen@entrust.com]
> Sent:	Monday, September 07, 1998 8:02 PM
> To:	'ietf-pkix@imc.org'
> 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:sharon.boeyen@entrust.com  Tel: (613) 247-3181 
> http://www.entrust.com            Fax: (613) 247-3690 
>        


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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 06:55:50 -0700 (PDT)
From: jplachance@cse-cst.gc.ca
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: <C3222395B150D11185B300A0C9045CB90C3123@mailserverb.its.cse.dnd.ca>
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
Precedence: bulk

To whom it may concern, 

For Option 2. 

Regards, 






J.P. Lachance 
Senior Systems Engineer 
PMO GOC PKI 
Communications Security Establishement 
Tel: 613-991-7504 
Fax: 613-991-7455 
Internet: jplachance@cse-cst.gc.ca



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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <01BDDB06.D7033400@dalmsdoc01.shl.com>; Tue, 8 Sep 1998 08:58:25 -0500
Message-ID: <c=US%a=MCI%p=SHL%l=DALFW03-980908135819Z-50946@dalmsdoc01.shl.com>
From: "PACHL, Jan" <jpachl@shl.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>
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: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com]
>[ ... ]
>
>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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 06:07:57 -0700 (PDT)
From: tjcasar@its.cse.dnd.ca
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: <D151573E3DC6CF11AAAD00A0C90428FD296876@mailserver.cse.dnd.ca>
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 05:17:23 -0700 (PDT)
From: DeRosenroll.Michael@tbs-sct.gc.ca
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: <B103B7FE19C3D011900200805F19428E013BAA37@server5.tbs-sct.gc.ca>
To: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org
From: "John A. DiDuro" <jdiduro@apollo.fedworld.gov>
Subject: for Option 2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <jbingham@cygnacom.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Tue, 8 Sep 1998 10:25:05 +0200
Message-ID: <35F4EA2C.64AC@wxs.nl>
Date: Tue, 08 Sep 1998 10:26:20 +0200
From: Ton van Lieshout <ton.van.lieshout@wxs.nl>
Reply-To: ton.van.lieshout@wxs.nl
Organization: Point Information Systems B.V.
X-Mailer: Mozilla 3.01C-WXS-16  (Win95; I)
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: FOR OPTION 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <98Sep8.070148gmt+0100.26882@gateway.security.no>
From: =?iso-8859-1?Q?Svein_L=F8seth?= <slo@security.no>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
Precedence: bulk

---------------------------------------------------------------------------------------------------------------------------
Svein Løseth						Tlf.:    +47-22 95 86 83
Network Security AS					Fax:    +47-22 60 44 27
Gaustadalléen 21				    Dir. Line:    +47-22 95 85 48
N-0371 OSLO						GSM: +47-91 77 09 63
NORWAY						http://www.security.no




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 <ietf-pkix@imc.org>; 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: <D789F71F24B4D111955D00A0C99B4F50AC9748@sothmxs01.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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:sharon.boeyen@entrust.com  Tel: (613) 247-3181 
http://www.entrust.com            Fax: (613) 247-3690 
       



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 <ietf-pkix@imc.org>; Mon, 7 Sep 1998 15:26:01 -0700 (PDT)
Message-Id: <199809072226.PAA25803@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 07 Sep 1998 15:30:57 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: RE: PKIX freeware library coming soon (fwd)
In-Reply-To: <199809072249.AAA24035@cs.pub.ro>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; Mon, 7 Sep 1998 11:55:39 -0700 (PDT)
From: Lynn.Wheeler@firstdata.com
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 <mfsmith@zionsbank.com>
cc: fod@brd.ie, Alan.Lloyd@OpenDirectory.com.au, dave@chromatix.com, ietf-pkix@imc.org
Message-ID: <88256678.0067D844.00@lnsunr02.firstdata.com>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <XFMail.980907213528.versed@elvis.ru>
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 <versed@elvis.ru>
To: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: depth
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

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

Sharon, Santosh? 

---------------------------------------
Pavel V.Krylov          versed@elvis.ru


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 <ietf-pkix@imc.org>; 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: <s5f3c243.014@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 11:23:32 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: Alan.Lloyd@OpenDirectory.com.au
Cc: ietf-pkix@imc.org
Subject: Re: Re relational - and Dirs and all that
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'mfsmith@zionsbank.com'" <mfsmith@zionsbank.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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 <ietf-pkix@imc.org>; 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: <s5f3aefa.078@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 10:01:25 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: fod@brd.ie, Alan.Lloyd@OpenDirectory.com.au
Cc: dave@chromatix.com, ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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 <Alan.Lloyd@OpenDirectory.com.au> 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: fod@brd.ie; Alan.Lloyd@OpenDirectory.com.au 
Cc: dave@chromatix.com; ietf-pkix@imc.org 
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 <Alan.Lloyd@OpenDirectory.com.au> 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; ietf-pkix@imc.org 
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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: "'fod@brd.ie '" <fod@brd.ie>, "'Mike Smith '" <mfsmith@zionsbank.com>
Cc: "'dave@chromatix.com '" <dave@chromatix.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
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: owner-ietf-pkix@imc.org
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: fod@brd.ie; Alan.Lloyd@OpenDirectory.com.au
Cc: dave@chromatix.com; ietf-pkix@imc.org
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 <Alan.Lloyd@OpenDirectory.com.au> 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; ietf-pkix@imc.org 
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 <ietf-pkix@imc.org>; 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: <s5f398ef.030@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Sep 1998 08:27:08 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: fod@brd.ie, Alan.Lloyd@OpenDirectory.com.au
Cc: dave@chromatix.com, ietf-pkix@imc.org
Subject: Relational vs Directory Repository Models (was RE: path development complexity s)
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
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 <Alan.Lloyd@OpenDirectory.com.au> 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; ietf-pkix@imc.org 
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 (root@maild.telia.com [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05618 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 06:56:06 -0700 (PDT)
Received: from d1o65.telia.com (root@d1o65.telia.com [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: <3.0.32.19980907155744.00a55170@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 07 Sep 1998 15:58:39 +0200
To: "Aram Perez" <aram@apple.com>, bob jueneman <bjueneman@novell.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: Digital signature and non-repudiation key usage bits
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@imc.org
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